Comment by Koshkin | Hacker News Reader

Comment by Koshkin | Hacker News Reader

The language may seem complex to some, but so does math. It is the single most powerful programming tool the world has ever known. Sure, it may be hard to see that it is beautiful, but that is so only because it is a product of both intelligent design and evolution. The language structure is extremely logical, and there is very little that could be changed in it without the danger of destroying its finely tuned fabric built from intricately interacting concepts and mechanisms. In that, it is radically different from the multitude of "pure" programming languages, some also of a respectable age, and it is because of that, unlike those languages, it became, and has been for over a quarter of century, the single most important programming language. Some may say: yes, clearly, this language is borne from good intentions, but are not these the good intentions that pave the road to hell? To that I have only one thing to say: this is where you go looking for good company :)

> there is very little that could be changed in it without the danger of destroying its finely tuned fabric built from intricately interacting concepts and mechanisms

Really? Very little? Finely tuned fabric?

Is diamond inheritance really part of that fabric? And NULL?

C++ is old and has only accumulated, never lost. When I think "finely tuned fabric", I think of Rust, which has the fortune of decades of learning. C++ piled on rvalues and move semantics. Rust is the one that "tuned" its design.

I'm not dissing C++; it's a true veteran, and has witnessed entire languages rise and fall. But let's be honest: the design of C++ is (as one would expect for a decades-old language) organic, not "finely tuned".

Is diamond inheritance really part of that fabric?

Diamond inheritance isn't a problem in C++ as each inheritance path is followed separately. A small price to pay to enjoy the power of multiple inheritance.

And NULL?

NULL is deprecated since C++ 11 in favor of nullptr.

C++ is old and has only accumulated, never lost.

You may want to have a look at the latest standards.

I don't think the usual criticisms of NULL are satisfied by it becoming slightly more type-safe.

References don't allow null.

Agreed. https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

> NULL is deprecated since C++ 11 in favor of nullptr

Pedantically, it's discouraged, not deprecated. NULL is a preprocessor constant defined in so many places, often in contradictory ways. There's no practical way for the C++ standards to deprecate it.

Compiler and analysis tools vendors could (and should) provide warnings when NULL is used when nullptr is more appropriate (which is always IMO).

Actually before nullptr was designed, the good practice in C++ was to use a plain 0, due to the way NULL is sometimes defined and how implicit conversions work.

Seeing C++ codebases using 0 for pointers instead of NULL was already a sign how up to date the respective programmers were with C++'s best practices.

Rust isn't finely tuned either, it just has memory safety (finely) turned up to 11.

I wouldn't call C++'s design organic, just severly constrained by backwards compatibility. It is finely tuned, but the results are not even close to an ideal that didn't consider C. Finely tuned doesn't imply perfection.

I really like your description, it's pretty much the same as how I think about it. But only when I'm in a subjective 'C++ all the things' mood - which happens often, especially since C++14, there's just so much to love about C++.

When I try to be objective about it though, I'd say you are glorifying too much and skipping on the darker sides of it. You and me probably now exactly how to avoid those and that's also exactly one of the reasons why for us C++ is all utter greatness. But when I see inferior, dangerous, ugly, waiting-for-UB code produced by others I realize it's not all that great. Or maybe still great - after all you could blame their lack of knowledge instead of C++ - but I really wouldn't use terms like finely tuned or extremely logcical. Seriously, I've used the language for like 10 years and it still occurs to me that I see a C++ question and corresponding answer on SO which completely baffle me because I had no clue about that particular implementation detail. There aren't many languages like that. Here's one just from today: http://stackoverflow.com/questions/39422188/difference-betwe... granted I would never write that stuff, but also I really couldn't tell 100% sure how 'const int& x = 4;' at classlevel is supposed to behave.

That is my feeling when I look at enterprise C++ code, which usually never goes beyond "C with Classes" style regardless of the improvements the language has gotten over the years, which is why in the end I came to be an happy JVM/.NET camper that only uses C++ on side projects or when JVM/.NET projects need a bit of outside help.

Let's bring up some technical details to see whether there is a deliberate thought process behind the evolution of C++. Recent versions of C++ have the auto keyword. It's a cool new feature grafted onto C++ from other languages and meant to make the programmer's life easier. It lets you avoid typing things like

  for (std::vector<std::pair<int, double>>::const_iterator it = v.begin(); it != v.end(); ++it) {
    foo(*it);
  }

The above used to be the recommended way to write a loop until C++11, and was supposedly superior to

  for (int i = 0; i < v.size(); ++i) {
    foo(v[i]);
  }

which was considered to be error prone and unsafe. But now things are much nicer and you can write

  for (auto x : v) {
    foo(x);
  }

Looks so much better. Clearly "auto" is a win for C++ programmers. But wait, it turns out that there's actually a bunch of different ways of writing the auto keyword that have subtly different semantics. You can write "auto", but you can also use every possible combination of "auto" with "const", "&" and "&&". So things like "auto&&" or "const auto&" are also perfectly valid and sometimes preferable to simple old "auto".

Let's put aside the fact that you can't explain the difference between "*", "&" and "&&" to a C programmer without them bursting out laughing. Why does auto have six different variants? Isn't this emblematic of how C++ is evolving?

At least C++ offers me tools to avoid leaking resources or corrupting memory, which cannot be said for C.

The fact that C11 made the security Annex optional, is a sign how much the C committee values writing safe code.

for (auto x : v) {

usually you'd use for(const auto& : v) though

As a light C programmer, no part of this post does not make me WTF hard. Would I actually be expected to type that cataclysm at the top? What's wrong with the C-style loop? Was 'auto' the best name they could come up with for this feature?

They have chosen auto, because it was already a reserved keyword, but it was practically useless.

Hey, try compiling this:

    template<class T,class...>class C{C<T*const,T,C>a;C<T,C>b;};C<int>c;

(c) Marc Aldorasi

Reply on news.ycombinator.com