3

It gives up auto_ptr and adds unique_ptr and shared_ptr. Are they good enough to let c++ abandon auto_ptr? There must be sometimes auto_ptr could lead to bad results. Can anyone give me an example?

If it doesn't do bad C++11 will keep it rather than give up.

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
Fanl
  • 1,491
  • 2
  • 11
  • 15
  • In addition to the other answers, which are all good, using `unique_ptr` and `shared_ptr` via `make_unique` or `make_shared` is much more effective than using the vanilla `auto_ptr` constructor with a `new` operator inside it. –  Apr 18 '14 at 04:45
  • Make note of 'guru question #4': http://herbsutter.com/2013/05/29/gotw-89-solution-smart-pointers/ – Mark Apr 18 '14 at 05:39

4 Answers4

4

Because unique_ptr is a better alternative for auto_ptr.

In particular, it was not possible to store an auto_ptr in a container. While you can store unique_ptr in a container.

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
  • 1
    Actually there's no problem returning an `auto_ptr` from a function. That's one of the only things it's good at. – Mark Ransom Apr 18 '14 at 03:45
  • @MarkRansom You are right, corrected. It makes sense as it transfers the ownership, I must have bad memory about its usage. – Yu Hao Apr 18 '14 at 03:50
4

auto_ptr was copy constructible which used to move the ownership, e.g.,

    auto_ptr a;
    ....
    auto_ptr<int> b = a; // a loses its ownership here

This can lead to confusion and bugs.

unique_ptr is not copy constructible. It is move constructible which moves the ownership, e.g.,

    unique_ptr a;
    ....
    unique_ptr<int> b = a; // ERROR, wont compile

    unique_ptr<int> b = std::move(a); // OK, as programmer is explicitly moving ownership, no confusion

    unique_ptr<int> b = unique_ptr(p); // OK, ownership will move from temporary unique_ptr

shared_ptr is obviously to share ownership, so:

    shared_ptr a;
    ...
    shared_ptr b = a; // both a and b have ownership, underlying pointer will only be freed when a and b both are out of scope
OOO
  • 914
  • 1
  • 10
  • 18
1

Yes, auto_ptr leads to bad results.

If you assign one auto_ptr to another, the first pointer loses its pointer altogether. This is a surprising result that leads to bugs.

auto_ptr<int> p1(new int(42));
auto_ptr<int> p2 = p1;        // at this point p1 is a bad pointer

unique_ptr is a much better alternative.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • Agreed. Just adding that unique_ptr's solution is to make the transfer of ownership *explicit* and compile-time checked. – Mark Apr 18 '14 at 05:40
1

The C++ Standard says that an STL element must be "copy-constructible" and "assignable." An element must be able to be assigned or copied and the two elements are logically independent. std::auto_ptr does not fulfill this requirement. In other words,the STL containers need to be able to copy the items you store in them, and are designed to expect the original and the copy to be equivalent. Auto pointer objects have a completely different contract, whereby copying creates a transfer of ownership. This means that containers of auto_ptr will exhibit strange behaviour, depending on usage.

unique_ptr is really the direct auto_ptr replacement, it combines the best features of both std::auto_ptr and boost::scoped_ptr.

DNamto
  • 1,342
  • 1
  • 21
  • 42