Semantic meanings of std::auto_ptr and boost::shared_ptr

Question

In our large project we have a lot class with the following typedef's:

class Foo
{
  public:
    typedef std::auto_ptr<Foo> Ptr;
    typedef boost::shared_ptr<Foo> Ref;
  ...
};
...
Foo::Ref foo(new Foo);
...
doBar(foo);
...

The using of them is very convenient. But I doubt if auto_ptr is semantically close to Ptr and shared_ptr is the same as ref? Or should auto_ptr be used explicitly since it has "ownership transfer" semantics?

Thanks,

Answer 1

std::auto_ptr has ownership transfer semantics, but it's quite broken. If you can use boost::shared_ptr, then you should use boost::unique_ptr instead of std::auto_ptr, since it does what one would expect. It transfers ownership and makes the previous instance invalid, which std::auto_ptr doesn't.

Even better, if you can use C++11, then swap to std::unique_ptr and std::shared_ptr.

Answer 2

auto_ptr is deprecated in C++11. You might want to stop using it and just use the shared_ptr. For shared_ptr, there is no ownership transfer on assignment, the number of references to the object is counted and the object is destroyed when the last pointer is destroyed.

Answer 3

I believe the order is just a nomenclature which someone used.
It probably should have been, ref for auto_ptr and ptr for shared_ptr, because:

References are immutable and hence cannot be made to refer to other object. auto_ptr has a similar(albeit remotely similar) semantics, transfer of ownership which means you would probably not want to assign a auto_ptr for the non-intuitive behavior it shows. The assigned object gains ownership while the object being assigned loses ownership.

On the Other hand shared_ptr has an reference counting mechanism which is similar(again remotely) to multiple pointers which can point to the same object. The ownership of the pointer rests with the shared_ptr itself and it gets deallocated as soon as there are no pointer instances referring to it.

Answer 4

You shouldn't use std::auto_ptr, its deprecated and I consider it dangerous, even more so when you hide it behind such a generic typedef as Ptr.

I don't think it makes any sense to called shared_ptrRef, in this case it is more Ptr than auto_ptr.

EDIT: I consider it dangerous because you can easily misuse it, even when you fully understand its workings, you can accidentally misuse it, especially when hiding it behind a typedef. A good class should be easy to use right and should be difficult to misuse. Especially with the advent of unique_ptr I can't see any useful scenario for auto_ptr.

Answer 5

A lot depends on what they are being used for. And in the case of Ref, what people understand by it. In pre-standard days, I would often use a typedef to Ptr for my (invasive) reference counted pointer; the presence of such a typedef was, in fact, an indication that the type supported reference counting, and that it should always be dynamically allocated.

Both std::auto_ptr and boost::shared_ptr have very special semantics. I'd tend not to use typedefs for them, both because of the special semantics, and because (unlike the case of my invasive reference counted pointer) they are totally independent of the type pointed to. For any given type, you can use them or not, as the program logic requires. (Because of its particular semantics, I find a fair number of uses for std::auto_ptr. I tend to avoid boost::shared_ptr, however; it's rather dangerous.)