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.
- 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.
- 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
- Can not be converted like a pointer (upcasting/downcasting) as freely as
- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk