So you invent a new name for something which serves more or less
the same purpose.
The new name exists because unique_ptr is not an exact superset of the
auto_ptr syntax. If it were, , we could just fix auto_ptr instead of
deprecating it and introducing a new name.
Just curious, but why the new name?
Read the link. At the top of the read is the reason for deprecating
auto_ptr and substituting in unique_ptr as the replacement. If we could
simply reengineer auto_ptr without breaking existing code we would. But
we can't.
Are there any legal uses of
auto_ptr that won't work exactly the same with unique_ptr? And
if not, why not call it auto_ptr, assuming that that doesn't
break any working code?
From the paper:
However because unique_ptr does not move from lvalues with copy syntax, it is
not a 100% source-compatible drop in replacement for auto_ptr. If it were, we
could just fix auto_ptr instead of deprecating it and introducing a new class
template.
(I use auto_ptr a lot in multithreaded
programs, even when I'm also using the Boehm collector.)
And that is the reason auto_ptr has been deprecated, not removed, from
the standard. We understand that it is heavily used and must remain in
the standard for now. Deprecation doesn't mean non-standard. It merely
means that you are put on notice that it might be removed from a future
standard (say in 2019).
Within that decade ahead of us, I hope that most uses of auto_ptr will
be able to migrate to unique_ptr. But that migration will, in some
cases, require more than just renaming auto_ptr to unique_ptr. The link
points out the breakage under this migration:
However copy semantics is disabled with unique_ptr:
auto_ptr<int> ap1(new int);
auto_ptr<int> ap2 = ap1; // ok, but unsafe implicit move
unique_ptr<int> up1(new int);
unique_ptr<int> up2 = up1; // compile time error: illegal access to
// private copy constructor
If you really want to transfer ownership from the lvalue unique_ptr, you move
from it just as you would any other type:
unique_ptr<int> up1(new int);
unique_ptr<int> up2 = move(up1); // ok, explicit move
In the interim auto_ptr and unique_ptr will coexist in the standard.
unique_ptr will support a superset of the functionality of auto_ptr, but
with slightly different syntax when "copying" (actually moving) from
lvalues.
-Howard
.