This is the mail archive of the
mailing list for the libstdc++ project.
Re: user-defined types and basic_string
- From: Matt Austern <austern at apple dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Fri, 23 Aug 2002 11:38:37 -0700
- Subject: Re: user-defined types and basic_string
On Friday, August 23, 2002, at 11:18 AM, Benjamin Kosnik wrote:
One of several, yes. And, as Benjamin pointed out, a design defect
Could do. (Unsigned int though if value_type == unsigned short, oui?)
This makes the assumption that range(unsigned long) is a strict
superset of range(unsigned short). If we were going to assume that,
why not just use "int" as int_type?
It seems int_type is one of the points where the generic templates
to fall down...
in the Standard Library is that the facets require traits information
don't have a traits argument.
I don't think there's any good way to deal with this: either facets
somehow go around making copies and equality comparisons without
using traits (in which case the apparent freedom of users to modify
the default behavior is just an illusion) or else facets should use
std::char_traits<charT> (in which case the apparent freedom of users
to pass a non-default traits class to the stream and streambuf classes
is just an illusion). I'm not sure which is worse. I don't think it's
idea to make lots of changes in the facet classes under the assumption
that the second choice is obviously better. This is probably something
to bring up with the LWG.
But the biggest problem, I think, is that specializing char_traits is
tiny piece of the work that users need to do to write a new character
type. Seems to me that anyone who's capable of writing a specialization
std::ctype<my_char> is more than capable of writing
and it'll be a specialization that's right, not just a generic version
I vote for leaving the generic std::char_traits undefined.