Re: user-defined types and basic_string

[Benjamin Kosnik <bkoz at redhat dot com>]

> Here is a minimal list of things where the primary template
> char_traits<> breaks down:
> 
>   (1) int_type
>   (2) less-than comparaison
>   (3) equality comparaison
>   (4) conversion char_type -> int_type
>   (5) conversion int_type -> char_type
>   (6) end-of-file mark
> 
> (1) has to be supplied by users.  Suppose, it is given by
> 
>    namespace __gnu_cxx
>    {
>       template<typename charT>
>         struct __char_traits_int {
>           typedef <user-supplied-type> type;
>         };
>    }
> 
> (2) and (3) may be supplied in various ways
> 
>    * either by std::less<> and std::equal_to<> (not really a
>    solution)o* by function objects
> 
>      namespace __gnu_cxx
>      {
>         template<typename charT>
>           struct __char_traits_eq {
>             bool operator()(charT a, charT b) const
>             { return a == b };
>           };
> 
>        // similar for char_traits_lt<>
>      }
> 
> In the same way (4), (5) and (6) can be given by function objects.
> Now, equipped with the above, one can give a general definition for 
> char_traits<> without having to always define *every* member
> function.  That will work for fundamental types as well as
> user-defined types.
> 
> 
>    template<typename _CharT>
>      struct char_traits {
> 
>        typedef typename __gnu_cxx::__char_traits_int<_CharT>::type
>        int_type;// ...
> 
>        bool
>        lt(const _CharT& __a, const CharT& __b)
>        { return __gnu_cxx::__char_traits_eq<_CharT>()(__a, __b); }
>      
>        // ...
>      };

Hmm. I like this idea better than the alternate idea presented by Jack
Reeves, which was to provide std::char_traits specializations for all
integral builtin types, but no generic template definitions. 

The other idea, of course, is to do nothing and let the present code
stand. I'm inclined to side with Matt here, and leave std::char_traits
generic undefined.

The solution sketched by Gaby seems more transparent, but doesn't buy
much more flexibility in the standard library, as
std::char_traits<unsigned short> will still be undefined, caught between

21's seeming willingness to allow a wide pool of "character" types (POD
union builtin integer types) wile only explicitly specifying two,
std::char_traits<char> and std::char_traits<wchar_t>

and

17.4.3.1 - Reserved names [lib.reserved.names]

-1- It is undefined for a C++ program to add declarations or definitions
to namespace std or namespaces within namespace std unless otherwise
specified. A program may add template specializations for any standard
library template to namespace std. Such a specialization (complete or
partial) of a standard library template results in undefined behavior
unless the declaration depends on a user-defined name of external
linkage and unless the specialization meets the standard library
requirements for the original template.

Personally, I'm of the opinion that things like some_template<unsigned
short> should be useful because I find the aggregate notation implied by
user-defined POD types to be extremely awkward. This is, however, a
expressly unportable way of thinking, and thus not useful to people
who have to deal with portable C++ code.

-benjamin