Thank you, I didn't realize it was already a part of the latest boost library. What I'm curious about is two things... 1) When would I choose unique_ptr<> over auto_ptr<> ? And 2) When would I choose unique_ptr<> over scoped_ptr<> ? Can somebody please provide some coding differences? If these coding examples are already documented someplace, can you please direct me to them? Thank you very much in advance. -Sid Sacek -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of OvermindDL1 Sent: Sunday, December 21, 2008 6:01 AM To: boost@lists.boost.org Subject: Re: [boost] unique_ptr, was: Composing non copyable and movable classes On Sat, Dec 20, 2008 at 3:10 PM, Sid Sacek <heavyreign@optonline.net> wrote:
I tried to locate the mentioned unique_ptr<> classes for testing, but am
unable to locate them.
Can somebody point me in the right direction please?
This is the only unique_ptr I know of: http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/interprocess_smar t_ptr.html#interprocess.interprocess_smart_ptr.unique_ptr _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sid Sacek wrote:
What I'm curious about is two things...
1) When would I choose unique_ptr<> over auto_ptr<> ?
Always. unique_ptr is the same idea as auto_ptr, but with a safe implementation.
2) When would I choose unique_ptr<> over scoped_ptr<> ?
When ownership is transferred away from the scope of allocation, either downscope (passed into a function) or upscope (returned from a function). Sebastian
Sid Sacek wrote:
1) When would I choose unique_ptr<> over auto_ptr<> ?
Always. auto_ptr is deprecated and is dangerous. unique_ptr, for example, perfectly works with containers.
2) When would I choose unique_ptr<> over scoped_ptr<> ?
Whenever you need the ability to move. You can choose to always use it instead of scoped_ptr, that's perfectly safe and doesn't add any overhead.
Mathias Gaunard wrote:
Sid Sacek wrote:
1) When would I choose unique_ptr<> over auto_ptr<> ?
Always. auto_ptr is deprecated and is dangerous.
unique_ptr, for example, perfectly works with containers.
With containers written to support unique_ptr or with any Container as defined by the standard's concept? -- Michael Marcin
On Dec 22, 2008, at 9:10 PM, Michael Marcin wrote:
Mathias Gaunard wrote:
Sid Sacek wrote:
1) When would I choose unique_ptr<> over auto_ptr<> ? Always. auto_ptr is deprecated and is dangerous. unique_ptr, for example, perfectly works with containers.
With containers written to support unique_ptr or with any Container as defined by the standard's concept?
It will work with containers written to support unique_ptr (or move- only types). std-defined C++0X containers will support move-only types. std-defined C++03 containers do not. The basic advance of unique_ptr over auto_ptr is that with unique_ptr if things compile, they will work. With auto_ptr things might compile but produce run time errors. So if your container<unique_ptr<A>> compiles, then you can use it with confidence. But it will likely not compile if it hasn't been designed to work with move-only types. This state of affairs is not nearly as mysterious as it sounds. I'd like to lift the veil a little. The reason auto_ptr is prone to produce run time errors is because generic code is often written which looks like: template <class T> void foo(T t) { T t2 = t; assert(t2 == t); } The generic code may not (probably does not) have the explicit assert as shown above. But its logic may assume that when it makes a copy, either via construction or assignment, that the source and target are equivalent after the copy. When T turns out to be an auto_ptr, then this assumption is silently broken, and thus the logic of the generic algorithm is broken. When T turns out to be a unique_ptr, the copy won't compile. Thus the breakage with unique_ptr happens at compile time, whereas the breakage with auto_ptr occurs at run time. A generic algorithm designed to work with move-only types will avoid logic that demands copies. If it needs to, it might /move/ objects around instead of copy them around: template <class T> void foo(T t) { T t2 = std::move(t); // no assumption here on the value of t } -Howard
Howard Hinnant wrote:
On Dec 22, 2008, at 9:10 PM, Michael Marcin wrote:
Mathias Gaunard wrote:
Sid Sacek wrote:
1) When would I choose unique_ptr<> over auto_ptr<> ? Always. auto_ptr is deprecated and is dangerous. unique_ptr, for example, perfectly works with containers.
With containers written to support unique_ptr or with any Container as defined by the standard's concept?
It will work with containers written to support unique_ptr (or move-only types). std-defined C++0X containers will support move-only types. std-defined C++03 containers do not.
The basic advance of unique_ptr over auto_ptr is that with unique_ptr if things compile, they will work. With auto_ptr things might compile but produce run time errors. So if your container<unique_ptr<A>> compiles, then you can use it with confidence. But it will likely not compile if it hasn't been designed to work with move-only types.
This state of affairs is not nearly as mysterious as it sounds. I'd like to lift the veil a little. The reason auto_ptr is prone to produce run time errors is because generic code is often written which looks like:
template <class T> void foo(T t) { T t2 = t; assert(t2 == t); }
The generic code may not (probably does not) have the explicit assert as shown above. But its logic may assume that when it makes a copy, either via construction or assignment, that the source and target are equivalent after the copy. When T turns out to be an auto_ptr, then this assumption is silently broken, and thus the logic of the generic algorithm is broken. When T turns out to be a unique_ptr, the copy won't compile. Thus the breakage with unique_ptr happens at compile time, whereas the breakage with auto_ptr occurs at run time.
A generic algorithm designed to work with move-only types will avoid logic that demands copies. If it needs to, it might /move/ objects around instead of copy them around:
template <class T> void foo(T t) { T t2 = std::move(t); // no assumption here on the value of t }
Sure makes sense but since we don't yet have a generic implementation of move to use no generic algorithms can really rely on it, right? This leaves me to believe the only real uses of unique_ptr right now in C++03 are 1. a more descriptive name than auto_ptr or scoped_ptr for some use cases 2. custom deleter support -- Michael Marcin
Thank you Sebastian and Mathias... Thank was very helpful and useful. Regards, -Sid Sacek -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Monday, December 22, 2008 9:05 PM To: boost@lists.boost.org Subject: Re: [boost] [unique_ptr] So how is it used differently? Sid Sacek wrote:
1) When would I choose unique_ptr<> over auto_ptr<> ?
Always. auto_ptr is deprecated and is dangerous. unique_ptr, for example, perfectly works with containers.
2) When would I choose unique_ptr<> over scoped_ptr<> ?
Whenever you need the ability to move. You can choose to always use it instead of scoped_ptr, that's perfectly safe and doesn't add any overhead. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
Howard Hinnant -
Mathias Gaunard -
Michael Marcin -
Sebastian Redl -
Sid Sacek