[Development] What kind of airplane we want to build?

[Ziller Eike]

> 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
>> 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
> Development at qt-project.org
> 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