C++11/14 compiler and library shootout | Hacker News Reader

C++11/14 compiler and library shootout

cpprocks.com

40 pointswslh15 comments

It's very heartening to see Microsoft and Intel actually adopting the new C++ standards given the fiasco that compiler support for C and C++ standards has been in the past.

That said, I sort of worry about the new approach to C++ standards. It was nearly a decade between C++03 and C++11 (duh) and C++03 was a very minor set of changes compared to C++98. Now we are planning to have major changes every six years, with a minor release in between? That's a new standard every three years. It seems hard to imagine how the compiler developers are going to keep up with that, much less our libraries.

Considering the C++ world is already very fragmented in terms of style and features used (C with Classes, Modern C++, horrible in-between?), I don't know if C++17 is going to be good for the ecosystem. I mean, people are talking about adding everything from monads[0] to compile-time reflection[1].

If the designers were willing or able to remove features (do we really need two different initialization syntaxes?) then I would be less concerned, but intentionally breaking every existing C++ library would probably do more harm than good.

Overall, I'm just not sure that this aggressive schedule of adding new features to a large language is a great idea.

[0] http://bartoszmilewski.com/2014/02/26/c17-i-see-a-monad-in-y... [1] http://cpptruths.blogspot.com/2014/03/why-we-need-compile-ti...

I think that with the competition of other languages, adding modern feature support became a necessity

C++11 is much better and much more intuitive than older versions. Still it feels like tearing down a tree with a kitchen knife sometimes.

I am getting tired of this "modern" attribute (nothing against the parent comment) attached to everything in the new standard. There is nothing modern about the new features of C++11/14, yet the proponents of the "modern style" behave as if they just discovered sliced bread. I was hoping that the C++ community was above this.

> There is nothing modern about the new features of C++11/14

There's nothing modern about any feature that's been introduced into a popular programming language in years. They're all rediscoveries or minor iterations on things invented decades ago.

It's usually not the features that are described as being "modern," though. It's the style that's described that way, and there is a marked difference between the style of, well, modern C++ code and the style of C++ code written in the '90s.

Borrow-checking in Rust seemed pretty modern to me.

Regions were in Cyclone in 2010, so it's still a fairly old idea.

I feel like C++11 was a sea change, but '14 is mostly cleanup and adding things they couldn't quite get into '11, and suspect this to be similar with '17 when it actually gets down to standardization work, not proposals. It would be nice if they start deprecating some of the older syntax.

It remains to be seen how well vendors keep up, but I think that's more a measure of interest than technical limitations. If the modernization of the language reinvigorates its use, they'll resource the compiler teams for it.

I have conflicting feelings on what I want from C++ in the future. I think the language needs meat-and-potatoes standard libraries like std::socket, std::filesystem, std::json, std::xml, and so on, to make it more attractive compared to Batteries Included languages like Java, Python, Go. But realistically, very few existing large C++ projects would ever switch to these libraries, so they are only useful for new projects. New language features like auto and lambdas in C++11 are more likely to make their way into existing large code bases and make life easier for their maintainers.

Note that this was published in March 2014

One really nice thing about the level of C++11 and C++14 (and even C++1z) support in clang and libc++ is that it has let emscripten remain at the forefront of support as well. While emscripten's compiler is a bit older (clang 3.3-based), I just updated the libc++ that emscripten uses to a current version (as of 3 days ago).

Could someone comment on the following C++14 feature on the list here:

"Avoiding/fusing memory allocations"

It lists Clang but nothing else as supporting it.

This sounds like a compiler optimization and not a language feature, and since it's talking about C++14 (not C++11) I know this isn't referring to move semantics/rvalue references.

What exactly is this?

That is a clarification [1] to the standard, to make it legal to avoid or fuse memory allocations if the compiler can prove it's OK. For example,

   int f() {
     int * x = new int(0);
     return *x;
   }

does not really need to allocate memory, and so that `new` is now explicitly allowed not to. Similarly,

   int f() {
     int * x = new int(0);
     int * y = new int(1);
     return *x + *y;
   }

Here the standard allows not only to elide both allocations, but also to fuse them into a single (faster) allocation.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n366...

I wish we could move to C++11 but it's still not safe to do so. One day, though.

"Safe" ? What do you mean?

The systems I deal with are administered by people that maintain a GCC compiler version of < 4.7.

Reply on news.ycombinator.com