[Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries)
Konstantin Tokarev
annulen at yandex.ru
Thu Jun 8 18:09:39 CEST 2017
08.06.2017, 01:11, "Thiago Macieira" <thiago.macieira at intel.com>:
> 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.
I'd like to insist that GCC 4.8 does not provide full C++11 support (see my previous mail),
i.e. targeting GCC 4.8 implementation of C++11 is still substantially different than targeting
C++11 standard.
> 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
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
--
Regards,
Konstantin
More information about the Development
mailing list