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

Re: Specializations of std::char_traits


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


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