Gabriel Dos Reis - Re: Char_traits (part 2+) (original) (raw)

This is the mail archive of the libstdc++@gcc.gnu.orgmailing 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]

Benjamin Kosnik bkoz@redhat.com writes:

| > | typedef unsigned short unicode_type; | > | typedef unsigned char unsigned_type; | > | | > | then doing | > | | > | template<> struct std::char_traits | > | { | > | // 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


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