[Development] What kind of airplane we want to build?
Eike.Ziller at theqtcompany.com
Mon Jan 25 10:52:30 CET 2016
> On Jan 23, 2016, at 1:47 AM, Thiago Macieira <thiago.macieira at intel.com> 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
> 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
> Development at qt-project.org
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
More information about the Development