This is the mail archive of the
mailing list for the libstdc++ project.
Re: Specializations of std::char_traits
- From: Matt Austern <austern at apple dot com>
- To: Nathan Myers <ncm-nospam at cantrip dot org>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Wed, 16 Jul 2003 14:18:08 -0700
- Subject: Re: Specializations of std::char_traits
On Wednesday, July 16, 2003, at 01:11 PM, Nathan Myers wrote:
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.
I'm having trouble reconciling these two paragraphs. The first says
there's a requirement in the standard that char_traits<T> be
instantiable for arbitrary T, the second says that we should not have
such a char_traits<T> except as a nonstandard extension.
(1) There is no requirement that std::char_traits, or any of the
templatized facets, be instantiable for any types other than
char or wchar_t. About the only argument I can offer in favor
of this claim: I couldn't find any such requirement. I also
don't think it's the sort of thing that could be hidden away.
Any such requirement would have to say what the typedefs for
std::char_traits<long> are defined as, and what the member
functions do. I don't think I could have missed text like that.
If you (or anyone else) can show me that requirement and that
specification, then of course I'll change my mind.
(2) As a consequence: we are conforming if we define the primary
template for std::char_traits as an incomplete type, or as a
class with no members, or as a class with useless members, or
as a class with members that are actually useful. At the moment
we define it in such a way that you don't get compile errors but
do get link errors, which I claim is conforming but poor quality.
(3) This is probably a mistake on the part of the standard. It should
be more explicit about which types you can instantiate char_traits
with, and it should be possible to instantiate std::basic_string<T>
at least for integer types. (I don't demand the ability to write
std::basic_string<vector<char> >, or std::basic_string<float>;
those things are just silly.) Rationale: this is existing practice
for most implementations, and a standard should take existing
practice into account.
(4) We should support this usage even in the absence of a change to the
standard. Rationale: it was supported in 3.1. I simply can't see
any way in which it's doing users a favor to take away something
that used to work for them and that still works on every other
implementation. From users' point of view this is a regression: a
working feature was taken away without warning.
For the record, I agree with Nathan that std::basic_string<short> is
style. This doesn't affect my feelings about point 4.
P.S. Again: if anyone thinks this discussion would be improved if we
code to look at instead of just words, I'm happy to post a patch within
day or so.