[boost] Re: Policy-based smart pointers revisisted (was: Re: Preliminarysubmission: command line & config file library)

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-01-18 01:25:08

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u65snyw6o.fsf_at_boost-consulting.com...
Terje Slettebø <tslettebo_at_[hidden]> writes:

>>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.
>>
>> 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...> {};
>
> etc.
>
> However, I also understand the concern regarding understanding the
policies
> available, their responsibilities and interaction. Therefore, convenience
> templates like the above could make it easier to use them, while still
> allowing new convenience templates/template typedefs to be made, or new
> policy implementations added.
>
> Having such convenience templates is a bit like having a small
configuration
> DSL on top of the policy-based smart pointer, to use the terminology in
C&E.

-Sure, and I expected we'd do that.  Not to beat this horse to death,
-but I think even that doesn't insulate users from the parameters
-completely.  They'll see it in the documentation, and wonder what's
-going on under the covers with all that complexity, and it will be a
-distraction.

I don't think that is the distraction.

The biggest problem with policy-based template classes is the same as the
problem with functions which have many default parameters: it's difficult to
set just one somewhere in the middle because one must know the reasonable
defaults for everything preceding it. This is a weakness in C++ itself, in
the default parameters system. Previous to template classes it hasn't been
much of an issue since there has been little need to design functions with
many default parameters. However with template classes and the "policy" idea
this weakness really crops up. Policy-based template classes would work fine
if one could choose to set a particular policy within a choice of policies
of a given type without having to worry about any other policy types. But
with the method of specifying default parameters, whether for functions or
types in a template class parameter list, the idea of policy-based template
classes is much less effective simply because it becomes much harder to use
for the end-user. There is something to be said for ease-of-use for template
classes as for anything else.

I wonder if there have been any murmurs in the C++ standard committee about
the system for setting default parameters somehow being changed to solve
this problem, so that a user can override a default without having to
override all preceding ones. I know I have heard suggestions about named
default parameters but that doesn't seem to solve the problem in my mind.
Something clearer and cleaner is needed but I don't know what it is.