Re: char_traits patch, round two

[Benjamin Kosnik <bkoz at redhat dot com>]

> 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. 

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.

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.

-benjamin