smart-pointers

First take a look at what C++ Primer said about unique_ptr and shared_ptr : $16.1.6. Efficiency and Flexibility We can be certain that shared_ptr does not hold the deleter as a direct member, because the type of the deleter isn’t known until run time. Because the type of the deleter is part of the type of a unique_ptr , the type of the deleter member is known at compile time. The deleter can be stored directly in each unique_ptr object. So it seems like that the shared_ptr does not have a direct member of deleter, but unique_ptr does. However, the top-voted answer of another question says: If

Free function allocate_shared can be used with any standard compliant allocator. But what about shared_ptr's constructor and reset method. template<class Y, class D, class A> shared_ptr(Y * p, D d, A a); template<class Y, class D, class A> void reset(Y * p, D d, A a); The manual says that D should provide a call operator which will be used to delete the pointer and A must be a standard compliant allocator. If so, why D is needed? Can't A do both allocation and delocation? Don't you think that the requirement to provide a deleter for every custom allocator makes the above methods pretty much

To implement reference counting we use an IUnknown -like interface and a smart pointer template class. The interface has implementation for all the reference-count methods, including Release() : void IUnknownLike::Release() { if( --refCount == 0 ) { delete this; } } The smart pointer template class has a copy constructor and an assignment operator both accepting raw pointers. So users can do the following: class Class : public IUnknownLike { }; void someFunction( CSmartPointer<Class> object ); //whatever function Class object; someFunction( &object ); and the program runs into undefined

Within my code I follow two rules when it comes to intrusive_ptrs: Passing a raw pointer by value implies that the raw pointer is guaranteed to be valid during the lifetime of that function. If the raw pointer is to be stored and used beyond the lifetime of the function, it should be stored in an intrusive_ptr. Many Internet commenters have written that shared_ptr should be preferred over intrusive_ptr except when working with third party code. However, intrusive_ptr obviates passing around smart pointers since you can create an intrusive_ptr from a raw pointer, as when the object is needed

I'm reading Effective Modern C++ by Scott Meyers and he's discussing the use of the pimpl idiom and pointing to the implementation class with unique_ptr , but there is an issue of special member functions (such as destructors) requiring the type to be complete. This is because unique_ptr 's default deleter statically asserts whether the type to be deleted is complete, before delete p is used. So any special member functions of the class must be defined in the implementation file (rather than being compiler-generated), after the implementation class has been defined. At the end of the chapter,

I just saw this nice copy-on-write pointer implementation. It looks pretty generic and useful, so my question is: Is such a class contained in any of the C++ toolkits (boost, loki, etc.)? If not, I'd really like to know why because it is a really useful idiom and apparently a generic implementation seems doable (like the one I linked to). There was a lot of debate over the possibility, and at least one suggested version of what eventually came out as auto_ptr was for a reference counted COW pointer. Unfortunately, the time for COW has mostly passed. Making a COW pointer (or COW-whatever)