Re: [boost] smart pointer compatibility

From: Greg Colvin (greg_at_[hidden])
Date: 2002-05-01 12:02:38

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.  People can customize
certain aspects without sacrificing binary compatibility,
and we plan to allow them to customize more, perhaps by
exposing a new constructor, or a custom_ptr template.

Another form of compatibility is construction or assignment
compatibility.  For example, you can take an object using
COM reference counting, do one AddRef, and put the pointer
to the object in a shared_ptr.  You tell the shared_ptr
to do a Release in it's destructor, and reduce the overhead
of the virtual, or even remote, AddRef and Release calls.

Binary compatibility is assured by providing a common base
class for the counter class, but users can substitute their
own base class if they wish.  And even then they can
maintain binary compatibility of various customizations
that share their base class.

Even more aspects can be customized by wrapping shared_ptr,
via delegation or inheritance.  By making the inheritance
public, and/or providing appropriate operators, construction
and assignment compatibility can be provided as well.

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 have not been convinced that such abstraction is
needed, or that it can be provided in a way that maintains
compatibility as well as shared_ptr does.