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]

Specializations of std::char_traits


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.


But still, think about it from the user perspective: with 3.1 users were able to write std::basic_string<int>, and now, when they try, they'll get mysterious link-type errors dealing with some machinery they've never heard of and don't care about. Even if the standard doesn't guarantee the ability to have a basic_string<int>, users are bound to see this change as a regression. And, unfortunately, it's not a regression with a very good workaround. (Users can't specialize std::char_traits for fundamental types.)

What would people think of reintroducing a stub generic char_traits, one that defines just enough functionality for std::basic_string to work? That's what other compilers do. If we don't do it, I think we'll get more complaints.

(And I'll also pester the LWG issues list maintainer to open a library issue on this for C++0x.)

--Matt


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