From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com>
"Mark Rodgers" <mark.rodgers@cadenza.co.nz> wrote in message news:002601c41836$33148560$0100a8c0@cadenza.co.nz...
IOW, traits are class templates and policies are template parameters so there really can't be any confusion between the two. So in the case std::basic_string
template<class charT, class traits = char_traits<charT>, class Allocator = allocator<charT> > class basic_string {
"char_traits" is a traits class template but "traits" is actually a policy template parameter.
That's is namely the problem I have with basic_string design. Trais class is used as policy. Actually it's even worse - char_traits contain partially functionality that may belong to some kind of policy (for example comparison method). IMO it should be separated.
std::char_traits is a traits class. It also happens that std::basic_string accepts a policy for controlling how it does various things. For expediency, std::char_traits provides the interface expected of std::basic_string's policy class. Thus, std::char_traits is used as the default policy class for std::basic_string. That doesn't stop std::char_traits from being a traits class. You can still write code that references -- without making it a template parameter -- std::char_traits<T>::foo.
It is quite reasonable for specialisations of traits templates to be used as arguments to policy parameters, which is exactly what happens when we write
std::basic_string< char,std::char_traits<char> >
But I don't think there is anything in basic_string that requires the template argument to be a specialisation of a class template. I think it would be quite legitimate to write
class MyFunkyCharBehaviour { /*...*/ }; typedef std::basic_string<char,MyFunkyCharBehaviour> MyFunkyString;
Exactly, so we could use complete different class that will define different trait values. And this is not good IMO.
There's nothing wrong with that. It is std::basic_string's interface that provides for the use of a policy class. That std::char_traits happens to be the most appropriate -- it rarely isn't -- implementation of that policy is beside the point. You can argue that std::basic_string shouldn't have such a policy parameter, and you'd probably be right, but that's not std::char_traits' fault. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;