Re: [boost] smart pointer compatibility

From: Greg Colvin (greg_at_[hidden])
Date: 2002-05-01 19:09:43

At 12:21 AM 05/01/2002, Andrei wrote:

>> What does that cost the user?
>
>> Binary compatibility.  
>
>Only both a) policy based smart pointers together with 
>b) one standard way to define and use a default smart pointer 
>for a specific type will be an acceptable solution.

'Only' is a strong word, as I'm not yet convinced that
boost::shared_ptr is not acceptable.

I haven't done a full comparison, but suspect that our
shared_ptr can cover a lot of same territory as Loki smart
pointers, and perhaps some new territory as well.  What it
lacks is the abstraction and orthogonality of a policy-based
design.  I am not yet convinced that such abstraction is
needed, or that it can be provided in a way that maintains
compatibility as well as shared_ptr does.

Right now, you can customize shared_ptr in three main ways.

First, you can customize how the shared object is destroyed
at construction time, without affecting the type of the
shared_ptr.  E.g. shared_ptr<FILE>(f,fclose)

Second, you can derive your type from the boost counted_base,
or from any other compatible base class and use intrusive_ptr.
If you use or derive from the boost base class you can convert
the resulting intrusive_ptr to a binary compatible shared_ptr.
If you provide your own class you can customize add_ref and
release. 

Third, you can provide your own smart pointer types that derive
from, delegate to, or are convertible to shared_ptr.  Such a
wrapper could even be a policy-based smart pointer.

Finally, there are other hooks for shared_ptr customization,
down in the details, that we have not yet exposed.