Re:Fashionable Problems
by ahartmetz on Monday December 23, 2019 @07:36AM
(#21863234)
AFAICS D screwed up with its "optional" but really not optional if you want to use the standard library garbage collection. Rust contains no such mistakes, and seems to contain fewers mistakes than C++. Any experienced C++ programmer should know that C++ contains plenty of mistakes. Exceptions are very awkward, the string class is useless, hash maps are much slower than they could be (the std API enforces that), modules should have appeared 20 years ago, non-const references as stealth pointers are bad for readability, [...]
[ Parent
| on HN ]
Why C++ string class is useless?
It's basically no better than vector<my_char_type> - i.e. it has no Unicode support whatsoever and very few string-specific convenience methods. Using algorithms is possible, but tedious.
Because I often work with Qt, I'm comparing it with QString, which is much more than a vector of chars. https://doc.qt.io/qt-5/qstring.html
Well, you just kinda answered your question. There is STL, Qt and Boost. Like all other languages. They do the same thing but in different capacities, you should select based on your needs. I think std::string can be supplemented for Unicode support, I am gonna say the fmt library was the supplement but I feel like I am wrong.
I used std::string and QString extensively for 4-5 years and find QString inexplicably bloated and un-intuitive for my use cases.
I don't understand your problem with QString, but anyway, AFAIK the common way to get Unicode support with std::string is ICU. ICU is quite large (~15-20 MB binary) and it breaks binary compatibility with every release.
I don't do C++ anymore professionally, but from I remember, std::locale was very useful: https://en.cppreference.com/w/cpp/locale
And QString had no magic to it other than wrapping its underlying data in ytf-16 which std::u16string does too.
It's not perfect but it gets the job done, IIRC.