> On Jan 23, 2016, at 1:47 AM, Thiago Macieira <[email protected]> > wrote: > > On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote: >> I feel it's actually TOO rapidly changing. C++11 even threw out C >> compatibility, not only by not adopting all C99 improvements (e.g. VLAs), >> but also by subtly interpreting even as simple valid C90 code as "auto x = >> 1.5;" in an incompatible way. (OK, that code is not valid C++98, but at >> least a C++98 compiler would tell you what is wrong with it, C++11 just >> silently gives it a different meaning.) > > I disagree with you on all points here. C++ is *not* moving too fast. In some > areas, it's not moving even fast enough: where's the reflection support? > Meanwhile, discussions linger in the standards proposal mailing list about > how > many templates we need for parsing a string to integer. > > Specifically on VLAs, the proposal was added to C++14, but dropped due to > disagreement. C++ would have implemented a subset of C99's requirement, but > not the controversial parts like taking a sizeof and getting the runtime size > and passing them as parameters. The less we talk about > void f(int n, char array[static n]); > the better. > > On auto, it's not a big loss. So what if it's incompatible between C and C++? > NO ONE writes "auto" anymore in C, since the only place where you can use it > are places where it's redundant. As for the case you showed, even C99 > deprecated it. > > I miss designated initialisers and that is a shame. When that comes around, > the discussion always goes on to talk about named parameters, which meets > stiff resistance in the committee. > >> I consider the fix of the "have to write '> >' to close double templates" >> issue as the most useful improvement in the entire C++11 standard. > > Not variadic templates? Not constexpr? Not decltype? Not rvalue references?
Variadic templates + decltype + SFINAE/type_traits + universal references are able to reduce several thousand lines of very limited functionality, repetitive, unreadable QtConcurrent code, to probably something like a few hundred lines with more features and better behavior (e.g. unlimited arguments and argument types, movable types). I'd see most of http://code.qt.io/cgit/qt/qtbase.git/tree/src/concurrent/qtconcurrentstoredfunctioncall.h and http://code.qt.io/cgit/qt/qtbase.git/tree/src/concurrent/qtconcurrentrun.h would just be gone. > By the way, if you Google for "C++ most vexing", you'll see a problem that is > still not solved and probably won't be. > >> Please do not make major changes to Qt that break all existing code, or even >> replace it with something entirely different. It causes major pain. There >> is useful software out there still stuck on Qt 3 years after Qt 4.0.0, and >> the changes you suggest would be even much worse than the Qt 3 to 4 >> transition. > > We will have to eventually break some things. Compatibility with old code has > kept QIODevice stuck in time, unable to move forward and implement important > things like zero-copy buffering. > -- > 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 -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
