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
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