[Development] What kind of airplane we want to build?
thiago.macieira at intel.com
Sat Jan 23 01:47:38 CET 2016
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]);
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
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
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
More information about the Development