At 07:33 AM 1/18/2003, Peter Dimov wrote:
>From: "Terje Slettebų" <[EMAIL PROTECTED]>
>> >From: "David Abrahams" <[EMAIL PROTECTED]>
>> >
>> > 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
