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