Why is it wrong to use std::auto_ptr<> with standard containers?

Question

Why is it wrong to use std::auto_ptr<> with standard containers?

Definitely a +1 on this because I've seen so many people get this wrong. It's a great question to ask. — twokats, Nov 07 '08 at 20:42
Please read also the related item. This question is considered here from the other side. May be helpful to understand more about auto_ptr and STL containers. http://stackoverflow.com/questions/8630552/auto-ptr-and-stl-containers-writing-an-example-of-erroneous-usage — nickolay, Dec 29 '11 at 11:59
C++ FAQ: [Can I have a container of smart pointers to my objects?](http://www.parashift.com/c++-faq-lite/containers.html#faq-34.6) — Amro, May 18 '12 at 01:44
`move` semantic and `unique_ptr` were designed to avoid the problems related to `auto_ptr`. In C++ 03, the language was not powerful enough to write a class like `auto_ptr` that behave correctly and safely in all scenarios as the compiler and the language were not able to distinguish l and r values so some "hacks" were used to get the desired behavior most of the time. — Phil1970, May 12 '17 at 03:22
Nice article: STL Containers and Auto_ptrs - Why They Don't Mix https://www.quantstart.com/articles/STL-Containers-and-Auto_ptrs-Why-They-Dont-Mix/ — alfC, Jun 08 '20 at 09:08

score 125 · Accepted Answer · edited Sep 04 '13 at 16:18

125

The C++ Standard says that an STL element must be "copy-constructible" and "assignable." In other words, 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.

Take for example this code:

class X
{
};

std::vector<std::auto_ptr<X> > vecX;
vecX.push_back(new X);

std::auto_ptr<X> pX = vecX[0];  // vecX[0] is assigned NULL.

To overcome this limitation, you should use the std::unique_ptr, std::shared_ptr or std::weak_ptr smart pointers or the boost equivalents if you don't have C++11. Here is the boost library documentation for these smart pointers.

edited Sep 04 '13 at 16:18

Nick Garvey

2,980
24
31

answered Sep 21 '08 at 17:47

Kevin

25,207
17
54
57

7

You should also consider the boost pointer containers, if you don't need shared ownership. – me22 Sep 10 '09 at 16:34
5

`unique_ptr` also disallows copying, so certain STL operations will not work correctly unless they can use its move semantics. – Mike Weller Jul 01 '13 at 09:54
4

"To overcome this limitation, you should use the `std::unique_ptr`": that class template can only exist because of move semantics (its specification requires rvalue references), so it fundamentally requires C++11. However (and related) the C++11 Standard no longer says that an STL element type must be "copy-constructible" and "assignable"; being move-constructible and move-assignable suffices. Indeed `unique_ptr` instances are only move-constructible and move-assignable. But so are `auto_ptr` instances! As a consequence, in C++11 you may do with `auto_ptr` what you can do with `unique_ptr`. – Marc van Leeuwen Aug 27 '14 at 09:26
@MarcvanLeeuwen unless you `reset` and `release` as needed – ratchet freak Sep 03 '14 at 07:47
2

@ratchetfreak: Hmm, I don't understand. What? "unless you `reset` and `release`", I don't see how that applies to anything in my comment. Note that both `auto_ptr` and `unique_ptr` have both these methods, and they do the same thing in both cases. – Marc van Leeuwen Sep 03 '14 at 09:05

Frank Krueger · Answer 2 · 2010-04-15T17:22:40.470

The copy semantics of auto_ptr are not compatible with the containers.

Specifically, copying one auto_ptr to another does not create two equal objects since one has lost its ownership of the pointer.

More specifically, copying an auto_ptr causes one of the copies to let go of the pointer. Which of these remains in the container is not defined. Therefore, you can randomly lose access to pointers if you store auto_ptrs in the containers.

score 39 · Answer 3 · answered Jun 25 '10 at 19:01

39

Two super excellent articles on the subject:

answered Jun 25 '10 at 19:01

Lazer

90,700
113
281
364

Because I think that in the intervening nearly two years, he probably dealt with the problem at hand. – Puppy Jun 25 '10 at 20:31
27

@DeadMG: yes, you are correct. But that was not my purpose. If someone comes to this thread sometime and wants to learn about `auto_ptr` and stuff, these links will be helpful, I am sure. – Lazer Jun 25 '10 at 20:44
There's plenty of duplicates that are more recent. – Puppy Jun 25 '10 at 21:23
8

@DeadMG: This question wasn't closed as duplicate and is therefore open for extension. Lazer said what was not said before here. I guess he came by by chance. – Sebastian Mach Nov 18 '11 at 16:21
The explanations in the second link, which analyze the problem after calling `sort()`, are clearer than all the answers here. – chaosink May 01 '20 at 19:35

score 17 · Answer 4 · edited Jun 25 '10 at 17:32

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.

There is a detailed description of what can go wrong in Effective STL (Scott Meyers) item 8 and also a not-so-detailed description in Effective C++ (Scott Meyers) item 13.

score 12 · Answer 5 · answered Sep 21 '08 at 17:44

12

STL containers store copies of contained items. When an auto_ptr is copied, it sets the old ptr to null. Many container methods are broken by this behavior.

answered Sep 21 '08 at 17:44

Dustin Getz

21,282
15
82
131

But, when using unique_ptr you get pretty much the same thing since only one unique_ptr can have the ownership of the object? – Tracer Jul 11 '14 at 06:56
2

@Tracer `unique_ptr` like any proper C++11 object can only transfer ownership of its resource when move-constructed or -assigned, ensuring that the programmer must deliberately pass an `std::move(sourceObject)` or a temporary, rather than passing an _lvalue_ and unintuitively/unpredictably having it mutated by the copy-assignment... which, as emphasised thoroughly here, was a core problem of `auto_ptr`. – underscore_d Feb 23 '16 at 00:15

Alex Bitek · Answer 6 · 2015-01-06T12:47:14.460

C++03 Standard (ISO-IEC 14882-2003) says in clause 20.4.5 paragraph 3:

[...] [Note: [...] auto_ptr does not meet the CopyConstructible and Assignable requirements for Standard Library container elements and thus instantiating a Standard Library container with an auto_ptr results in undefined behavior. — end note]

C++11 Standard (ISO-IEC 14882-2011) says in appendix D.10.1 paragraph 3:

[...] Note: [...] Instances of auto_ptr meet the requirements of MoveConstructible and MoveAssignable, but do not meet the requirements of CopyConstructible and CopyAssignable. — end note ]

C++14 Standard (ISO-IEC 14882-2014) says in appendix C.4.2 Annex D: compatibility features:

Change: The class templates auto_ptr, unary_function, and binary_function, the function templates random_shuffle, and the function templates (and their return types) ptr_fun, mem_fun, mem_fun_ref, bind1st, and bind2nd are not defined.
Rationale: Superseded by new features.
Effect on original feature: Valid C ++ 2014 code that uses these class templates and function templates may fail to compile in this International Standard.

Why is it wrong to use std::auto_ptr<> with standard containers?

6 Answers6

Linked

Related