[boost] Re: shifted_ptr review

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-10 19:42:54

cppljevans_at_[hidden] wrote:
> On 10/01/2003 02:49 PM, Gregory Colvin wrote:
>> It's an important feature of shared_ptr that it doesn't care how the
>> pointee gets allocated.  So one could use the shifted_ptr allocation
>> strategy with shared_ptr, and get the advantages of co-allocating the
>> pointee and the count.  But what you couldn't get is the smaller
>> size of shifted_ptr, because there is no way to tell shared_ptr how
>> to navigate from the pointer to the associated count.
> Which raises a con not mentioned in the "Rationale" in
>    shifted_ptr/libs/smart_ptr/doc/index.html
> in
>    http://groups.yahoo.com/group/boost/files/shifted_ptr.zip
> This con is that shifted_address<I,J> will work correctly only
> for the case where I != J.  This is because when I == J,
> the class is not polymorphic and then:
>   template<typename U> shifted_address<I,I>::get(U*a_p)
> returns:
>    (a_p - offset(sizeof(shifted_header) + shifted_header::s_padding));
> which is incorrect when a_p does not point to the start of the
> memory block, which is the case in the following code where pb is
> created:
>
>    struct A{int a;};
>    struct B{int b;};
>    struct C: public A, public B{virtual ~C(){}};
>    shifted_ptr<C> pc(new (so) C);
>    shifted_ptr<B> pb(pc);
>
> another con is that when the instance is polymorphic, dynamic_cast
> is called to get the header, which is a virtual function call.
> This call is made each time the reference count is decremented
> or incremented for a polymorphic instance, AFAICT.

Exactly, I was currently implementing the "real-time" collector (destructs
objects instantaneously upon cyclic references) before redocumenting it.  I
am glad you point those out.

I wouldn't call those "con"s because as for the first issue, similar
problems will occur if you cast a shared_ptr<C> -> shared_ptr<B> & C * -> B
*: there is no way to destruct the objects correctly after the hidden
address shift.  The second one truly calls a virtual function but it is
really negligeable, believe me.

I would vote to implement garbage collection for its true purpose: immediate
speed.  You will find a good document about it here:
http://www.hpl.hp.com/news/events/csc/2003/boehm_slides.pdf

Regards,

Philippe