From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-07-15 03:28:29
LoÃ¯c Joly-2 wrote:
> I was wondering whether there was any plan to implement a unique_ptr in
> boost, that would replace scoped_ptr, and would default to scoped_ptr on
> compilers lacking move semantic?
While std::unique_ptr and std::shared_ptr together cover a lot of
functionality, I don't think boost::scoped_ptr should be changed or removed.
In some sense, scoped_ptr provides better static guarantees than unique_ptr.
If you see a scoped_ptr declared at function scope you can be sure that it
is deallocated when the function exits (unless someone abuses it with
get()+reset(0)). A unique_ptr might transfer it ownership elsewhere.
So scoped_ptr's type tells us something and there is probably lots of code
out there which wants to convey this information. Therefor we shouldn't
change it's semantics. Also, scoped_ptr and auto_ptr are more lightweight
since they do not have the extra level of indirection that a custom deleter
If the smart ptr library had been designed today, unique_ptr could have
replaced scoped_ptr, IMHO. The extra type information of scoped_ptr and it's
efficiency would probably not be worth the added conceptual overhead of
another pointer type. I would find more use in a smart pointers which by
type guaranteed that the value is never null. These could introduce a new
types like valid_shared_ptr or be policy-based like shared_ptr<T,
NullValuePolicy= possibly_null> (shared_ptr<T, non_null> for non-null
-- View this message in context: http://www.nabble.com/-smart_ptr%3E-C%2B%2B0x-unique_ptr---tp18424143p18459505.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk