This is the mail archive of the
mailing list for the libstdc++ project.
Re: Specializations of std::char_traits
On Wed, Jul 16, 2003 at 12:12:41PM -0700, Matt Austern wrote:
> On Wednesday, July 16, 2003, at 11:11AM, Nathan Myers wrote:
> >On Tue, Jul 15, 2003 at 04:39:04PM -0700, Matt Austern wrote:
> >>We've received several complaints from customers who noticed that
> >>std::char_traits<int> (or long, or signed char, or unsigned short, or
> >>whatever) used to be defined but isn't defined anymore.
> >>Now, just to be obvious, I realize that
> >> - The C++ standard doesn't say there should be any specializations
> >>other than char and wchar_t
> >> - In general there's no way to define all of the members of
> >>std::char_traits for an arbitrary type. There's no good way to say
> >>what char_traits<T>::int_type should be, for example.
> >As I recall, the standard requires a default definition of
> >char_traits<T> for any T. (I recall the vote in favor, which I
> >opposed, if mildly.)
> Yes and no. There must be a class template std::char_traits<T>
> (there has to be a primary template to specialize!), but I don't see
> anything in the standard saying that the primary template has to
> have any of the members found in table 37. In fact, I'm not even
> convinced there's a requirement that the primary template has to
> be instantiable.
That was the status quo before the vote.
> The standard is quite explicit about the member functions in the
> std::char_traits<char> and std::char_traits<wchar_t> specializations
> (clauses 188.8.131.52 and 184.108.40.206), but I believe users are entirely on
> their own if they try to instantiate std::char_traits for any other
That would mean that the proposal was voted in but never actually
edited into the standard. That would be interesting, if true.
(But I suspect that the requirement is cleverly buried somewhere.)
I don't see any value in supporting char_traits<short>, in any case.
Anything that can be accomplished by that means can be done portably
and with less risk using char_traits<MyCharType>. That is what we
should document. If we did add a default definition for built-in
types, I would hope that users would need to include a non-standard
header to use it, so they would know that they are using an extension.