15

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?

lithuak
  • 6,028
  • 9
  • 42
  • 54

4 Answers4

14

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.
icecrime
  • 74,451
  • 13
  • 99
  • 111
  • 1
    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 ... – etarion Dec 29 '10 at 13:15
  • 5
    @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. – CB Bailey Dec 29 '10 at 13:20
  • 1
    @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. – icecrime Dec 29 '10 at 13:22
  • 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). – John Bartholomew Dec 29 '10 at 14:33
  • 5
    +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. – John Dibling Dec 29 '10 at 16:27
  • @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](http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/2058b30338c8ca25/5b352a4750739eaa)) – icecrime Dec 30 '10 at 10:06
  • @JohnBartholomew I know this is old, but might I suggest [BCP](http://www.boost.org/doc/libs/1_55_0/tools/bcp/doc/html/index.html)? It makes extracting boost easy. – Alice Mar 18 '14 at 05:29
5

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.

Khaled Alshaya
  • 94,250
  • 39
  • 176
  • 234
  • Yep -- you're only screwed into this if you need to support Windows earlier than XP SP2. – Billy ONeal Dec 29 '10 at 14:30
  • 1
    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. – Martin York Dec 29 '10 at 18:48
  • @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. – Khaled Alshaya Dec 30 '10 at 00:44
2

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.

sharptooth
  • 167,383
  • 100
  • 513
  • 979
1

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.

Raedwald
  • 46,613
  • 43
  • 151
  • 237
  • 2
    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. – CB Bailey Dec 29 '10 at 12:58
  • In this case the `Container` pbject retains ownership of the `Foo` obkect. – Raedwald Dec 29 '10 at 13:35
  • 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. – CB Bailey Dec 29 '10 at 13:42
  • `this->addFoo(*file)` records the reference. – Raedwald Dec 29 '10 at 14:00
  • Again, how? This line appears to have nothing to do with `foo`. Edit: Ah, did you mean `addFoo(*foo)`? – CB Bailey Dec 29 '10 at 14:07
  • Yes, sorry for the typo. Now fixed. – Raedwald Dec 29 '10 at 14:35