Tell me again what's wrong with intrusive pointers?
 

It's my understanding that intrusive pointers are frowned upon. For example
this is from the boost::intrusive_ptr documentation: "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."

This tells me that intrusive pointers are faster and leaner than any of the
other alternative other than raw pointers.
http://www.boost.org/libs/smart_ptr/smarttests.htm

To my way of thinking they are easier to use when working with recursive
data structures (trees). I was trying to use boost::shared_ptr because of
the comment quoted above, and similar comments I've read elsewhere. It
often makes sense when constructing nodes to pass the parent as a
parameter, and add `this' to the parent as a child. I tried doing that
with a shared_ptr implementation using boost::enable_shared_from_this.
When I executed the code, it threw a bad_weak_ptr exception, which traced
back to where I was trying to pass a shared_ptr to `this'. I assume the
problem is that I cannot use that feature until the object is fully
constructed and an owner is established.

If the argument against intrusive pointers has to do with not wanting to
mess with the internals of the class being pointed to, that seems obviated
by the use of boost::enable_shared_from_this. AFAIK, using shared_ptr it
is possible to establish two independent reference counts which is a
guaranteed path to disaster. That can't happen with intrusive pointers.
What are the reasons for favoring shared_ptr over intrusive_ptr?
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

Re: Tell me again what's wrong with intrusive pointers?
 

* Steven T. Hatton:
> What are the reasons for favoring shared_ptr over intrusive_ptr?

One reason is that intrusive reference counting (I don't know about the
Boost version) in general makes it possible to get away with using raw
pointers in client code. And that temptation is /very/ very strong:
it's the micro-optimization attractor, which for programmers is stronger
than the sex drive, even stronger than death-avoidance. Another reason
is that it necessitates using at least two kinds of smart pointers for
essentially the same conceptual-level purpose: non-intrusive smart
pointers for those classes that can't be outfitted with internal
reference counting, and intrusive ones, and for this, more is less.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: Tell me again what's wrong with intrusive pointers?
 

Alf P. Steinbach wrote:

> * Steven T. Hatton:
>> What are the reasons for favoring shared_ptr over intrusive_ptr?
>
> One reason is that intrusive reference counting (I don't know about the
> Boost version) in general makes it possible to get away with using raw
> pointers in client code.

With boost::shared_ptr you can do that, so in this case that doesn't apply.

> And that temptation is /very/ very strong:
> it's the micro-optimization attractor, which for programmers is stronger
> than the sex drive, even stronger than death-avoidance. Another reason
> is that it necessitates using at least two kinds of smart pointers for
> essentially the same conceptual-level purpose: non-intrusive smart
> pointers for those classes that can't be outfitted with internal
> reference counting, and intrusive ones, and for this, more is less.

With OpenSceneGraph there is a galactic base class (like a universal base
class, but not as inclusive) called osg::Referenced. If you want to use
the corresponding osg::ref_ptr, you simply derive from referenced and have
at it. There are things to be aware of such as the consequences of
deriving from osg::Referenced and not making the destructor protected, and
then putting an instance on the stack.

The problem of introducing two variants of smart pointers doesn't seem very
big in this situation. There are two kinds of things I'd be keeping track
of using the intrusive reference counting, nodes and node data. I probably
won't need shared pointers beyond those.

I can probably make the shared_ptr work if I forego trying to append the new
node to its parent in the constructor. I probably should learn to work
with it, if for no other reason, because other people seem to think it's
the way to go.

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/