Re: [Boost-users] intrusive_ptr vs shared-ptr

Subject: Re: [Boost-users] intrusive_ptr vs shared-ptr
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-01-23 12:17:25

On Fri, Jan 18, 2013 at 6:38 PM, ilya shlyakhter <ilyawebmail_at_[hidden]>wrote:

> Dear Boosters,
>
> The documentation of intrusive_ptr says
>
> "As a general rule, if it isn't obvious whether intrusive_ptr better
> fits your needs than shared_ptr, try a shared_ptr-based design first."
>
> but does not explain why.
>
> If the classes involved are all my own and deriving them all from a base
> class
> that implements reference-counting is not a problem, what are some reasons
> to prefer shared_ptr to intrusive_ptr?
>
> Thanks,
>
> Ilya
> _

Not sure if this has been mentioned, but an intrusive reference count can
been seen as inherently ("philosophically") wrong - it is an external
value, not an essential value of the class:

class MyRefCount {... };

class Foo : MyRefCount { ... };

Foo foo;

does it make sense to ask what the ref count on a static or stack allocated
Foo is?  Taking intrusive_ptr or a shared_ptr on a non-allocated object is
wrong in either case, but only intrusive_ptr makes it part of the class.  A
non-shared Foo has an unused reference count - maybe not a big deal in term
of efficiency, but only philosophically.
Or do you hide the constructor and make a factory function - so you can
never have a Foo outside of an intrusive_ptr?

Having said all that, I actually often prefer intrusive_ptr:

- easy binary interface (ie exposing objects from DLLs) as the
intrusive_ptr_add_ref(Foo) is easily exported.
- easier to use than enable_shared_from_this.