On Monday 10 April 2006 21:59, Peter Dimov wrote:
One reason for the "try shared_ptr first" recommendation is that while intrusive_ptr's advantages are usually obvious to developers, its disadvantages and shared_ptr's advantages are not. They became evident at a later date.
Okay, that's something I understand now. Anyhow, as David suggested, it might be worthwhile to sum up what their (dis)advantages are. For completeness, I'd also include std::auto_ptr. shared_ptr: - Size of the shared_ptr object itself is two pointers. - One additional allocation overhead for shared count, weak count and deleter function pointer (I'm just guessing, is that right?) Further, size is how much? Does it have a specially adapted allocator for those? - Additional freedom with custom deleters. - Allows various type conversions (like raw pointers), including to void or other incomplete types. - Allows weak references (i.e. observers rather than owners) via weak_ptr. - Can be constructed from auto_ptr. - Can be retrieved via 'this', but this requires additional overhead (enable_shared_from_this) in the object itself. intrusive_ptr: - Size of intrusive_ptr object itself is one pointer. - No additional allocation overhead, but space of the refcounter needs to be provided by the object itself (typically one pointer's size). - Can be integrated with existing reference counters (like e.g. COM objects). - Can be converted from/to raw pointers without disadvantages, in particular using 'this'. - Can not be converted like a pointer (upcasting/downcasting) as freely as shared_ptr. std::auto_ptr: - Size of auto_ptr object itself is one pointer (with GCC 4's libstdc++). - No additional overhead since not refcounted. - Can not be instantiated with incomplete types. This works with some implementations as long as at the dtor's instantiation the type is complete but that is not guaranteed by the standard. - Peculiar copying/assignment semantics that assure exclusive ownership but are confusing at first and make it unusable in standard container classes. Uli