[Deganta]

The problem is that C++ is full of so called "zero-cost-abstractions" that are only zero cost if you ignore:

1. Compile time

2. Non-optimized builds

Stuffing everything into the Standard Library using lots of template magic does has its upside, but debug performance is one of the big downsides.

Another one are really clunky interfaces, like std::variant. This should really have been a language feature, not a library features.

[titzer]

The phrase "zero-cost abstraction" is a lie anyway. It's all relative to how much compiler optimization happens. If you actually executed the C++ specification step by step, the code would be dog slow, because there are so many implicit conversions, constructions, inlining, constant folding, etc. We could quibble about how much static resolution qualifies (template expansion, overload resolution, etc--that's executing an inflated in-memory IR, and not the original source code.) Not to mention that all the rest of the compiler backend is working hard to get good machine code, and cannot possibly produce "optimal" machine code, so there is an unmeasurable cost just because of the limitations of any one particular compiler backend. (And those things matter, too!)

[olliej]

If you implemented any language following the spec in a step by step manner they would be dog slow, because any usable spec has to be very explicit in every step required for every operation.

All those conversions that you believe only happen if you implement the spec “step by step” always happen.

Actual implementations of languages then implement the explicitly described semantics, in whatever way they feel is most efficient.

[titzer]

Bah. Compiling Java to bytecode consists of a lot of static resolution steps and then a fairly straightforward, simple translation. Single-stepping the bytecodes will absolutely produce the same results as the optimized JIT code and there are few expressions that generate more than 1 to a handful of bytecodes.

[omegalulw]

Compile time and non-optimized builds aren't what you want to consider when you care about code that's going to run across thousands of cores or ultra low latency work - those are the cases where you should be considering C++ in the first place.