4 ms·
> several libraries where each defines its own "Point". Same problem where each library defines its own "String". Would be nice if the standard libraries woul
by pjtr 11y ago
> several libraries where each defines its own "Point".
Same problem where each library defines its own "String".
Would be nice if the standard libraries would define such basic types and everyone would just use the same ones.
This might work better without OO kitchen sink approach to types. Just standardize a simple data layout or interface and leave the possibility for libraries to define their own functionality in extension methods.
- maxlybbert 11y agoYou do realize that std::string is 20+ years old now, right?
- deleted 11y ago[deleted]
- the_why_of_y 11y agoThe problem with std::string is, it was useless in the real world because its interface is basically unsuitable for handling Unicode. That's why every project that cares about i18n had to define its own string class to get anything done. Only with C++11 did they add std::u16string, which is at least suitable for the (horrible) UTF16 encoding. Maybe we'll get an UTF8 capable std::string class in another 20 years.
- maxlybbert 11y agoYou've always had the ability to put utf-8 data in std::strings, but you have to keep track of which strings are encoded. C++11 adds functions to convert to utf-8 (and utf-16 and utf-32), http://en.cppreference.com/w/cpp/locale/codecvt http://en.cppreference.com/w/cpp/locale/codecvt .
- pjtr 11y agoSure. That was kind of my point. Still, as Herb Sutter asked at CppCon 2015: "How many of you have your own homegrown string types at your companies? ... Don't lie. ... Right. And those of you who didn't put up your hand and are just bashful, ... we know we have them." [1] [1] https://youtu.be/hEx5DNLWGgA?t=1373 https://youtu.be/hEx5DNLWGgA?t=1373