Re: [boost] Policy-based smart pointers revisisted

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-01-18 12:55:53

At 07:33 AM 1/18/2003, Peter Dimov wrote:
>From: "Terje Slettebø" <tslettebo_at_[hidden]>
>> >From: "David Abrahams" <dave_at_[hidden]>
>> >
>> > Please don't take this to mean I'm against a
>> > policy-based smart pointer; quite the opposite.  I've
>> > said all along it would be great to have one in boost.
>> > I've even wished I had an appropriate occasionally.
>
>Yep.
>
>> > I just don't want to trivialize what I perceive to be
>> > valid concerns, either.  Understanding the costs of
>> > complexity should be as important to the designer of
>> > policy-based classes as to everyone else, if not more
>> > so.
>>
>> I understand the concern. For one thing, we don't have template typedefs,
>> yet, although me may get a similar effect (if not the same type) with
>e.g.:
>>
>> template<class T>
>> struct shared_ptr : smart_ptr<T, policies...> {};
>
>Not quite.
>
>It is not simply declaration complexity that Dave's talking about - it can
>be avoided by making smart_ptr<T> be shared_ptr<T> by using default
>parameters. It is semantic complexity. shared_ptr is fairly deep by itself
>(and getting the specification and the tests to a state that can be
>considered adequate wasn't easy.)

One aspect of the semantic complexity that bothers me
is that the various flavors of smart pointer may not
be interchangeable.  shared_ptr is partly parameterized
on implementation, but the interface and semantics
remain the same.  For a policy-based smart pointer
to be usable I think you need a clear set of concepts
that clients can use as requirements, and a clear
delineation of which combinations of policies support
which concepts.