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 requires. 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 version). Johan -- View this message in context: http://www.nabble.com/-smart_ptr%3E-C%2B%2B0x-unique_ptr---tp18424143p184595... Sent from the Boost - Dev mailing list archive at Nabble.com.