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