Re: [boost] Traits-based design and ODR

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-04-30 14:54:58

At 02:47 PM 4/30/2002, Greg Colvin wrote:

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

Not only that, but given the discussion current discussion to the effect 
that the policy-based smart pointer template default policies should 
be  chosen for good third-party library interface interoperability, the 
current Colvin-Dimov shared_ptr semantics are probably pretty close to what 
the smart_ptr default policy semantics should be.

--Beman