C++17 Compiler Bug Hunt
ithare.com
ithare.com
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 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.
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.
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.
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!
auto i = { 1 };
auto i = {5};
auto i{5};
See also https://stackoverflow.com/questions/25612262/why-does-auto-x... .
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.
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.
I wonder if there'd be a way to actually do a real comparison.
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?
Isn't it reasonable to desire a language that is both backwards compatible and not very complex?
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!
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.
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.
https://www.kdab.com/clang-tidy-part-1-modernize-source-code...
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.
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.
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?