Re: [boost] intrusive pointer, rationale for preferring shared_ptr instead.

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2006-04-12 01:53:03

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