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

From: Ed Brey (brey_at_[hidden])
Date: 2002-07-17 17:28:13

"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)?