
Gottlob Frege wrote:
On Fri, Jan 18, 2013 at 6:38 PM, ilya shlyakhter
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.
To me, it does not make sense for Foo to have an intrusive pointer if it is intended to be created on the stack or statically. So I would use intrusive pointer only if objects were to be created on the heap (otherwise I'd use a linked (non-intrusive) pointer). And I agree the intrusive count should not be public. Louis.