containers and auto_ptr

Started by
5 comments, last by GameDev.net 19 years, 6 months ago
I know that you shouldn't put auto_ptr-like smart-pointers in STL containers because the containers aren't gauranteed by the standard not to make internal copies (which would, of course, screw up whatever they are making internal copies of). Now, if I want destructive-copy smart-pointers (like auto_ptr), do I have to make my own containers!? Is there a way around this weirdness?
Not giving is not stealing.
Advertisement
No, there is no way around it. STL Container elements must be Assignable.

Destructive copy violates that requirement.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Ahh, crap.

Thanks for telling me what I didn't want to hear. [sad]
Not giving is not stealing.
Quote:Original post by thedevdan
Thanks for telling me what I didn't want to hear.


I aim to please.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
What are you using them for? Maybe boost::shared_ptr would do the trick. It allows you to keep several shared pointers to an object and when all the pointers go out of scope the object gets deleted.
Use boost::shared_ptr instead (since it was designed for just that purpose); IIRC it's set to be included in the C++ standard, so you'll be ahead of the curve.
Why not just allocate an auto_ptr on the heap? ;)

This topic is closed to new replies.

Advertisement