Daydreaming About Qt6 & Qt7

[phoronix]

Phoronix: Daydreaming About Qt6 & Qt7

A Qt fan asked developers this weekend about what features might be candidates for a release that breaks from Qt5 and goes to Qt6 or even then to Qt7...

http://www.phoronix.com/vr.php?view=MTc1OTE

[vinipsmaker]

I think we'll never see QString removal, mainly because upstream C++'s std::string will never follow QString design and Qt devs wouldn't dare to make such colossal breaking change.

I also don't think we'll one day see the Qt's "STL" being replaced by the real STL. C++ STL still has a lot of evolution interest (polymorphic allocators, allocators with realloc, ranges, concepts...) and even if we agree the real STL is better (now or in the future, doesn't matter), Qt devs will never give up on their programming style (QList::mid) where usability is favored over performance.

I don't know, maybe if they manage to throw more usability and code to the JavaScript/QML side, then it wouldn't hurt productivity-over-performance programmers. The only thing I value here is interoperability and I don't anybody would enjoy every lib developer providing their own STL.

[Ancurio]

I think we'll never see QString removal, mainly because upstream C++'s std::string will never follow QString design and Qt devs wouldn't dare to make such colossal breaking change.

I also don't think we'll one day see the Qt's "STL" being replaced by the real STL. C++ STL still has a lot of evolution interest (polymorphic allocators, allocators with realloc, ranges, concepts...) and even if we agree the real STL is better (now or in the future, doesn't matter), Qt devs will never give up on their programming style (QList::mid) where usability is favored over performance.

I don't know, maybe if they manage to throw more usability and code to the JavaScript/QML side, then it wouldn't hurt productivity-over-performance programmers. The only thing I value here is interoperability and I don't anybody would enjoy every lib developer providing their own STL.

All Qt containers + QString have COW, when will the STL have it?

[vinipsmaker]

All Qt containers + QString have COW, when will the STL have it?

STL string implementations used to have COW, but it proved bad for multi-threading and it was banned in C++11.

Small String Optimization, move semantics and design ideas (like shared_ptr) collectively are the "new COW".

One thing way more important present in QString is Unicode support, which has been available for ages within Qt.

But the QString/QByteArray/QVector<char> differences are annoying. Maybe QByteArray shouldn't exist and something like string_view/string_ref worths more.

[Alliancemd]

Re

"Cross-Process Signals/Slots" - That I want!

vinipsmaker - Qt 5 also uses move semantics and all the appropriate optimizations where appropriate. And I don't understand your problems with QString.
Qt's QString is actually faster than all the string implementations out there, you should read Thiago Macieira's blog post on QString optimizations...

[doom_Oo7]

Consistent memory management please...

It's a pain to use shared pointers with the items of graphics scene for instance...

[vinipsmaker]

Qt 5 also uses move semantics and all the appropriate optimizations where appropriate.

The point is not that Qt should make use of these other optimizations. The point was that these other optimizations makes COW less important.

And I don't understand your problems with QString.

I don't have a problem with QString. I have a problem with the lack of interaoperability. Of course you can convert between QString and std::string, but this is less than ideal. My concern is "what changes does upstream C++ standard libraries have to adopt for Qt drop the QString, QList and so on?".

Would Qt devs drop QString if std::string improved enough (after a time where the changes were well spread across the industry to be a good baseline)? And std abstractions will never incorporate usability over performance (only pay for what you use), then Qt devs would need to give upon a few designs too, because they would never make into std namespace.

TL;DR: I think it's quite unlikely that we'll Qt dropping QList, QString... and I think there is hope only if most of development over Qt use mover from C++ to non-C++ (JavaScript within QML).

Qt's QString is actually faster than all the string implementations out there, you should read Thiago Macieira's blog post on QString optimizations...

<http://www.macieira.org/blog/2011/07/qstring-improved/>? It talks mainly about compile-time improvements (consexpr anyone?).

[anda_skoa]

But the QString/QByteArray/QVector<char> differences are annoying. Maybe QByteArray shouldn't exist and something like string_view/string_ref worths more.

String and bytearray are two dfferent concepts but QByteArray could probably be a subclass of QVector<uint8_t> with convenience methods added on top of it.

Cheers,
_

[alelinuxbsd]

I think could be really nice if some big project as Qt (or other) was able to use an alternative language to c/c ++ without compromising functionality and performance.

[dilepoutee]

So much delicacy in those comments...