[Development] Are we already allowed to use C++17 in dev?

Olivier Goffart olivier at woboq.com
Tue Jan 14 10:15:35 CET 2020

On 2020-01-13 19:38, Thiago Macieira wrote:
> On Sunday, 12 January 2020 23:18:40 PST Olivier Goffart wrote:
>> Well it might, since this patch forces the use of C++17 everywhere,
>> regardless of the configure test. which i believe is the problem.
> There's a reason we wrote the test like that. It was specific to make iOS
> detect C++17 as absent, so we wouldn't try to use the aligning operator new.
> The reason for my failure is that the Standard Library is not as new as the
> compiler itself. We do not have C++17 standard library.

I know that.
But since we are supposed to mandate C++17 in dev, what the other path[0] does 
is simply to discard this test altogether and add the -std=c++17 anyway.
That patch had a CI test run without macOs, and every platform passed. 
(although no C++17 is already in use, so maybe there are further issues)

[0] https://codereview.qt-project.org/c/qt/qtbase/+/283832

As mentioned in the commit message, this is just a quick and dirty way to get 
things running with C++17 as soon as possible with qmake. Of course, with 
cmake, we will have the proper error detection in place and such.

Now if we force the -std=c++17 flag, we hit this other problem you mention 
because we get compilation error while including <variant> because we still 
target macOS 10.13 and the code in qvariant.h does

  #if __has_include(<variant>) && __cplusplus >= 201703L
  #include <variant>

but the problem is that on the Apple platform, the <variant> header is present, 
but will cause an error because it detects that it is not available on the 
target platform. (I know you are aware of this, just clarifying for the list)
Now we are trying to remove macOS 10.13 from the CI to "solve that problem".
The thing is that it takes some time since we want the tests running on 10.14 
first. (Thanks Tor Arne for the patches). I'm afraid it will still take quite 
some time before this happen because, if i understand correctly, the patches 
have to reach each branches before going to the dev branches, then qt5.git has 
to integrate, which may happen to be quite difficult given the problem we have 
to synchronize all modules). Then hopefully there is no further problem.


More information about the Development mailing list