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

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

From: "Ed Brey" <brey_at_[hidden]>
> "Douglas Gregor" <gregod_at_[hidden]> wrote in message
news:200207171706.05033.gregod_at_cs.rpi.edu...
> >
> > This can't be done safely:
> >
> > // Translation unit 1
> > class Foo;
> > boost::shared_ptr<Foo> f; // reference count in shared_ptr
> >
> > // Translation unit 2
> > class Foo : public boost::counted_base
> > {
> > // ...
> > };
> > boost::shared_ptr<Foo> f; // reference count in counted_base
>
> Uh oh.  We have this condition in the shared_ptr in Boost 1.28.0 as it is,
since it avoids the heap allocation when the count exists, even though it
(AFAIK) doesn't elide the counter pointer yet.
>
> I'm having trouble grasping the ramifications of this problem.  It seems
that this may have been discussed before, but I wonder if I wasn't paying
close attention.  Can you point to or provide an example demonstrating how
this breaks a program (rather than just pessimizing TU 1)?
<

It seems that I'm the only person that understands shared_ptr. :-) The above
works just fine. shared_ptr<Foo> has the same representation regardless of
whether Foo is complete, or whether it derives from counted_base. Moreover,
shared_ptr<Foo> can use either detached or intrusive counting behind the
scenes, depending on how it's constructed, regardless of the type of Foo.

And yes, if you try to elide the pointer, you'll get an ODR violation from
the above.