This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Specializations of std::char_traits
- From: Matt Austern <austern at apple dot com>
- To: "B. Kosnik" <bkoz at nabi dot net>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Thu, 17 Jul 2003 15:53:23 -0700
- Subject: Re: Specializations of std::char_traits
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