Is there any reason to use auto_ptr?

Question

After reading Jossutis' explanation on auto_ptr from his STL book I've got a strong impression that whatever task I would try to use it in I'd 100% fail becuase of one of many auto_ptr's pitfalls.

My question is: are there any real life tasks where auto_ptr is really usefull and does fit there well?

Semmes

gotw.ca/publications/using_auto_ptr_effectively.htm – Nicholasnichole

Note that the article is almost 11 years old, and we know better alternatives these days. – Exceptive

I wouldn't recommend that article. Not only because it's old, but also it has errors: Pimpl example won't work. – Lotic

Answer 1

Clearly, auto_ptr looses against unique_ptr.

Now, in a 'strict C++03 without boost' world, I use auto_ptr quite often, most notably :

• For 'factory member functions' which return a dynamically allocated instance of a given type : I like the fact that using std::auto_ptr in the return type explicits that the object must be deleted
• In functions which allocate an object before attempting to insert it in a container afterwards : for example in order to release() only if std::map<>::insert returns that insertion succeeded
• In a thread procedure which pops elements from a message queue, I like storing the pop'ed element in a const std::auto_ptr to make it clear that the message will be destroyed no matter what.

Upgrowth

I fail to see the point of "without boost". The smart pointers are a header-only library, so it's not like you have to link against anything. You could just copy&paste the code from boost ... – Pleach

@etarion: It's still a maintenance overhead. Which version of boost? Who's responsible for monitoring for updates? Do you need to review the code because it's not part of the implementation. In some environments using code that is not part of the implementation always implies a large management overhead. – Spencerianism

@etarion: actually, I added this to prevent comments stating that boost::scoped_ptr is more appropriate than std::auto_ptr in some of the cases I've listed (which would be true) :-) But on a side note, have you actually tried to copy boost/shared_ptr.hpp only ? It's really not that easy. – Upgrowth

I extracted the boost smart pointer headers once. Never again. You've gotta pull out practically the whole boost config system as well, it's easier to re-implement the smart pointers (except you'll get it wrong of course, especially w.r.t. conversion-to-bool). – Patterson

+1 because there are many shops that have legitimate reasons for not using Boost. I work in such a shop. See @Charles' comment for some of the legitimate reasons. – Fart

@wilhelmtlell: actually std::auto_ptr should be avoided for pimpl (I can't seem to find a concise explanation, but you can check this thread) – Upgrowth

@JohnBartholomew I know this is old, but might I suggest BCP? It makes extracting boost easy. – Martyrology

Answer 2

I would say it can be used, but it is not the best option.

First, it is a matter of year or less and auto_ptr is officially deprecated. Second, there is a superior alternative: unique_ptr. Dr. Stroustrup once said about unique_ptr:

“What auto_ptr should have been” (but that we couldn't write in C++98)

So unless you don't have the choice, auto_ptr is not a good choice. Mainly, because most C++ compilers these days implement move semantics and provide unique_ptr.

Exceptive

Yep -- you're only screwed into this if you need to support Windows earlier than XP SP2. – Kobold

It may not be the best smart_pointer, but it is still a better choice than a RAW pointer with no ownership systematic. Of course unique_ptr is a clear step forward. – Chape

@Martin York +1 Maybe because I am still a student, I don't think about dependencies in a realistic way. I agree that using auto_ptr is better than dealing with raw pointers directly. – Exceptive

Answer 3

In simple scenarios when you need to temporarily control a heap-allocated object auto_ptr can be used without problems. For example if you need to conditionally create an object that will be used only within one function you can't allocate it on stack and auto_ptr lets you not care of the object lifetime should an exception occur.

Reichert

Answer 4

I use std::auto_ptr moderately often, to ensure exception safety. That is, to prevent a memory leak in the event of part of a method throwing an exception.

For example:

Foo &Container::addFoo(
   const std::string &name
   )
{
  // The post conditions of the method require that the new Foo
  // has been added to this container, but the addition method
  // may throw exceptiona
  std::auto_ptr< Foo > foo(new Foo(name));

  foo->twiddle();// may throw
  this->addFoo(*foo);// record reference. May throw

  return *foo.release();
}

Edited: clarified that this->addFoo(*foo) records a reference.

Chavez

I'm sure I wouldn't return a reference to something that I expected a client to deallocate. Why not return the auto_ptr by value to signal the transfer of ownership? That's one of auto_ptr's designed usages. – Spencerianism

In this case the Container pbject retains ownership of the Foo obkect. – Chavez

How? foo is constructed locally and not passed to any other function (other than the member function twiddle). From the code it looks like the caller is left with the only reference to it. – Spencerianism

this->addFoo(*file) records the reference. – Chavez

Again, how? This line appears to have nothing to do with foo. Edit: Ah, did you mean addFoo(*foo)? – Spencerianism

Yes, sorry for the typo. Now fixed. – Chavez