char_traits patch, round two

[Martin Sebor]

Benjamin Kosnik wrote:

>>You're probably right that it may not have been required to be
>>defined, likely because a number of its members cannot be defined
>>for any arbitrary POD type, but I don't think the language is there.
>>
> 
> Well, yeah. 
> 
> This is why I took out the definitions that were previously in place.
> They were wrong, and in particular made too many assumptions about
> int_type being an integral type, which Jack Reeves correctly pointed out
> as an error. 
> 
> I'm not convinced they can ever be right. 


They can be right for a good number of types (definitely at least for
signed and unsigned chars), but certainly not for all at the same time.


> 
> I could be wrong, of course. Do you have a char_traits<_CharT> class
> with full member definitions, that can be generically instantiated for
> all the 27_io types, with arbitrary char_type, state_type, int_type,
> off_type, and pos_type? I'd love to see it.


Not for all combinations, obviously, that's not possible. But I think
our char_traits<unsigned char> works probably just as well as the char
specialization, and basic_string<unsigned char> will probably work
equally well.


> 
> Because of this, I'm recommending that people do explicit
> specializations on user-defined types (not native types, as you pointed
> out). This is more work for everybody, but at least it's conformant and
> portable.
> 
> I'm curious: if char_traits<_CharT> member functions can't be defined
> for arbitrary (yet standards-compliant) CharT's, how could the standard
> possibly require these definitions? I'm not following your logic.


I don't think it would be so hard. INT_T in the primary template could
be required to be the widest integer, eq() and lt() as simple
[in]equality, and eof() as INT_T (-1). That's all that depends on the
character type. All other operations are expressed in terms of those.
This would probably work for most cases. Where it doesn't, programs
would either have to specialize one or more members of provide
a specialization of the whole template. IMHO, this solution has all
the advantages of not providing the primary template at all, and then
some :)


Martin