[Development] INTEGRITY

[Thiago Macieira]

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