Hacker News Reader

Comment by userbinator | Hacker News Reader

Basically compiler fuzzing. I'm not surprised that bugs were found.

Recently, I have run into quite a few issues with different C++17 compilers (actually, I found that none of the compilers-I-tried is really C++17 compliant yet);

IMHO the fact that the spec is so complex that it is near impossible to implement it correctly should be a big hint, yet people seem very eager to continually stuff more features into the language, which can interact with all the other features in complex ways.

View on HN

I think you fundamentally mischaracterize the intent of the standards committee's additions to C++: a large part of the changes introduced from C++11 on are intended to simplify use of the language. Yes, it does take the form of additions, because legacy codebase support makes it hard to remove old features. But the intent is to take user code patterns which accomplished something either indirectly or via hacks and make the code declarative. Yes this does put more responsibility on the compiler, but will bring long-term benefits. "Must implement this intentionally designed feature correctly" versus "must replicate this historical accident of behavior exactly".

I think that's what bothers me about your comment; your phrasing "continually stuff more features into the language" implies a short-sightedness, but if you actually follow the work of the committee you can see that the thinking all the way from when it was C++0x to now maintains a long-term view.

You're post nicely summarizes the dual nature of the evolution fo the C++ standard: it gets more complex in certain ways, so the language hopefully gets simpler in other ways.

In think the GP was correct in pointing out that the ways in which the language is getting more complex is a problem for implementations of the compiler and/or the standard C++ library.

You may be correct that the GP was unfairly calling the committee "eager" to make the language more complex. But perhaps we can agree that the language is becoming more complex, and that the complexity comes at a cost.

In a recent project the juniors pushed for C++17 use; I've never seen so many code comments about compiler bugs in a single project that size. It targets only two platforms using GCC and clang.

This is not to say that compiler developers do a bad job; however, don't expect complex language revisions to be production grade from the get-go.

Generally I'd stick to C++14 features but test and consider C++17 library features as those are usually much more stable. Around the C++20 timeframe C++17 should be fully stable.

Don't go too far, or you'll get...

auto i = { 1 };

Wait, is that an integer, or an array? Serious question, with initialiser lists I'm not sure any more.

Don't sweat it, it's `auto.` Whatever you meant it to be will be deduced by the compiler. ;)

    auto i = {5};

is a std::initializer_list<int>, whereas

    auto i{5};

is an int (as of C++17): https://godbolt.org/g/eXXN3o

If you change the compiler version (to e.g. gcc7) your blurb compiles in C++14.

We’ve had good success with c++17 starting with an “blank buffer” application about a year ago. The code is clearer and so has fewer bugs. It helped that starting from zero allowed us to enable almost every compiler warning in g++ and clang++.

The bigger problem is interfacing with third party code that has to work with everything back to c+03. I don’t envy those folks in their task!

> IMHO the fact that the spec is so complex that it is near impossible to implement it correctly should be a big hint, yet people seem very eager to continually stuff more features into the language, which can interact with all the other features in complex ways.

A "big hint" for what? There's not many viable alternatives to C++, and the major contestant at the moment is Rust which has an even more complex compiler. Otherwise all the simpler languages make major compromises to achieve that simplicity, compromises that are unacceptable in more than a few circumstances.

> Rust which has an even more complex compiler.

What metric are you using for this? I would expect it to be simpler, mostly due to a lack of needing to support so many things. Totally willing to be wrong though.

Speculation, granted, but the borrow checker is non-trivial compiler complexity, along with more smarts generally shoved into the compiler like type inferencing and the macro system.

Ah, cool, that's understandable. It goes both ways; C++ has a lot of complexity that Rust doesn't have too.

I wonder if there'd be a way to actually do a real comparison.

Reply on news.ycombinator.com