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


On Thursday, July 17, 2003, at 8:28AM, Gabriel Dos Reis wrote:

"B. Kosnik" <bkoz@nabi.net> writes:

| > On the contrary, I think it does matter. int_type is supposed to be
| > provided by char_traits<>. Nobody knows whether it is used by users
| > only with iostreams. Either we provide something consistent or we don't
| > provide a definition at all.
|
| Ditto for state_type. I don't see how a truly generic char_traits can be
| done with one template parameter: I'd think (at least) three would be
| necessary.


Yeah, I thought about that too -- based on your recent changes to
pod_char_traits.   To be honest, I don't have any favorite (and I think
I can be convinced for one way or the other :-).
I also thought about using a decoupled external traits like

  template<typename CharT>
   struct int_type {
     // ...
   };

  template<typename CharT>
    struct state_type {
      // ...
    };

I don't think it's worth it. In principle, the traits parameter *is* supposed to be
the traits class saying what state_type and int_type are. Unfortunately, it got
mucked up with a whole lot of things that could be completely generic.


I agree with Benjamin: because of int_type, state_type, and eof(), it is
impossible to provide a fully general char_traits. I've set my goals lower:
make a generic char_traits that has just enough functionality so users can
instantiate basic_string for general types. Users who want to do anything
more than that can still provide their own traits class, as they have to do
today.


--Matt


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