Re: Char_traits (part 2+)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Benjamin Kosnik <bkoz@redhat.com> writes:

| > | typedef unsigned short unicode_type;
| > | typedef unsigned char unsigned_type;
| > | 
| > | then doing
| > | 
| > | template<> struct std::char_traits<unicode_type>
| > | {
| > | // do the work
| > | }
| > | 
| > | etc. Isn't this legal?
| > 
| > No, it isn't.
| 
| Ouch. Is it implementation-defined, or illegal?

It is undefined-behaviour since unicode_type is not a user-defined
type. 

| If it's
| implementation-defined (or undefined behavior), then can can libstdc++
| "define" it to be ok for non-required types (all !(wchar_t || char))?

That would be a possible extension, but then we should be careful about
the meaning we give it.

Sometime ago (one? two years), I was working on the char_traits<>
thingy seeking for ways to provide points-of-customization for users
-- but I gave up, being distracted by other things (and ironically
enough, I ditched the patch from my disk two weeks ago :-(( )

| If not, then I don't see any clear way out of this mess.

Deprecate char_traits<> :-)

Seriously, we may try to define points-of-customization so that the
primary template char_traits<> remains useful if some defnitions are
provided by users.  I don't know how that is better than just telling
users that GCC won't reformate their hard drive if they do the
specialization -- that however demands more typing.

-- Gaby