KDE Now Maintaining Their Own Set of Patches For Qt 5

[wertigon]

I'm afraid you're thinking about this all wrong. There are numerous huge software projects that use Qt - a lot of them commercial. Imagine the sheer amount of work that'd have to go into moving away from QString to std::string API. How would you explain to your customers that they have to rewrite all of their container code if they want to upgrade to Qt6? Why would anybody do that?

This is why the keyword "Deprecated" exists. It is not unreasonable to ask your customers to recode to a different container while maintaining the old API one last generation.

Qt containers are fine. They have a STL-like and Java-like convenient APIs. They do copy-on-write (STL doesn't). They use signed integers for indices (I think it was Scott Meyers who said that using unsigned ints for indexing is one of STL's biggest mistakes). They are guaranteed to work exactly the same on all platforms. They are used consistently across the entire Qt. What exactly do you gain by switching over?

Just because they work fine, does not mean they are fine. The trouble comes when you need to launch beyond Qt, at which point these containers incur technical debt. For instance, the entire programming community has settled on UTF-8 as the standard Unicode codepoint. Except Qt, Win32 and Java, whom are being stubborn about this. Meanwhile the WWW has pretty much settled the issue and most if not all documents authored nowadays are UTF-8 on the web.

What do you gain by switching over? Interoperability and less need for hacky workarounds. Not saying all of it is bad, but quite a few things are and should be switched over for the sake of making Qt more useful.

Qt does adopt things from STL. Qt5 relies on STL. QString has fromStdString() and toStdString() methods since Qt5. You can use std::thread with Qt slots for example. At one point they did consider adopting some STL containers but eventually decided against it.

Yes. Qt depends on STL; but it does not allow for this very much when interfacing the Qt libraries. This becomes apparent when you want to, say, pair a more capable network library with Qt than exist in the Qt platform.

Bottom line, there really is no reason to cling to old and outdated containers, even if replacing them is a massive undertaking. Keeping said containers will only hurt more and more for each passing year, just like jQuery did for browsers.

[oleid]

In my humble opinion, qt should strive towards the std:: libs as they improve and rely less on their own, incompatible stuff where possible.

In my humble opinion, rolling their own string type is fine for Qt. GTKmm doesn't use std::string as well. In contrast to Qt, however, their string type is utf8. And from my point of view, that is the most sane thing. Now if there only was a utf8 string type in the standard...

[JackLilhammers]

This is why the keyword "Deprecated" exists. It is not unreasonable to ask your customers to recode to a different container while maintaining the old API one last generation.

Instead, think about how reasonable it is for your customers not to have to fix things that weren't broken.
Especially considering that they can already choose the containers that suit their project best.

If you're curious about why they're still using QString instead of std::string or std::wstring, you can read this thread
https://interest.qt-project.narkive....not-std-string
It's a bit long, but I think it's interesting.
That said, I don't think it's that big of a deal to call toStdString() when you need std::string or to work with std::string and call fromStdString()

[wertigon]

Instead, think about how reasonable it is for your customers not to have to fix things that weren't broken.
Especially considering that they can already choose the containers that suit their project best.

I do not see it as unreasonable to consolidate on the same library over time. If this were to be deprecated in Qt 6 and removed in Qt 8, that would be 10-15 years for customers to change. While things are not broken as of now, using a 3D-printed plastic cog instead of a solid, molded titanium one isn't exactly a recipe for a lasting machine, either. So, the 3D printed cog has 16 teeth instead of 14; This creates some repercussions like the axis the cog is on is not turning at the correct velocity. Redesigning the machine to then use more standard parts over time is a good idea, ya?

If you're curious about why they're still using QString instead of std::string or std::wstring, you can read this thread
https://interest.qt-project.narkive....not-std-string
It's a bit long, but I think it's interesting.
That said, I don't think it's that big of a deal to call toStdString() when you need std::string or to work with std::string and call fromStdString()

Thread is from 2012; surely, by now most points made are no longer valid? I could be wrong of course.

To be clear here, I do not know enough details about any single Qt component, nor do I know if this has been discussed over at Trolltech, and this is just one of many non-standard parts. All I know is, Qt is designed by people, at this stage being very conservative, and most engineers I've talked to tend to do a thing a certain way because they've always done it that way. It is good for every new iteration of a framework, to challenge each component. This does not mean the custom component is automatically bad; but I do not see a good reason to use Qstrings for instance. I also see no good reason to stick to UTF-16, other than backwards compatibility; that alone would solve a lot of headaches.

But I'll agree to disagree, it's clearly not my product.

[JackLilhammers]

Thread is from 2012; surely, by now most points made are no longer valid? I could be wrong of course.

I know it's an old thread, but explains why Qt 5 used QString instead of standard strings.
I could be wrong too, but I don't think the standard library has changed so much as to make QString obsolete.

It is good for every new iteration of a framework, to challenge each component.

Actually, they do challenge every component.
If you look at the changelog in Qt 6 you'll see that QVector and QList implementation has been merged and QLinkedList has been deprecated and they're recommending using std::list while keeping the old class for backwards compatibility.

[lowflyer]

What I cannot understand, is why the heck Qt 6, released in 2021, must insist on spending resources and burning goodwill with their own incompatible qt::QString instead of deprecating it completely and simply do:

typedef qt::QString std::wstring;

The main difference between QString and std::wstring is that QString is implicitly shared.

[Guest]

At this point I wonder how much kde might be willing to shell out on a viable framework alternative they could actually switch to.

It's a lot less work, and cheaper for them to just fork Qt 5 and stay on that for a few years. Plus they get a stable base to build on.

[lowflyer]

What do you consider standardized and how is it relevant for the discussion?

The first public release is the only sensible baseline to compare the STL with Qt since Qt was never standardized. To argue that "Qt was first because the standard was ratified later" is hypocritical.

Neither std::string, std:wstring nor QString store code points. std::string stores an array of bytes. std::wstring stores an array of wchar_ts, wchar_t is an implementation-defined integral type that may be as small as 8 bits (yes, really). QString stores an array of UTF-16 code units. std::string and std::wstring make no assumptions about the data they store. Since QString assumes its content to be a UTF-16 code unit sequence, it can implement Unicode-aware text handling consistently across multiple platforms. You still need to exercise caution when dealing with surrogate pairs in QString. However, AFAIK there is no string manipulation library that is considerably better in this regard.

No. Don't let yourself be misled by the Qt documentation. The problem is just pushed 8 bits further down. To infer "Unicode-aware text handling consistently across multiple platforms" from this is simply wrong.
Technically you are correct that wchar_t *may* be only 8 bits. But you'd be surprised what it *actually is* on your compiler. Behold the definition of wchar_t:

wchar_t - 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)

Or, check it for yourself with

std::cout << sizeof(wchar_t) << "\n";

On Linux, std::wstring is considerably better than QString. On Windows, both are equally bad.

When people talk about a local socket, I imagine that most people think of AF_UNIX kind of socket. Most APIs and SDKs use the name local socket to describe this device.

Don't assume. At least one person didn't.

[lowflyer]

By the way MadCatX . I'm not mad at you - despite my (often too-) edgy comments. Reading up documentation while replying to your posts thought me a whole lot. I honestly like tough technical discussions.

[MadCatX]

The first public release is the only sensible baseline to compare the STL with Qt since Qt was never standardized. To argue that "Qt was first because the standard was ratified later" is hypocritical.

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?

No. Don't let yourself be misled by the Qt documentation. The problem is just pushed 8 bits further down. To infer "Unicode-aware text handling consistently across multiple platforms" from this is simply wrong.
Technically you are correct that wchar_t *may* be only 8 bits. But you'd be surprised what it *actually is* on your compiler. Behold the definition of wchar_t:

Or, check it for yourself with

std::cout << sizeof(wchar_t) << "\n";

On Linux, std::wstring is considerably better than QString. On Windows, both are equally bad.

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.