[Development] Why can't QString use UTF-8 internally?

[Olivier Goffart]

On Wednesday 11 February 2015 10:32:31 Bo Thorsen wrote:
> This would make me very unhappy. I'm doing a customer project right now
> that uses std::string all over the place and there is real pain involved
> in this. It's an almost empty layer over char* and brings none of the
> features of QString. Of all the failures of the C++ standards committee,
> std::string is the worst.
> 
> Any string class has to be unicode. What it uses internally is an
> implementation detail (which is what started this thread). It's fine to
> have a pure ascii string type as well, but there are so few cases left
> in real world applications where this is useful.
> 
> What QString internally uses is a pure optimization question, and I'll
> leave that to others. But whatever is decided, I want to be sure it
> keeps some of the things QString offers:
> 
> 1) Unicode! Don't assume the user remembers to use utf8.
> qlabel->setText(stdString) *will* fail. Leaving decisions on encoding to
> users is a bad idea.
> 
> 2) length() returns the number of chars I see on the screen, not a
> random implementation detail of the chosen encoding.
> 
> 3) at(int) and [] gives the unicode char, not a random encoding char.
> 
> std::string fails at those completely basic requirement, which is why
> you will never see me use it, unless some customer API demands it or I'm
> in one of those exceptional cases where there is sure to be ascii only
> in the strings.
> 
> Another note: Latin1 is the worst idea for i18n ever invented, and it's
> by now useless, irrelevant and only a source for bugs once you start to
> truly support i18n outside of USA and Western Europe. I would be one
> step closer to total happiness if C++17 and Qt7 makes this "encoding"
> completely unsupported.
> 
> I know this I've made the statements here a bit harsh, but I see the
> same kinds of problems again and again in customer code, when they chose
> to use std::string all over the place. They give the same arguments I've
> seen here - optimized, faster, etc - and add a few like "easier to
> switch away from Qt, backend is std/boost only and no Qt allowed and so
> on". And they pay for it in development time, bugfixing and angry users.
> 
> Sure, QString isn't optimized for some cases. But I'll take a less
> optimized class any day over something that brings heaps of bugs. Then I
> have time to focus on optimizing the serious things instead of fixing bugs.

Again, std::string is not an equivalent of QString, it is a equivalent of 
QByteArray.
The equivalent of QString would be std::wstring or std::u16string. And those 
classes have the properties you desire.

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org