08.06.2017, 01:11, "Thiago Macieira" <[email protected]>: > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
