thiago.macieira at intel.com
Thu Sep 19 23:47:00 CEST 2019
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.
> > "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
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
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
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
That's a whole level of difference from dropping features or an entire
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
More information about the Development