From: Alexander Gutenev (gutenev_at_[hidden])
Date: 2008-08-01 02:37:12
> Overhead of counter and deleter is exactly the same for both shared_ptr
> and
> intrusive_ptr - one per object (the fact that intrusive_ptr doesn't
> support
> Deleter at the moment is beside the point IMO - it should). Slight
> difference is
> that former is require additional new call.
Additional new call is not very little thing. Extra heap operation have its
cost. Not sure for other platforms, but with VS2005, new is roughly malloc,
malloc is roughly HeapAlloc, and Windows heap have overhead like rounding up
to multiply of 16 bytes per HeapAlloc and using additional 16 bytes per
HeapAlloc.
The reason for polymorphic deleter in shared_ptr is, IMHO, that additional
heap object is allocated anyway, so here polymorphic deleter is almost free
sugar.
For unique_ptr deleter is non-polymorphic, unique_ptr does not need
additional object by itself, so here polymorphic deleter would be an
expensive thing.
For intrusive_ptr polymorphic deleter is too expensive too. As for
non-polymorphic - this can be controlled by intrusive_ptr_add_ref
implementation.
Also, there's an alternative for custom non-polymorphic deleter: member
operator delete. For PODs or not editable classes it cannot be added, but
then inheritance from intrusive_pointee_base cannot be added too. If class
is yours, why not write operator new/operator delete for it ?