Idiomatic use of std::auto_ptr or only use shared_ptr?

Question

Now that shared_ptr is in tr1, what do you think should happen to the use of std::auto_ptr? They both have different use cases, but all use cases of auto_ptr can be solved with shared_ptr, too. Will you abandon auto_ptr or continue to use it in cases where you want to express explicitly that only one class has ownership at any given point?

My take is that using auto_ptr can add clarity to code, precisely by adding nuance and an indication of the design of the code, but on the other hand, it add yet another subtle issue when training new programmers: they need to understand smart pointers and the fine details of how they work. When you use only one smart pointer everywhere, you can just lay down a rule 'wrap all pointers in shared_ptr' and be done with it.

What's your take on this?

Answer 1

I believe that "wrap all pointers in shared_ptr" should indeed be the default mode, and is suitable advice to give to your junior coders. However, in the special ownership cases that you mentioned, auto_ptr is indeed more appropriate and its use should be encouraged under such circumstances.

Answer 2

I believe that it's best-practice is to substitute all uses of std::auto_ptr by boost::scoped_ptr unless std::tr1::shared_ptr meets the requirements better, if you don't mind using Boost. On the other hand, it was surely intentional that scoped_ptr wasn't included in TR1.

Answer 3

"Use shared_ptr everywhere" is a good default rule, and certainly a good starting point for teaching people about responsible use of smart pointers. However, it's not always the best choice.

If you don't need shared ownership, shared_ptr is overkill: it has to allocate a separate memory block for the reference count, which can impact performance, and it is less clear documentation-wise.

Personally, I use std::auto_ptr in many places where boost::scoped_ptr would also suffice: e.g. holding a heap-allocated object before ownership is transferred elsewhere, where the intervening operations might throw.

C++0x will have std::unique_ptr to complement std::shared_ptr as a better alternative to std::auto_ptr. When it becomes widely available I'll start using that.

Answer 4

auto_ptr is nice in signatures, too. When a function takes an auto_ptr<T> by value, it means it will consume the T. If a function returns an auto_ptr<T>, it's clear that it relinquishes ownership. This can communicate your intents about the lifetime.

On the other hand, using scoped_ptr<T> implies that you don't want to care about the lifetime of the T. This also implies you can use it in more places. Both smart pointers are valid choices, you can certainly have both in a single program.

Answer 5

To provide a little more ammunition to the 'avoid std::auto_ptr' camp: auto_ptr is being deprecated in the next standard (C++09). I think this alone is good enough ammunition for any argument to use something else.

However, as Konrad Rudolph mentioned, the default replacement for auto_ptr should probably be boost::scoped_ptr. The semantics of scoped_ptr more closely match those of auto_ptr and it is intended for similar uses. The next C++09 standard will have something similar called unique_ptr.

However, using shared_ptr anywhere that scoped_ptr should be used will not break anything, it'll just add a very slight bit of inefficiency to deal with the reference count if the object is never actually going to be shared. So for private member pointers that will never be handed out to another object - use scoped_ptr. If the pointer will be handed out to something else (this includes using them in containers or if all you want to do is transfer ownership and not keep or share it) - use shared_ptr.