On Fri, Jan 18, 2013 at 6:38 PM, ilya shlyakhter <ilyawebmail@gmail.com> 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.