On Monday 14 October 2024 06:13:49 GMT-7 Giuseppe D'Angelo via Development wrote: > Do you foresee any problems at actually guaranteeing that we still work > with C++17, should one force the C++ version (via whatever means)? > I mean, we have to keep work in C++17 anyhow (for some toolchains), > what's the harm at saying that Qt actually works everywhere that way?
I don't think we need to guarantee that it works for anybody but us, for the platforms where C++20 is available. So "if it passes the CI, it's good enough". > Is it an implementation concern, or e.g. because by default the CI won't > test it anymore (will test in C++20), or...? My proposal is that we do build all tests in C++17 mode on Linux. We don't necessarily have to run them, though. That will exercise the Unix code paths in C++17 mode and all headers.will be tested in all platforms too. > (Indeed testing is especially tricky. Do we run the full autotest suite > on those platforms that won't get C++20 by default? Should we still keep > C++17 coverage around on at least one platform, say, Linux?) Yes if they run tests now. I know QNX and INTEGRITY do, but I am unsure whether VxWorks testing is enabled yet. > Right now that includes, for instance, libstdc++, which still marks > C++20 and later as experimental, and can break API/ABI at will. Indeed, which means we need to know what of it, if anything, we can use in our ABI. I have one item I want and I've emailed Ville asking if that one is ABI- stone already. > So, what happens to us if libstdc++ breaks (for instance) ABI in some > std::format utility? Bad things. But that's no different from std::filesystem breakage if we hadn't been careful. > What about the qt-configure-module script? Is it going to inherit > qtbase's settings? I'd prefer not to, but Alexandru convinced me it's a useful thing to have in the change review above. It'll be an overridable CMake setting, so all modules inherit qtbase's setting as their default. > Same question as above: given the C++20 code would still need some sort > of protection (feature macros, QT_CONFIG, whatever) because it needs to > build on the C++17 platforms, what's the harm at keeping C++17 "working" > everywhere? Extra effort and CI time. If we're not going to allow users to use that, why should we spend valuable CI cycles in it? Especially for platforms we don't have enough of, like Apple ones. > Effectively, I don't see much difference from the current situation, > where we "pretend" that we require C++17 but in reality we just check > that we can pass `-std=c++17` to the compiler. Any usage in Qt code of > individual language/library features still requires protection, because > they're not universally implemented. Indeed, except that it will be -std=c++20. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
