This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: char_traits patch, round two

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

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 :)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]