views:

271

answers:

3

With the new standard coming (and parts already available in some compilers).

The new type std::unique_ptr is supposed to be a replacement for std::auto_ptr.

Does their usage exactly overlap (so I can do a global find/replace on my code (not that I would do this, but if I did)) or should I be aware of some differences that are not apparent from reading the documentation.

Also if it is a direct replacement (why give it a new name) rather than just improve the std::auto_ptr.

+5  A: 

std::auto_ptr and std::unique_ptr are incompatible in someways an a drop in replacement in others. So, no find/replace isn't good enough. However, after a find/replace working through the compile errors should fix everything except wierd corner cases.

  • Function variable:
    100% compatible, as long as you don't pass it to a function or use it as a return value.
  • Return value:
    not 100% compatible but 99% compatible doesn't seem wrong.
  • Parameter by value:
    100% compatible with one caveat, unique_ptrs must be passed through a std::move call.
  • Parameter by reference:
    100% compatible.
  • Member variable:
    This one is tricky. std::auto_ptrs copy semantics are evil. If the class disallows copying then std::unique_ptr is a drop in replacement. However, if you tried to give the class reasonable copy semantics, you'll need to change the std::auto_ptr handling code. If you allowed copying of a class with a std::auto_ptr member without any special code, shame on you and good luck.

In summary, std::unique_ptr is an unbroken std::auto_ptr. It disallows at compile time behaviors that were often errors when using a std::auto_ptr. So if you used std::auto_ptr with care it needed, switching to std::unique_ptr should be simple. If you relied on std::auto_ptr's odd behavior, then you need to refactor your code anyway.

caspin
+1 for "you need to refactor your code anyway". auto_ptrs are only good for what 20.4.5/3 says they are good for.
Cubbi
+8  A: 

You cannot do a global find/replace because you can copy an auto_ptr (with known consequences), but a unique_ptr can only be moved. Anything that looks like

std::auto_ptr<int> p(new int);
std::auto_ptr<int> p2 = p; 

will have to become at least like this

std::unique_ptr<int> p(new int);
std::unique_ptr<int> p2 = std::move(p);

As for other differences, unique_ptr can handle arrays correctly (it will call delete[], while auto_ptr will attempt to call delete.

Cubbi
on the other hand, doing this find/replace will only result in compile errors, it won't silently break code as far as I can see. So it is safe to do, if you manually fix the compile errors afterwards
jalf
@jalf: Indeed, I can't think of a counter-example that would be well-defined with auto_ptrs and UB with unique_ptrs.
Cubbi
+4  A: 

AFAIK, unique_ptr is not a direct replacement. The major flaw that it fixes is the implicit transfer of ownership.

std::auto_ptr<int> a(new int(10)), b;
b = a; //implicitly transfers ownership

std::unique_ptr<int> a(new int(10)), b;
b = std::move(a); //ownership must be transferred explicitly

On the other hand, unique_ptr will have completely new capabilities: they can be stored in containers.

UncleBens