[Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries)

Thiago Macieira thiago.macieira at intel.com
Thu Jun 8 00:10:57 CEST 2017


On quarta-feira, 7 de junho de 2017 13:30:30 PDT Konstantin Tokarev wrote:
> FWIW, the first really C++11 complete version of GCC is 4.9, 4.8 still has a
> number of bugs that result in internal compiler errors, compilation errors,
> or runtime errors in some non-trivial but valid C++11 code. See for example
> patches in [1, 2]

4.9 is a 4-year-old compiler today. I'd love to get rid of the buggy 5.3.x, 
but that's too recent. Quick survey shows:
* GCC 4.9 in Ubuntu 14.04 LTS, Debian Jessie, Fedora 21 [*]
* GCC 4.8.5 in the latest OpenSUSE Leap, SUSE Linux Enterprise. and CentOS / 
   RHEL.
[*] F21 is not supported by Fedora; minimum support at the time of Qt 5.10's 
  release will be F24

So I'm guessing we should require GCC 4.8.5 (all the latest fixes). This will 
give us full C++11 support in GCC. Clang claims to be fully C++14 compliant in 
3.4, which we already require.

Then there's MSVC. So... should we begin thinking of dropping MMSVC 2013? 
We'll gain by doing that:
 * default and delete members
 * alignas & alignof
 * inheriting constructors
 * noexcept
 * range for (without having to check if it really works)
 * ref qualifiers (no more need for #ifdef)
 * thread_local (QRandomGenerator benefits from this, also obviates the need to 
    introduce Q_THREAD_LOCAL)
 * user defined literals
 * Unicode strings
 * unrestricted unions

Another benefit is that MSVC 2017 and 2015 are supposedly binary compatible 
with each other. With care, we can even use this feature in Qt.

If we require MSVC 2015 with the most recent update (which is over a year old 
now), in addition we get:
 * attributes
 * thread-safe statics (finally! could drop the fallback from Q_GLOBAL_STATIC! 
    oh, wait, Apple...)
 * uniform initialisation (without having to check if it really works)

In other words, there'll be exactly one C++11 feature we won't be able to 
indiscriminately use:
 * constexpr

(plus whatever fails due to issues in the the Standard Libraries)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list