[boost] Re: Re: Numeric conversions lib comments

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-03-26 13:37:20

"Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]> wrote in message
news:35C251B635189944B65CAB923470EA9601FEC600_at_execmail.apps.ilx.com...

>
> I don't say I like it either. Major issue with basic_string design
IMO is
> that char_traits is template parameter

<snip>

> Here is how I see it. Trait is something type specific, IOW specific
to
> type, IOW  uniquely defined by type. If you could provide trait
along with
> the type as a template parameter, that mean you could change it
> independently from the type, IOW you could define different value
for trait
> still using the same type. For example if you have component C
defined like:

<snip>

> On the other hand policy is something that is orthogonal to the
primary type
> (actually in policy based design there may not be any primary type,
but just
> an orthogonal policies), IOW you could use different policies in
> conjunction with the same type. And natural place for the policy is
along
> with type in component definition among the template parameters.

This is probably the best characterization of the traits/policy
distinction I've heard. I don't agree entirely about basic_string,
however; I think that the comparison functions such as
char_traits::compare have to be made available through template
parameters, otherwise you wouldn't be able to reuse basic_string if
you want strings with different comparison criteria. Most of the stuff
in char_traits, such as the typedefs, copy, move, to_int_type, eof
could go in a genuine traits template, so that basic_string would look
like this:

       template<typename Ch, typename Comp = std::char_compare<Ch> >
       class basic_string;

This wouldn't make a practical difference for strings, but it might
mean that iostreams wouldn't need traits parameters at all -- I
haven't verified this -- which would be a huge advantage.

Jonathan