no prizes for guessing what I'm going to suggest....
if you want transfer of ownership semantics without the hassle of worrying about deleting the object, use a boost::shared_ptr.
no prizes for guessing what I'm going to suggest....
if you want transfer of ownership semantics without the hassle of worrying about deleting the object, use a boost::shared_ptr.
"I saw a sign that said 'Drink Canada Dry', so I started"
-- Brendan Behan
Free Compiler: Visual C++ 2005 Express
If you program in C++, you need Boost. You should also know how to use the Standard Library (STL). Want to make games? After reading this, I don't like WxWidgets anymore. Want to add some scripting to your App?
shared_ptr, as the name says, is about shared ownership, not transferring it. Use std::auto_ptr for that.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I always thought that the shared-ownership idiom was one of the possible ways of achieving ownership-transfer. Why use std::auto_ptr if I can transfer ownership through sharing?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
technically you're right, but I dislike using auto_ptr for anything other than very simple scoped RAII precisely because of it's unintuitive transfer of ownership semantics. You can achieve the same transfer with a shared_ptr, by allowing the 'first' shared_pte to go out of scopeOriginally Posted by CornedBee
"I saw a sign that said 'Drink Canada Dry', so I started"
-- Brendan Behan
Free Compiler: Visual C++ 2005 Express
If you program in C++, you need Boost. You should also know how to use the Standard Library (STL). Want to make games? After reading this, I don't like WxWidgets anymore. Want to add some scripting to your App?
I would probably prefer a combination of unique() and swap() with a null shared_ptr.
I certainly understand what CornedBee means, but despite the absence of a release() function (which makes sense of course), I believe it's possible to obtain ownership transfer without the need to use auto_ptr. Arguably, shared_ptr is an ugly choice since it makes little sense to expect transfer of ownership when working with ownership sharing, or so I seem to think. But intrusive_ptr, for instance would make a less ugly option.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
shared_ptr is fine for most things, but I just don't associate the term "transfer of ownership" with it.
With auto_ptr you signal that your library wants absolutely exclusive use of the object in question and that with passing the object to the library the user's control over it has ended, thank you very much.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law