> The reason is that C++ is more than a language: it is part of an actually philosophical quest that language design is about.
> It is about trying to bridge the language of the machines and the language of human abstractions as closely as possible. In itself it does not necessarily lead to the best language possible, but it explores an interesting limit.
> C++ strives to be a language where you can still feel what the machine will actually implement while you code high-level abstractions.
This has been false ever since the earliest days of ANSI C. The C and C++ standards define an abstract machine that is quite far from any machine that exists today. Type-based aliasing rules, to name one important example, are something that has almost nothing to do with anything that exists in the hardware.
It's quite enlightening to read the description of LLVM IR [1] and observe how far it is from anything a machine does. In fact, LLVM IR is quite a bit lower level than C is, as memory is untyped in LLVM IR without metadata: this is not at all the case in C.
In reality, C++ is an attempt to build a high-level language on top of the particular abstract virtual machine specification that happened to be the accidental byproduct of a consensus process among hardware/compiler vendors in 1989. It turns out that this has been a very helpful endeavor for a lot of people, but I don't think we should claim that it's anything more than that. There's nothing "philosophically" interesting about the C89 virtual machine.
I don't see how type aliasing negates anything of what I am saying. Types are an abstraction but C++ allows you to extract its pointer, to make a sizeof() of it, to do pointer casting and arithmetics.
You can go low level with most high level languages, what sets C++ apart is that using low-level instructions have generally zero overhead. ptr2 = static_cast<uint8_t*>(ptr)+5; pretty much maps to the assembly code you would expect.
> Types are an abstraction but C++ allows you to extract its pointer, to make a sizeof() of it, to do pointer casting and arithmetics.
And the semantics of those operations are dictated not by what the underlying machine does but what the C++ abstract machine does, which is very different. The underlying memory is still typed.
> You can go low level with most high level languages, what sets C++ apart is that using low-level instructions have generally zero overhead.
That's true for the JVM, .NET, even JS...
> ptr2 = static_cast<uint8_t*>(ptr)+5; pretty much maps to the assembly code you would expect.
No, it doesn't, not after optimizations and undefined behavior. It's perfectly acceptable for the compiler to turn that into a no-op if, for example, "ptr" was a null pointer.
OTOH it has become more true over time, because C and C++ based hardware and software platforms became dominant and processors are now designed to just run C(++) as well as possible.
CPUs no longer commonly implement integer overflow checking, granular hardware based memory safety primitives, efficient user level exception handling, etc.
Even though it's not the real machine it's still a lot closer to it than you get from the higher level languages mentioned by parent commenter like they said.
Once you have the concept of user-defined aggregate types that are meaningful to the semantics of your VM (which C and C++ definitely do), then you're pretty far away from the machine. The difference between the C VM and the .NET VM is not nearly as wide as the difference between the native instruction set and the C VM.
That's the point: C++ allows to go pretty high on the abstract side, but it gives all the tools to map how the high level abstractions are implemented on the low level side.
I think that while it is true, and I am a big C++ fan, given it was my path after Turbo Pascal, exactly because I am a fan of Wirth and Xerox PARC languages I also know there are better paths.
An example is the work being done in .NET Native, C#'s roadmap up to 8 picking up Midori's work, D, Swift, Java 10 and so on.
C++ got this position, because the others stop caring about those issues.
Now that they finally started caring about them, lets see what the future holds.
Oh like I said I have a love-hate thing with C++. Nowadays I mostly do C# and python, with a bit of Java. I only rely on C++ when I have to do brutal per pixel computer vision algorithms.
In most cases you can rely on libraries to do the heavy duty (and then I stick to python or C#) but sometime you have to take the big C++ hammer and try to not hit your fingers with it.
> It is about trying to bridge the language of the machines and the language of human abstractions as closely as possible. In itself it does not necessarily lead to the best language possible, but it explores an interesting limit.
> C++ strives to be a language where you can still feel what the machine will actually implement while you code high-level abstractions.
This has been false ever since the earliest days of ANSI C. The C and C++ standards define an abstract machine that is quite far from any machine that exists today. Type-based aliasing rules, to name one important example, are something that has almost nothing to do with anything that exists in the hardware.
It's quite enlightening to read the description of LLVM IR [1] and observe how far it is from anything a machine does. In fact, LLVM IR is quite a bit lower level than C is, as memory is untyped in LLVM IR without metadata: this is not at all the case in C.
In reality, C++ is an attempt to build a high-level language on top of the particular abstract virtual machine specification that happened to be the accidental byproduct of a consensus process among hardware/compiler vendors in 1989. It turns out that this has been a very helpful endeavor for a lot of people, but I don't think we should claim that it's anything more than that. There's nothing "philosophically" interesting about the C89 virtual machine.
[1]: https://llvm.org/docs/LangRef.html