On 31/01/2022 17:36, Thiago Macieira wrote:
On Monday, 31 January 2022 05:23:45 PST Giuseppe D'Angelo via Development wrote:1) Does a build of Qt default to C++17 or C++-latest? Qt 5 did the latter, Qt 6 does the former. I would be fine at restoring C++-latest, with command line switches available to picking a specific C++ version if so desired.It defaults to C++17. We actually know of a few issues with C++20 with some compilers and those need to be fixed, regardless of what we do about this thread. And we should at a minimum test our headers with multiple versions of the C++ standard, because that's an acceptable choice our users can make.However, this smells of maintenance burden; what "latest" means depends on the specific compiler version, that is, we need to start building compiler+CMake version lists (older CMakes does not recognize the latest C++ versions).I don't see why that would be a problem for us. So an older CMake doesn't know that GCC 10 has C++2b mode? Then we just test the C++2b mode in an OS that comes with a suitably recent CMake.
I was referring to the "defaulting to C++-latest". In order to know what *is* the "latest" you can target, you need to detect the CMake and the compiler versions. That means start building tables of supported combinations. Probably nothing too complicated, still, work to do.
On top of that, C++17 is still the official minimum (= need CI coverage for C++17 builds on all platforms).Not if we decide that we must use C++20.
That's an orthogonal decision. Bumping the minimum requirement of Qt to C++20 will simply reopen the same questions for C++23, won't it?
3) Should a C++-latest build of Qt work for a C++17-compiled project? I would say that this should work. If the post-C++17 features are guarded by the right #ifdefs, would that be a problem? The added bonus of making this work would be that we could offer C++-latest binary builds of Qt and projects could still pick their preferred C++ version to use.I think it's a must, unless we say that user code must also use C++20 to work with Qt and I don't think we're there yet.
So, concretely, this just means: use feature macros to guard the relevant APIs. The C++17 project won't see the APIs as available, so it can't use them, and won't get no compile errors.
4) Should a C++17 build of Qt work for a C++-latest project? I'd say "yes", but what happens if the project tries to use an API that uses a C++-latest datatype? At first approximation, the user might simply get a link error (the function hasn't been built into Qt). Can we offer better QoI here, and completely hide those functions from such builds of Qt? Not sure if it's easy -- it would mean baking the "has C++ feature" detection into the Qt build, maybe via CMake magic? But I would say that it's worth it; link errors are completely meaningless to an end user.I'd say no. That was my reply to Lars just now and the gist of my opposition to Marc's initial proposal: a C++17 build of Qt is an unsupported "send patches, not bug reports" build.
Is this a "no" to the better QoI, or to the overall idea of making a C++17 build of Qt work with a C++-latest project?
Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
