Hi,
I also agree that it is important to keep moving along and harness what new C++
versions offer in the best way we can. Potential time to do this would indeed
be in the near future – one good point in time to drop support for older
compilers could be with Qt 6.9 around March 2025 as mentioned. Like Volker said
we should assess both C++20 and C++23 at that point.
The topic raised by at least Maurice about the embedded and especially RTOS
platforms moving slower is very valid. But these are also ones where customers
typically stay with one Qt version for a bit longer. Thus, I believe it could
work to have Qt 6.8 (LTS) as the last one that compiles with C++17. As long as
there is some new compiler and RTOS combination that we can keep running on dev
with the new C++ version (20 or 23) we can pick/backport the relevant fixes to
Qt 6.8 for a while until it is again a good time to support the RTOS platforms
for deployment (optimally by the next LTS is due around September 2026).
Let’s continue assessing the benefits from using capabilities of later C++
versions and meanwhile check with the RTOS vendors on how they have been
planning to enable using C++20 and C++23.
Yours,
Tuukka
From: Development <development-boun...@qt-project.org> on behalf of Thiago
Macieira <thiago.macie...@intel.com>
Date: Friday, 5. May 2023 at 19.17
To: development@qt-project.org <development@qt-project.org>
Subject: Re: [Development] Raising the minimum to C++20
On Friday, 5 May 2023 03:18:46 PDT Ville Voutilainen wrote:
> > Of the C++20 features I currently see a good reason to make mandatory:
> > * feature-test macros (no change: we're already using them)
> > * spaceship operator and <compare> header
> > * char8_t
> > * std::is_constant_evaluated()
> > * constinit
> > * <bit> header
> > * (maybe) designated initialisers
> > * (maybe) constexpr from <algorithm> and <utility>
>
> I don't see any of these as worth breaking embedded users who want new
> Qt versions but don't yet
> have the compilers that can give them these facilities.
When you put it this way, no, they're not worth *breaking* the experience for
those users. We're already using the feature-test macros and constinit even in
C++17 mode, we have our own implementation for what <bit> does (but see
below). We also have conditional code for std::is_constant_evaluated() and a
fallback to a GCC extension, and Ivan was beginning to add a fallback/
workaround for the spaceship operator with macros[1]. The latter is why I
began this thread: I'd like to know if we should "dirty" our code with more
macros or if we can go clean for the spaceship.
The only odd result is that one compiler (MSVC) is generating worse code
because we don't have access to the builtins that <bit> and
std::is_constant_evaluated() would have used. That's fixable.
One, __builtin_is_constant_evaluated() works with GCC 9, Clang 10, MSVC 2019
and even the old EDG-based Intel compiler in C++17 mode, see
https://gcc.godbolt.org/z/4boM5Esfx
So we *could* just use it and damn the torpedoes. That leaves out users of GCC
8 (a.k.a. QNX) and the GHS compiler, who would get non-constexpr code
generation.
Two, we could simply raise MSVC or just all Windows builds to C++20 regardless
of what we do elsewhere. During Qt 4 days, after we switched to C++11, we did
begin using some core language and standard library features without compiler
check in macOS-specific code because we knew the state of that compiler.
I think is a fair deal: we get to move forward and improve the platforms that
can upgrade, without affecting the ones that can't.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/475447
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
