title: When would you use an std::auto_ptr instead of boost::shared_ptr?
body: <p>We've pretty much moved over to using <code>boost::shared_ptr</code> in all of our code, however we still have some isolated cases where we use <code>std::auto_ptr</code>, including singleton classes:</p>
  
  <pre><code>template &lt; typename TYPE &gt;
  class SharedSingleton
  {
  public: 
      static TYPE&amp; Instance()
      {
          if (_ptrInstance.get() == NULL)
              _ptrInstance.reset(new TYPE);
          return *_ptrInstance;
      }
  
  protected: 
      SharedSingleton() {};
  
  private:
      static std::auto_ptr &lt; TYPE &gt; _ptrInstance;
  };
  </code></pre>
  
  <p>I've been told that there's a very good reason why this hasn't been made a <code>shared_ptr</code>, but for the life of me I can't understand why?  I know that <code>auto_ptr</code> will eventually get marked as depreciated in the next standard, so I'd like to <strong>know what/how I can replace this implementation</strong>.</p>
  
  <p><strong>Also, are there any other reasons why you'd consider using an <code>auto_ptr</code> instead of a <code>shared_ptr</code>?</strong> And do you see any problems moving to shared_ptr in the future?</p>
  
  <hr>
  
  <p><strong>Edit:</strong> </p>
  
  <ol>
  <li>So in answer to "can I safely replace <code>auto_ptr</code> with <code>shared_ptr</code> in the above code", the answer is yes - however I'll take a small performance hit.</li>
  <li>When <code>auto_ptr</code> is eventually marked as depreciated and we move over to <code>std::shared_ptr</code>, we'll need to thoroughly test our code to make sure we're abiding by the different ownership semantics. </li>
  </ol>