Re: [boost] Traits-based design and ODR

From: Greg Colvin (greg_at_[hidden])
Date: 2002-04-30 13:47:12

At 07:58 PM 04/29/2002, Phil Nash wrote:
>I have been wondering (but not had time to experiment) whether a possible
>compromised approach could be to have a smart pointer type for interfaces
>where any policies that need not be exposed in the type *after construction*
>are held opaquely as runtime policies. While this may not be as efficient as
>the compile time versions, they would compliment, rather than replace, their
>richer-typed brethren.

I believe that this is what Peter's latest shared_ptr does.

>Conversion constructors for perhaps a wider range of alternative
>compile-time variants may be provided which absorb the richly-configured
>objects without losing that configuration, but only exposing the policies
>that unavoidably need to be part of the explicit type of the interface
>oriented smart pointer (for example, you would certainly want to know if a
>smart pointer featured destructive copy!)

For example, converting intrusive_ptr to shared_ptr.

My take is this:  some "policies" are really just implementation
details, which should be "hideable".  The client of a shared_ptr
need not be concerned with where the reference count is stored,
how the referenced object is destroyed, or how the memory for
the count and object is managed, so why should those details get
exposed in the name of the smart pointer type?  Using shared_ptr
those details are set when the smart pointer is constructed, and
need not be revealed to the client.  Note that this means that
the creator of a smart pointer can change those details without
requiring recompilation of its clients, and without breaking
binary compatibility.

I don't see why a policy-based smart pointer template cannot
preserve this feature of shared_ptr.