[Development] Raising the minimum to C++20

[Tuukka Turunen]

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-bounces at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Date: Friday, 5. May 2023 at 19.17
To: development at qt-project.org <development at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230505/eb22e245/attachment-0001.htm>