Hacker News new | comments | ask | show | jobs | submit login
C++17 Compiler Bug Hunt (ithare.com)
107 points by jjuhl 10 months ago | hide | past | web | favorite | 38 comments

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.

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.

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!

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.

    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

See also https://stackoverflow.com/questions/25612262/why-does-auto-x... .

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

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

> 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.

This article is interesting, but its links to the GH project [1] appear to be mishandled somehow because they link to the article itself.

[1] https://github.com/ITHare/kscope

One genuine question, is it possible for C++ committe to push for a simpler language by depracating features? Or this policy would have disastrous effect on the community?

Occasionally something gets deprecated. Like export template, trigraphs or auto_ptr. But pretty much only when there is widespread disuse and displeasure. 99% of features are used by at least 1% of the user base and need to be kept around.

So why people are nagging about C++ becoming complex?

I dont see any other way. Either you have to remove stuff from the language to make it simpler or stop introducing any new features at all. Am I right? Or is there any other way around this?

I see people constantly nagging about C++ becoming more and more complex. But I suspect of committe would depracate any features, mostly the same people would start nagging about not having backward compatibility?

> But I suspect of committe would depracate any features, mostly the same people would start nagging about not having backward compatibility?

Isn't it reasonable to desire a language that is both backwards compatible and not very complex?

Sure, but that’s not what’s being asked for. People are demanding that the language evolve over decades to become less complex while maintaining backwards compatibility. It’s a “I still want my cake after I eat it” situation.

So, instead the committee focuses on adding features such that if you migrate parts of your old code or add new code to an old project, the new code can be much simpler than it would have had to be before and the old code that no one wants to touch still compiles right along side the new stuff.

Want C++ to be simpler? Use the new features instead of the old features. Use unique_ptr instead of raw pointers. Use constexpr if instead of SFINAE. Use range based for loops. Yay! C++ is Simpler!

>Isn't it reasonable to desire a language that is both backwards compatible and not very complex?

My perspective on this is a little bit different. The answer in my opinion is no.

Let us define what compelx means : If you accept a language is a system, comprised of components (features), then defining complexity is very simple. As you may know in a system, every component interacts with every other component (unless otherwise strictly said). So the moment keeping track of these interactions becomes more than what we can track easily, we call that system a complex system.

So what you are saying is basically means adding components to a system (which is in it is already a complex system because of backward compatibility with C) without introducing complexity and not becoming a complex.

That is not simply possible.

1) You can design a simple language and keep it that way by not adding features.

2) You can remove old unused features to keep the complexity level.

Basically think about complexity from graph theory perspective. Verticies are features and edges are interactions between features.

Sure. It's reasonable to desire a pony, too.

But given an already-complex language, you're not going to get a not-very-complex language that is backward compatible, no matter how reasonable it is to want one. It's simply not possible.

What people really want is a simpler language that doesn't change the parts they use. But there's nothing hindering them from continuing to do so. Just use the parts you need, and the complexity of the rest doesn't affect you much.

A lot of implementation complexity comes from improving the user experience. E.g. you add a new feature and users will expect to be able to use all their old constructs with it.

Tools for automatically updating source code would be a good thing. It'd allow removing old compatibility features, and save time modernizing code bases. Python did it with 2to3.

Regardless, Python 3 is hardly a celebrated success story.

Backwards compatibility is very important.

What did I just read?

I had a hard time understanding the post, too.

AFAICS, kaleidoscope produces random code (which does nothing meaningful) that should compile. Then, they feed the random code into the C++ compilers Clang, gcc, and MSVC. The random code triggers bugs in the compilers, which are summarized in the post.

Actually, they don't feed the random code, but kaleidoscope uses the template system to "directly" produce randome code.

I wish there were more technical details on kaleidoscope. Just seems like lots and lots of borderline-meaningless high-level overview.

I recall being impressed the last few times I submitted bug reports to GCC. They were really on top of their game.

While this is a fairly interesting article and that code is an interesting piece of work as well, I found it a hard read solely because of the way it's presented. The bunnies, the big bold text in between the other text, the oh-so-slight difference in font size to indicate different headings (I think?), nested bullet points with sometimes only one entry in a level, making me wonder why there even is a bullet. Oh and I like humor, but those Job title/Hobbies entries, the <wink/sadface/whatever/>, I don't know, it's like everything but funny to me? Mainly distracting.

It is pretty normal that people will bikeshed about blog format on the internet, because people often don't have the technical chops to talk about the content, but why is it that these bikeshed comments get upvoted here?

I'm fairly sure I do have the technical chops to talk about the content, being very used to C++ in all it's glory, but I don't have much to add to the article: once broken down to it's intent/meaning, it's clear to me what it's about and why the code is useful. Which is why I said it's an interesting article. And why I upvoted the post.

That being said, to address your concern: this is HN, where in my experience pretty much anything can get discussed, and not-so-topnotch blog formats is one of those things. Upvotes in this case simply mean others have the same feeling with regards to the general readability of the article. Also note that, as far as I recall, there has been more than one post - not just comment - on HN exactly about this: conveying information in a proper manner is an important aspect of the internet in general. Not just bikeshedding. Even more so for technical stuff, imo.

It seems trivial but I think it's important to discuss the aesthetic of these types of things. It's not to nitpick, it's not to make fun of a person or belittle their work (I think most people here agree it's a great post!), it's to engage in a communal discussion about what we learned here so we can apply it elsewhere. Isn't that still in the spirit of HN?

I don't find the parent comment to be the most constructive example but, ignoring the subjective criticism about the jokes, I agree there's something unusually distracting about the format.

For example, the bunnies that highlight content on the right-hand side? If you're reading the entire post, you're going to read some sentences twice over -- So why are these here? For summary? Why couldn't the summary be in a more accessible area like the top?

Is this a stand up fight sir?

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact