Around 20 years ago we had quite a few systems programming languages to choose from.
The widespread of UNIX into the industry, killed the other languages because they weren't the UNIX system programming language and other system vendors weren't able to fight against UNIX based Workstations.
So like JavaScript in the browser, C eventually killed the alternatives in the workstation market.
C++ was able to gain industry acceptance because C++ compiler vendors were actually C compiler vendors bundling C++ in their products, since C++ came from AT&T as well.
Additionally, the computers started to be fast enough for mainstream VM based systems.
The business application developers moved along to VM based languages, while the system programmers focused on the languages that were supported by larger OS vendors, C and C++.
All the compiler vendors selling system programming languages compilers that didn't enjoy first class treatment on a mainstream OS, either closed down or changed business.
So 20 years later, C and C++ became the only alternatives for systems programming, unless one wants to play with dead languages.
With Ada being used in projects that required it, or for software scenarios where human life are at risk like aviation, train control systems, medical devices and so on.
And now we are getting beaten every day in security exploits due to daggling pointers and out of bounds errors.
C++ bugs are sometimes - too often - faster to find even from disassembly than from source code. Seriously. Yes, it's a very slow approach. But you can see what's really going on, and the picture is shockingly different from the source code point of view. While disassembly is verbose, there's no syntactic sugar that can obscure true function. C++ features, like operator overloading and exceptions, locally hide actual functionality. I've seen another language that has a lot of different ways to do same thing and enabled write-only development. Perl.
No, disassembly listing is not what I typically use for debugging. Just one of the tools. The point is, something is wrong when disassembly can be easier to understand than source code!
So depressing when you need to deal with it often. Our best tool is not very good.
Well, all this puts bread on my table, so I guess I shouldn't complain too much...
Well, the problem with C++ is that it's way too easy to take its features too far. I've seen commercial C++ libraries that overloaded operators to an absurd degree. I don't recall the name at the moment, but it was a database library.
Overloading operators is a great feature, but should be used as sparingly as possible, and only where it makes intuitive sense.
Templates offer even more rope to hang yourself, and even though I'm a late convert to using templates, I would never suggest the feature goes too far. It's kludge fuel, no doubt, but the language needs the feature, and it allows you to do things that are truly useful and elegant.
It never occurred to me that viewing the disassembly could be useful for debugging, and I would imagine it's not normally useful unless you are really doing some pretty sophisticated stuff with the language. It would be extremely educational to understand what the compiler actually does however, but if inspecting the disassembly is instructive on how best to use the language, then I would suspect the language design, or at least the compiler, is doing something wrong.
I do think C++ requires a little too much consideration of how certain operations are implemented, e.g., this very discussion, but it's a price I'm willing to pay for a language that lets me do things any way I want to do them.
I program in Python in my spare time and for small scripting tasks, and can't imagine choosing C++ over Python for any personal project I've done in the past couple years (which tend to be small anyway), but I use C++ at work and am very happy to continue using it after 20 years on and off (mostly on).
The widespread of UNIX into the industry, killed the other languages because they weren't the UNIX system programming language and other system vendors weren't able to fight against UNIX based Workstations.
So like JavaScript in the browser, C eventually killed the alternatives in the workstation market.
C++ was able to gain industry acceptance because C++ compiler vendors were actually C compiler vendors bundling C++ in their products, since C++ came from AT&T as well.
Additionally, the computers started to be fast enough for mainstream VM based systems.
The business application developers moved along to VM based languages, while the system programmers focused on the languages that were supported by larger OS vendors, C and C++.
All the compiler vendors selling system programming languages compilers that didn't enjoy first class treatment on a mainstream OS, either closed down or changed business.
So 20 years later, C and C++ became the only alternatives for systems programming, unless one wants to play with dead languages.
With Ada being used in projects that required it, or for software scenarios where human life are at risk like aviation, train control systems, medical devices and so on.
And now we are getting beaten every day in security exploits due to daggling pointers and out of bounds errors.