This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Specializations of std::char_traits
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Matt Austern <austern at apple dot com>
- Cc: "B. Kosnik" <bkoz at nabi dot net>, libstdc++ at gcc dot gnu dot org
- Date: 18 Jul 2003 09:19:21 +0200
- Subject: Re: Specializations of std::char_traits
- Organization: Integrable Solutions
- References: <783E33E4-B8A9-11D7-9066-000393B2ABA2@apple.com>
Matt Austern <austern@apple.com> writes:
| 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.
Yes, and any compiler intended to be used with libstdc++-v3 would have
already failed if it couldn't handle namespaces.
I think char_traits is good to use because:
1) it is already a reserved named; we don't need another level of
uglification
2) it represents our view of the standard char_traits could have
been; __gnu_cxx::char_traits is a parallel of std::char_traits.
For GNU extension, using uglified names for types or functions we
intend users to potentially use may create the confusion that the can
do the same for any other uglified names. That is why I didn't
suggest uglified name for the decoupled type traits.
The rest of the patch looks right to me except that part.
-- Gaby