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 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 21.1.3.1 and 21.1.3.2), but I believe users are entirely on
> their own if they try to instantiate std::char_traits for any other 
> types.

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.

Nathan Myers
ncm-nospam@cantrip.org


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