"Rozental, Gennadiy" <gennadiy.rozental@thomson.com> wrote in message news:35C251B635189944B65CAB923470EA9601FEC600@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:
On the other hand policy is something that is orthogonal to the
<snip> 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