Re: user-defined types and basic_string

[Matt Austern <austern at apple dot com>]

On Friday, August 23, 2002, at 11:18 AM, Benjamin Kosnik wrote:

> > 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?
> Could do. (Unsigned int though if value_type == unsigned short, oui?)
>
> It seems int_type is one of the points where the generic templates 
> start
> to fall down...
One of several, yes.  And, as Benjamin pointed out, a design defect
in the Standard Library is that the facets require traits information 
but
don't have a traits argument.

I don't think there's any good way to deal with this: either facets 
should
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 
a good
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 
just a
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 
std::char_traits<my_char>,
and it'll be a specialization that's right, not just a generic version 
that's
almost right.

I vote for leaving the generic std::char_traits undefined.

			--Matt