# std::auto_ptr annoyance

This topic is 3801 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

It's not allowed to say: autopointer = pointer Where autopointer is an std::auto_ptr and pointer is a regular pointer. Instead you have to use autopointer.reset(pointer) OR autopointer = std::auto_ptr<TheType>(pointer) And that is also what I intended by typing "autopointer = pointer" Why did the C++ committee decide to do it that way? The reason I ask is, if you do autopointer = pointer, you get no compiler error but it still crashes. auto_ptr's would have been more straightforward to use if autopointer = pointer would have behaved the same as autopointer.reset(pointer), I think. Is there a reason, technical or non-technical, why they decided to not make the interface of auto_ptr that way?

##### Share on other sites
I'm sure that it has something to do with the fact that auto_ptr takes over ownership of the pointer when copying.

I also have a gut feeling that std::auto_ptr is in 90% of all cases the solution to memory managment in C++, but people are not smart enough to use it properly, so they need shared_ptr etc. </uneducated opinion>

##### Share on other sites
This behavior is caused by the constructor of std::auto_ptr being declared explicit.
This is done for security reasons; the following code would be legal (and enough dangerous to be disallowed, in opinion of std-developers, not mine):

#include <memory>void func(std::auto_ptr<int> a){}int main(){int* a = new int;func(a); // implicit conversion, does not compile with explicit constructor of auto_ptrdelete a; // crash, auto_ptr try to delete a}

You might delete the "explicit" modifier of

explicit auto_ptr(_Ty *_Ptr = 0) _THROW0()

at line 656 of memory.h if you are brave enough! ;)

##### Share on other sites
yes, there is.

auto_ptr is a very special RAII tool that not just owns its resource but also has special copy semantics - ownership is always transferred from source (auto or raw) to destination auto_ptr. since it is impossible to take ownership from raw pointer, user has to explicitly show his intentions to be sure he know what he is doing. it prevents from loooooooots of bugs from various scenarios. also be sure to check how auto_ptr works with std containers (compiler SHOULD forbid that, but this is not always true)

##### Share on other sites
Assigning a pointer to an auto_ptr-typed variable is a big deal: the auto_ptr must delete() the previously referenced object. That's why the auto_ptr constructor from a raw pointer, which is what you would be calling in your example, is declared explicit; normal usage is initializing an auto_ptr with it:

std::auto_ptr<TheType> autopointer(pointer);

Which doesn't seem verbose to me.

Calling reset() and if needed release() is convenient enough for the uncommon case of recycling an auto_ptr for different objects rather than declaring several ones:

//normal{std::auto_ptr<TheType> a_x(new TheType("X"));//...do stuff with instance "X"...std::auto_ptr<TheType> a_y(new TheType("Y"));//...do stuff with instance "X" and instance "Y"...//both a_x and a_y go out of scope, instance "X" and instance "Y" are deleted}//strange{ std::auto_ptr<TheType> a_only(new TheType("X"));//...do stuff with instance "X"...a_only.reset(new TheType("Y"))//instance "X" is deleted//...do stuff with instance "Y" only...//a_only goes out of scope and instance "Y" is deleted}

##### Share on other sites
Quote:
 Original post by KonfusiusI also have a gut feeling that std::auto_ptr is in 90% of all cases the solution to memory managment in C++, but people are not smart enough to use it properly, so they need shared_ptr etc.

The semantics and use cases for std::auto_ptr and boost::shared_ptr are completely different. Because of std::auto_ptr's behavior, I wouldn't think it covers anywhere near 90% of memory management scenarios!

In any case, I would think boost::shared_ptr, given it's shared semantics, would cover more general case scenarios than std::auto_ptr. Garbage collected languages often share these same shared semantics, for example.

##### Share on other sites
Quote:
Original post by GenuineXP
Quote:
 Original post by KonfusiusI also have a gut feeling that std::auto_ptr is in 90% of all cases the solution to memory managment in C++, but people are not smart enough to use it properly, so they need shared_ptr etc.
In any case, I would think boost::shared_ptr, given it's shared semantics, would cover more general case scenarios than std::auto_ptr. Garbage collected languages often share these same shared semantics, for example.
I tend to agree with you, but Konfusius is also correct - automatic garbage collection or any kind is a form of laziness, albeit a very convienient one. Where you can afford the performance and space requirements, it allows you to write code faster, without caring particularly about the details.

You can write vast, dynamic systems without using any form of reference counting or garbage collection, but it requires much more careful forethought, and a very high level of coding discipline.

1. 1
2. 2
3. 3
Rutin
20
4. 4
khawk
14
5. 5
frob
12

• 9
• 11
• 11
• 23
• 12
• ### Forum Statistics

• Total Topics
633656
• Total Posts
3013190
×