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---tp18424143p184681... Sent from the Boost - Dev mailing list archive at Nabble.com.