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 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.

My claims:
(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 major
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 poor
style. This doesn't affect my feelings about point 4.


--Matt

P.S. Again: if anyone thinks this discussion would be improved if we had
code to look at instead of just words, I'm happy to post a patch within a
day or so.



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