Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk