Re: [boost] [smart_ptr> C++0x unique_ptr ?

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-07-15 11:30:23

Howard Hinnant wrote:
> 
> However I did want to clarify   one bit:  sizeof(unique_ptr<int>) ==
> sizeof(auto_ptr<int>) ==  
> sizeof(scoped_ptr<int>) == sizeof(int*).  And unique_ptr<int> doesn't  
> allocate any extra memory on the heap (unlike shared_ptr, and just  
> like scoped_ptr and auto_ptr).
> 
> The deleter of unique_ptr is a "static deleter".  This is in contrast  
> to shared_ptr's "dynamic deleter".  The static deleter requires no  
> overhead unless it contains state (the default_delete is stateless).
> 

I didn't know this. I suppose this means that:
1. All code which potentially destroys a unique_ptr<T> needs to know the
complete declaration of T 
2. unique_ptr<T> can't be assigned to a unique_ptr<void>

Correct?

Statement 1 can substantially increase compilation dependencies if everybody
who passes around unique_pointers need to know the complete types even
though they never use them. This type of code is extremely common. For
instance, to expose dependencies you often have one instance of some class
and pass it all over the application instead of having a singleton. Raw
pointers, references and shared_ptr need not know the full type of the
pointer value being passed which removes alot of include statement and
thereby compilation dependencies. Can this problem be lessened by passing
around r-value references?

Statement 2 can be useful when you only care about objects' lifetimes and
never expect to use it again. I find this pattern very useful, especially
for storing a bunch of boost::signal::scoped_connection and other RAII
objects which you just want to tie to some particular objects lifetime.
Anyhow, I suppose unique_ptr<T> can be moved to shared_ptr<void> which has
dynamic destruction (and can be type erased). Am I right?  

Johan
-- 
View this message in context: http://www.nabble.com/-smart_ptr%3E-C%2B%2B0x-unique_ptr---tp18424143p18468121.html
Sent from the Boost - Dev mailing list archive at Nabble.com.