Re: [boost] Re: Re: Implicit construction in intrusive_ptr

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-18 06:01:45

From: "Ed Brey" <brey_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:017901c22daa$4bb21f10$1d00a8c0_at_pdimov2...
> > >
> > > The scenario is that there is some helper function that takes x by
> > intrusive pointer.  The poor sap who is writing fn forgets this and
thinks
> > that helper is taking x by raw pointer.  With shared_ptr, the computer
> > catches his bug (probably a serious logic error, otherwise helper would
be
> > taking T by reference).  With intrusive_ptr, this program compiles fine.
> >
> > Why is this a problem?
>
> It's more of a lost opportunity than a problem.  Any time the compiler can
catch a bug at compile time, you have a good thing.  In my example above,
the program with intrusive_ptr would compile but not work.  Based on what
you've written below, I believe we're on the same page here.
<

No, it seems that we are not. Why will this not work? Why is this a bug?

[...]

> > intrusive_ptr is a generic intrusively-counted pointer, with the
associated
> > performance implications; it can be constructed from a raw pointer (such
as
> > 'this'), and it can be used to manipulate COM objects.
>
> I agree with this.  If intrusive_ptr were used only as to represent things
like COM objets, the implicit raw-pointer construction is just fine.
However, I see an additional opportunity for intrusive_ptr, which is as a
more efficient shared_ptr, given a counted_base. (I'm using "counted_base"
as shorthand for any counting mechanism embedded within the object.)  The
more often that intrusive_ptr is used in place of shared_ptr, the more
problematic the "use at your own risk" caveat becomes.
<

"Misuse at your own risk", not "use at your own risk." It is a matter of
design philosophy. intrusive_ptr<T> _relies_ that objects of class T
interpret addref/release requests in a particular way. By using a static
object, or an object on the stack, with an initial reference count of zero
that will 'delete this' on the last 'release', you are breaking that
contract.

If you play by the rules, intrusive_ptr<> is safe, and so is the implicit
conversion.

> Perhaps the best option would be to merge the two.  Just as shared_ptr
"auto-detects" a counted base and becomes more efficient, would it not be
reasonable to take that to the next level so that shared_ptr elides is
pointer-to-count member given a counted base?
<

No. shared_ptr cannot elide the pointer-to-count member under any
circumstances, since its type doesn't change. Consider:

class X
{
public:

    virtual void f() = 0;
};

class Y: public X
{
public:

    virtual void f();
};

class Z: public X, public counted_base
{

public:

    virtual void f();
};

shared_ptr<X> px(new Y); // detached count
shared_ptr<X> px2(new Z); // embedded count