Re: [boost] Re: Policy-based smart pointers revisited

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-01-18 06:04:20

>From: "Edward Diener" <eddielee_at_[hidden]>

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

I don't think it would be a problem as a distraction, either, any more than
the fact that std::string is a typedef for std::basic_string<char,
CharTraits = char_traits<char>, Allocator = allocator<char> > prevents
people from using std::string/std::wstring as they are, without knowing or
caring about the extra default template parameters.

Kevlin Henney has even suggested _not_ hiding the parameterisation with a
typedef, and instead use a string template directly, such as string<char>
and string<const char> (for immutable strings, may be safely reference
counted), or string<wchar_t>, now that we are more used to templates. That
specifies clearly the character type used, just like we specify the element
type in the standard containers
(http://www.cuj.com/experts/1905/henney.htm).

As an aside, it might even be possible to extend the language, so that class
template parameters may be deduced from an initialiser. In that case,
std::string str="Test"; (or std::string<> str="Test";) might create a
std::string<const char> (after implicit conversion from const char *), and
std::string wstr=L"Test" might create a std::string<const wchar_t>. In other
words, leaving the deduction to the compiler, as with function templates. If
no initialiser is given, you have to specify the parameter explicitly (or it
might default).

Granted, std::basic_string may not be such a great example of PBD, as the
"policies" are hardly changed. For example Matt Austern has pointed out that
in order to do case-insensitive string comparison, it may be better to
create a comparison functor, which may be passed to algorithms, rather than
changing the character traits. And allocators... well, as Scott Meyers says
it in "Effective STL", "Allocators are weird.", :) and the implementation
would be free to ignore parts of them.

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

You may not need named parameters, as most of the time, "canned" versions
might be fine. And if you'd like named parameters, you might use something
like the named template parameters in the Sandbox. If you want something
different from the defaults, you have to specify it, somehow.

Regards,

Terje