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

[Thiago Macieira]

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?

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