[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