c++ ISO release compatibility
-
I'm sure its in a doc somewhere but what is the latest release standard that Qt 6 is supporting?
Another more philosophical question deals with c++ language evolution. the language has changed a lot from when Qt was conceived, and at least to me, Qt has a smell or feel of being legacy c++ oriented. By that I mean there are many updates to the language where Qt went down a parallel path because they weren't in the spec at the time. ie smart pointers and garbage collection functions. When, if ever, will it be time for the framework to come back into the fold by supporting the modern "C++ way" of doing things? or shoudl we expect continued and even greater divergence into the future? Will qml replace c++ support?
Thoughts?
The dystopian literature that served as a warning in my youth has become an instruction manual in my elder years.
-
I'm sure its in a doc somewhere but what is the latest release standard that Qt 6 is supporting?
Another more philosophical question deals with c++ language evolution. the language has changed a lot from when Qt was conceived, and at least to me, Qt has a smell or feel of being legacy c++ oriented. By that I mean there are many updates to the language where Qt went down a parallel path because they weren't in the spec at the time. ie smart pointers and garbage collection functions. When, if ever, will it be time for the framework to come back into the fold by supporting the modern "C++ way" of doing things? or shoudl we expect continued and even greater divergence into the future? Will qml replace c++ support?
Thoughts?
@Kent-Dorfman
IIRC, Qt 6 needs C++17 (whilst it seems to me Qt 5 needs C++11).What I guess it Qt maintainers don't want to push for latest C++ release, as it would force users to use latest compilers, this would almost rule out some distros (CentOS, Debian) which are know to be quite conservative from using Qt 6 for instance.
`They did not know it was impossible, so they did it.'
-- Mark Twain -
@Kent-Dorfman
IIRC, Qt 6 needs C++17 (whilst it seems to me Qt 5 needs C++11).What I guess it Qt maintainers don't want to push for latest C++ release, as it would force users to use latest compilers, this would almost rule out some distros (CentOS, Debian) which are know to be quite conservative from using Qt 6 for instance.
It's implicitly defined by the supported compilers listed here.
-
When Qt6 released C++20 was still kinda fresh. Compilers still ironed out bugs, many platforms didn't have support yet etc. so C++17 was a good balance between upgrading from rusty C++98 to a more modern but not quite edge of the razor version of the language. The next jump will happen with Qt7 I guess.
As adopting new features goes - a lot of it happens. We got lambdas, string suffixes, chrono, constexpr and a lot more, but these are "easy" i.e. they are additive. It's a lot harder to change fundamental rules of the library like passing non-copyable QObjects with pointers to something like move semantic approach. It's a massive rewrite and compatibility break.
Porting Qt 3 to 4 was a huge pain. 4 to 5 was a bit better, but still took a lot of work. 5 to 6 was intentionally made as easy as possible by minimizing breaking changes. I don't think 6 to 7 will be much different. I think Qt is under a lot of pressure right now from alternative technologies and massive break in compatibility wouldn't do it any good.
I guess it's a bit of a situation like with the C++ itself, but Qt has it double worse, because not only is it getting old and amasses a lot of legacy, but it also diverged from the language and the standard library.
A big question are also the widgets and the whole styling support libraries. Although they are holding up pretty well they are definitely in the category of legacy technologies and adding support for modern stuff, like for example Fluent Design on Windows, are pretty much out of the question with them. I wonder if a modernization decision would also mean cutting widgets support. That would certainly be a big blow.
It's a tough situation to be honest. A technology stack refresh would in simple technical terms be beneficial, but also very costly in a broader sense. It's a bit of a gamble. I don't envy the decision makers when it comes to Qt7.
-
When Qt6 released C++20 was still kinda fresh. Compilers still ironed out bugs, many platforms didn't have support yet etc. so C++17 was a good balance between upgrading from rusty C++98 to a more modern but not quite edge of the razor version of the language. The next jump will happen with Qt7 I guess.
As adopting new features goes - a lot of it happens. We got lambdas, string suffixes, chrono, constexpr and a lot more, but these are "easy" i.e. they are additive. It's a lot harder to change fundamental rules of the library like passing non-copyable QObjects with pointers to something like move semantic approach. It's a massive rewrite and compatibility break.
Porting Qt 3 to 4 was a huge pain. 4 to 5 was a bit better, but still took a lot of work. 5 to 6 was intentionally made as easy as possible by minimizing breaking changes. I don't think 6 to 7 will be much different. I think Qt is under a lot of pressure right now from alternative technologies and massive break in compatibility wouldn't do it any good.
I guess it's a bit of a situation like with the C++ itself, but Qt has it double worse, because not only is it getting old and amasses a lot of legacy, but it also diverged from the language and the standard library.
A big question are also the widgets and the whole styling support libraries. Although they are holding up pretty well they are definitely in the category of legacy technologies and adding support for modern stuff, like for example Fluent Design on Windows, are pretty much out of the question with them. I wonder if a modernization decision would also mean cutting widgets support. That would certainly be a big blow.
It's a tough situation to be honest. A technology stack refresh would in simple technical terms be beneficial, but also very costly in a broader sense. It's a bit of a gamble. I don't envy the decision makers when it comes to Qt7.
Well put. I spend what I consider to be a lot of thought/effort into how I want to answer vs the Qt answer when someone asks a Qt related question dealing more with C++ STL or language features. I strive to avoid the Qt containers because my world is bigger than Qt and the STL equivalents are more generic. I understand that "at the time" certain Qt containers were more prudent to use than their C++ counterparts, but as alluded to, I wonder if it's time to put all that aside...which is purely hypthetical becuase I think both of use know it will never happen.
