KDE Now Maintaining Their Own Set of Patches For Qt 5

[lowflyer]

Where are you going with this? STL simply was not an option when Qt was being developed so they wrote their own library functionally similar to STL. What does this have to do with standardization?

Well, you chimed into this discussion with this statement:

Qt was developed before STL became a thing so they had do roll their own standards.

Both, Qt and the STL were developed at around the same time. The trolls should have looked around to see how others address this common problem. Instead they ran just with the limited set of idioms they had acquired: Java. The notoriously most stupid decision in any software project is "to roll their own "standard"". They have done similar mistakes in other areas (null string != empty string, qmake, QBS). I find it upsetting that they seem to be ignorant about standards development. The standards and Qt have evolved since. But Qt has remained in their errors.

You're still not getting it. It's all about guarantees. When you see a std::wstring, you cannot make any assumptions about the kind of data it contains. The fact that wchar_t is implementation-defined pretty much disqualifies it from any kind of multiplatform use. This is why C++11 introduced std::u16string and std::u32string. These at least guarantee the size of the character type. However, they still don't prescribe encoding.

QString provides both guaranteed character size and prescribes UTF-16 encoding. This allowed Qt to have consistent string handling across all supported platforms. STL still doesn't do that even in 2021. It also enabled Qt to implement a lot of additional stuff like locale-aware comparisons, case conversions and other convenience functions for text manipulation. You cannot do that unless you have a well-defined string representation.

I think I see your point. You put a high emphasis on multiplatform. And I should have pointed out std::u16string as the equivalent of QString.

You don't seem to get what I try to point out: QString does not handle UTF-16. What it handles is UCS-2. The Qt documentation tries to get away with saying "each QChar corresponds to one UTF-16 code unit". This is only a 16 bit unsigned value - not the same as a "Code Point".

If you compare the equivalent types, the guarantees of Qt are no better than the STL. Do not compare char with QChar. Furthermore, the STL provides wchar_t that does not exist on Qt. Strings from that type handle UTF correctly. You correctly point out that wchar_t is not 100% multiplatform, but with the STL it's easy to define a type that is: std::basic_string<u32char_t>. You'll struggle to get that with Qt.

Let me show you where QString falls flat:

"😎 = \U0001F60E is B-)"

This is a string that contains exactly 12 code points. Observe that Qt counts 14 characters which is not correct.

See for yourself with the following code:

#include <iostream>
#include <QString>
#include <string>

int main()
{
    std::wstring const wstr{L"😎 = \U0001F60E is B-)"};
    QString qstr(QString::fromStdWString(wstr));
    std::cout << "wstring size:" << wstr.size() << " QString size:" << qstr.length() << "\n";
}

The inevitable consequence is that all the shiny "locale-aware comparisons, case conversions and other convenience functions for text manipulation" become unusable as soon as you have emojis or Asian languages in your QStrings. Well, you're still "multiplatform". But with that, Qt falls flat on all platforms. Note that microsoft compilers deliver the same wrong result: 14. And also note that std::wstring (on non-microsoft platforms) did handle that correctly since the dawn of time.

Another point of annoyance: From Qt5 until somewhere in the middle of Qt5, the standard binary installation of Qt included a version of libicu. Initially this lead me to think that QString handles UTF correctly. But I had to learn the hard way that it does not despite including the resources to do it correctly.

[ssokolow]

[...]

That may be true, but I get the impression you're seeing UTF-32 as more useful than it actually is.

• Let's Stop Ascribing Meaning to Code Points
• Dark corners of Unicode

This stuff is the reason that Rust chose UTF-8 as its internal string representation and people use the grapheme cluster iterator from unicode-segmentation a lot more than interacting directly with the char type. (See also the UTF-8 Everywhere manifesto.)

[JackLilhammers]

lowflyer
I don't know if you meant Microsoft compilers or compilers on Windows in general, but wstr.size() == 14 even with mingw.
In your example the standard library outputs the right number, but not always.
In this particular case Qt may be worse that the standard library, depending on the platform, but imho it's not enough to say that they should drop QString (and I'm not even taking into account the implicit sharing) and it's surely not enough to drop Qt as a developer.
Also, there are graphemes represented with more than one code point, so the number of code points isn't always a meaningful information.

PS: About the empty string being equal to nullptr I totally agree, it's bad design.

ssokolow
Qt has QTextBoundaryFinder to iterate over grapheme clusters: https://doc.qt.io/qt-5/qtextboundaryfinder.html

[lowflyer]

ssokolow
Sorry for that impression. While I prefer UTF-8 for nearly anything, there are use cases for UTF-32. Thanks for the links. It was a really interesting read.

JackLilhammers
I'm not in a position to test every compiler on every platform. What I directly tested was:

• microsoft compiler on windows
• GCC on Linux

I also tested on godbolt.org

• clang
• gcc
• microsoft compilers on Wine x64 and x86
• icc
• webassembly
• arm, mips, power on gcc and clang

I found the results to be consistent with the definition on cppreference.com:

wchar_t - type for wide character representation. Required to be large enough to represent any supported character code point (32 bits on systems that support Unicode. A notable exception is Windows, where wchar_t is 16 bits and holds UTF-16 code units) It has the same size, signedness, and alignment as one of the integer types, but is a distinct type.

The mingw compiler apparently defines the flag "-fshort-wchar" which makes the wchar_t type 16 bit. I found also a discussion about "-no-fshort-wchar not working" that reasons microsoft compatibility.

I'm not hinting to "drop QString". But we have to be aware of its limitations and not blindly assume unicode support. Your link to QTextBoundaryFinder is really helpful. You may also notice the reason why the Copperspice guys did not copy QString, but created CsString

[MadCatX]

lowflyer
I'm only stressing multiplatformity because that is Qt's biggest selling point. If you seek to target only one platform, Qt doesn't give that much better value than other toolkits (or a reasonable combination of multiple toolkits).

I still don't get your argument about STL vs. Qt library. When project A and B are developed at the same time, project B cannot really use project A if project A is not ready yet. I've already said it multiple times in this thread, there were only a few months between first STL public release and Qt public release. At that time nobody really knew how would STL pan out. It wasn't a standard, it wasn't well supported, it wasn't fast.

Take a look at how many platforms Qt1 supported when it was released. The list is actually longer because the commercial Qt1 included support for Win32. The list continued to grow until about Qt3. One of the reasons why Qt could achieve this level of multiplatformity was because it was very self-contained. The more you rely on 3rd-party code, the more likely you are to have to work around somebody else's bugs and STL is a pretty huge chunk of 3rd-party code to rely on. It also wasn't until C++11 when the STL containers started to provide clear benefits over Qt stuff.

I feel like you are trying to judge Qt's design decisions with today's optics. C++ devs have it embarrassingly easy today. There are basically three compilers, three (or maybe four) major platforms and three (maybe four) CPU architectures to support. Our tools are also much more advanced and polished then ever. The reality of the 90s was akin to a digital wild west. Do you think that your statement

std::wstring (on non-microsoft platforms) did handle that correctly since the dawn of time

would hold true if you had to use Watcom on WIn32, aCC on HP-UX and Metrowerks for Mac OS because that's what your customers wanted? (I myself had the distinct "pleasure" to use a compiler where the default enum size was configurable)

As for the neverending QString debate, let me make just a few last remarks:
- QString documentation is very clear about the fact that methods that take an index operate on code units and not codepoints nor graphemes.
- Qt has means to deal with "human" text units that take QString as the input. Again, since QString has a more strict definition than any STL string type, it is easier to write such functionality.

[ssokolow]

lowflyerwould hold true if you had to use Watcom on WIn32, aCC on HP-UX and Metrowerks for Mac OS because that's what your customers wanted? (I myself had the distinct "pleasure" to use a compiler where the default enum size was configurable)

Would that be Watcom or something else?

I noticed that Open Watcom retained that particular feature the last time I had time to work on my "InnoSetup/NSIS for DOS"-esque retro-computing hobby project where I'm trying to balance hackability (write it in C) and not crowding the actual content off a floppy disk.

(Fine-tuning the compiler flags for output size and replacing parts of the standard library with inline assembly to do BIOS FFI. just to position some text, graph.h added something like 35KiB to the base binary size (no thanks to Open Watcom not having true dead code elimination) when my goal is to fit a BASIC runtime, unzipper, installer-oriented standard library, and the user's install script and chosen theme into 15KiB... ideally 10KiB so I can beat the smallest non-.BAT commercial installer I found in my collection of floppies and DOS CDs.)

[ssokolow]

ssokolow
Qt has QTextBoundaryFinder to iterate over grapheme clusters: https://doc.qt.io/qt-5/qtextboundaryfinder.html

Thanks. I suspected it had something like that yet but, so far, I've only ever needed to do it on the Rust side of a PyQt+PyO3 stack. (My way of binding QWidget APIs to Rust in a QML/C++-esque compromise. Qt frontend, reusable Rust backend.)

[MadCatX]

Would that be Watcom or something else?

Borland, actually. It's not really a problem until somebody gets the idea to use `sizeof(TheEnum)` for serialization. The truly sad part is that it wasn't that long ago

[lowflyer]

lowflyer
I'm only stressing multiplatformity because that is Qt's biggest selling point.

The only place where multiplatfom really matters is desktop and mobile. This is the place where Qt really shines. All the other places are niche platforms where this advantage boils down to "tooklit knowledge".

I still don't get your argument about STL vs. Qt library.
...
and STL is a pretty huge chunk of 3rd-party code to rely on.

Personally, I find it unrewarding to pit the STL against Qt especially with arguments from the past. But the bigger issue is that you seem to misunderstand the status of the STL. It is part of the language definition - not "3rd-party" code.

I feel like you are trying to judge Qt's design decisions with today's optics.

Well yes. To some degree I do. It's because I actually like Qt. As the whole industry progresses, I see Qt remaining in its errors - and I don't like that.

- QString documentation is very clear about the fact that methods that take an index operate on code units and not codepoints nor graphemes.
- Qt has means to deal with "human" text units that take QString as the input. Again, since QString has a more strict definition than any STL string type, it is easier to write such functionality.

It's not in the QString documentation and they mislead people by using "UTF-16" where they should better say "UCS-2". And the link to QTextBoundaryFinder that JackLilhammers pointed out is missing.

The STL has an equally strict defined string type, so there's no distinct advantage of QString in this respect (not addressing implicit sharing here).

[JackLilhammers]

And the link to QTextBoundaryFinder that JackLilhammers pointed out is missing.

That's clearly a gap in their documentation, which is very well done imho, but could be better.
OTOH the docs for PySide are very much a work in progress