On Thursday, 19 September 2019 01:41:49 PDT Mutz, Marc via Development wrote: > > Seems like it. Like I said, we've never required the C++11 standard > > library > > and we need to be sure the feature we need is supported before we > > commit to > > it. > > https://www.qt.io/blog/2016/06/16/qt-5-7-released > > > "we require a C++11[-]compliant compiler to build [...] Qt" > > The std library is not optional, unless you mean that Qt explicitly > targets free-standing implementations. That, however, is not mentioned. > When we dropped support for pre-C++98-compilers in 5.0, we also removed > -no-stl, because that's natural. There's a technical distinction between > the compiler and the std library, but from the POV of the standard, in > hosted environments, there isn't.
You're mis-remembering or mis-interpreting the Qt 5.0 decision. The -no-stl option was removed because we decided in 2012 that a C++98-compliant Standard Library is required. The wording in the Qt 5.7 changelog was: - Starting with Qt 5.7, Qt requires a C++11 compiler with support for C++11 atomics. This affects user code too: Qt headers no longer compile with a C++98 compiler. The Qt 5.6 and 5.7 wording was even more restrictive: - Qt 5.7 will begin requiring certain C++11 features in order to compile. We've NEVER meant we required the entire C++11 core language and much less the entire Standard Library. Up until Qt 5.12, we didn't require constexpr in at least one compiler. We STILL don't require C++11's ref-qualified member functions! We also know that the Standard Library lags behind the Core Language in the implementations. We have to be realist and know what we can and cannot depend on. And I've said in multiple reviews that the use of C++11 standard library features needed to be tested. I've asked multiple times that we confirm which features are safe to use in all our minimum implementations. Just search Gerrit and this mailing list. > QNX was a case where an older library (by a different vendor) shipped > with a newer GCC, and that limited the use of library features in Qt, > but that particular platform is now gone, and if Integrity has the same > problem as that QNX toolchain had, it should have been removed along > with it. Otherwise, we could've kept QNX along for the ride with no > extra cost to the Qt project. I agree with the "extra cost" argument. Platforms that don't move fast enough impose a burden on us. I do like your cleanups in QtTest, for example -- we've always had the rule that QtTest should use the least amount of Qt, so that we can test buggy Qt in the first place. > I think we should be way past caring for non-conforming platforms. We > decided to use SD-6 macros for post-C++14 feature detection, even > thought that meant that none of the features were detected for MSVC, a > much more important platform that Integrity. Correct, but we can't depend on C++14 anyway, so that meant little to our functionality. Everything in Qt continued to compile and work even without those macros. That's a whole level of difference from dropping features or an entire platform. Still, it's a decision we can make. I'm not opposed to it, as I have been bitten by Integrity's compiler shortcomings before (see QRandomGenerator's integration log). But it's a *decision* to *change* our policy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
