Re: Specializations of std::char_traits

[Matt Austern <austern at apple dot com>]

OK, this isn't quite the promised patch (I haven't done any nontrivial 
testing, and I haven't written test cases), but at least it's enough to 
people can see what I'm talking about.

I've combined the two suggested approaches: making the generic 
std::char_traits a thin wrapper around a class defined in __gnu_cxx, 
and separating out the types so it's easy to override them alone.

Two possibly controversial design decisions:
 1. I named the __gnu_cxx class "char_traits".  Rationale: why not?  It 
really is char_traits, so I couldn't think up a good reason to make up 
another name.  It's not as there's any reason nowadays for us to care 
about obsolete compilers that can't handle namespaces.
 2. I deliberately avoided standard algorithms like std::copy and 
std::fill_n.  Rationale: at present, bits/char_traits.h is almost 
self-contained.  It depends on <cstring> and bits/fpos.h and nothing 
else.  I don't want to introduce a new dependence unless there's a very 
strong reason for it.

But modulo stupid typos and such, do people think that what I have here 
is the right general approach?

			--Matt

Attachment: ct.txt
Description: Text document