Replacing auto_ptr in VC++ 8

Question

std::auto_ptr is broken in VC++ 8 (which is what we use at work). My main gripe with it is that it allows auto_ptr x = new T();, which of cour

Answer 1

Use boost::shared_ptr/boost::scoped_ptr. It will be the preferred smart pointer in upcoming C++ standards (is in TR1 already).

Edit: Please find a related discussion here: Idiomatic use of std::auto_ptr or only use shared_ptr?

Answer 2

As far as I recall, wasn't it :

auto_ptr<T> x = auto_ptr<T>(new T()); ??

Answer 3

Not an answer, but for general interest of anyone for whom these bugs are relevant. There's one more related bug with VC8's auto_ptr, which has to do with implicit upcasts. It's probably the most evil of the bunch, because other bugs just let you compile code that is otherwise illegal according to Standard without failing, but at least compliant code works fine. With this bug, the code that is actually compliant does not work properly.

The problem is this. Standard specifies auto_ptr constructors and conversion operators in such a way that they support implicit upcasting of auto_ptrs, just as with normal pointers. However, VC8 implementation of that does a reinterpret_cast rather than a static_cast there. Naturally, not only this is U.B. by the letter of the standard, but it also breaks with multiple base classes and/or virtual inheritance. Here's an example of legal code broken by this:

struct Base1 { int x; };
struct Base2 { int y; };
struct Derived : Base1, Base2 {};

std::auto_ptr<Derived> createDerived()
{
  return std::auto_ptr<Derived>(new Derived);
}

std::auto_ptr<Base2> base2(createDerived());

At one of my past jobs, when we ran into this problem in production, we ended up simply patching the headers ourselves (it's a trivial 2-line fix).

Answer 4

Move to boost smart pointers.

In the meantime, you may want to extract a working auto_ptr implementation from an old / another STL, so you have working code.

I believe that auto_ptr semantics are fundamentally broken - it saves typing, but the interface actually is not simpler: you still have to track which instance is the current owner and make sure the owner leaves last.

unique-ptr "fixes" that, by making release not only give up ownership, but also setting the RHS to null. It is the closest replacement for auto-ptr, but with its different semantics it is not a drop-in replacement.

There's an introductory article to boost smart pointers, by, ahem, me.

Answer 5

Have you considered using STLPort?

Answer 6

Use a unique_ptr. I think these were introduced to be a better auto_ptr.

http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_smart_ptr.html#interprocess.interprocess_smart_ptr.unique_ptr

In fact, I'm led to believe auto_ptr may be deprecated in favour of it:

http://objectmix.com/c/113487-std-auto_ptr-deprecated.html