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!)

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.

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.

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.