the zero-overhead principle

There is a fear that high-level conveniences must cost performance — that classes, templates, and smart pointers buy readability at the price of speed. C++ is built around a promise that pushes back on this, usually summarized in two parts by Bjarne Stroustrup: first, you don't pay for what you don't use; second, what you do use, you could not reasonably hand-code any better. This is the zero-overhead principle, and it explains why C++ aims to give you abstraction without an abstraction tax.

Concretely, 'don't pay for what you don't use' means a feature you never invoke imposes no cost on your program — if you don't throw exceptions, the happy path runs at full speed; if you don't use virtual functions, there is no vtable pointer or indirect call. And 'what you use is as efficient as hand-coding' means the abstractions are designed to compile down to the same machine code an expert would write by hand: a std::unique_ptr is the size of a raw pointer and its dereference is a plain load; a range-based for over a std::vector compiles to the same pointer-bumping loop as a hand-written index; a template max<int> is identical to a hand-written integer max. The compiler's job — inlining, monomorphization, optimization — is to make the abstraction evaporate.

Why it matters: this principle is why systems and game and embedded programmers can use modern C++ instead of dropping to C — they get RAII, type safety, and generics while keeping C-level control over memory and time. The honest caveats are real, though: zero-overhead is an aspiration the language is designed toward, not a guarantee in every case. Some features do carry inherent cost (shared_ptr's atomic counts, runtime exceptions on the throw path, virtual dispatch), abstractions are only zero-cost after the optimizer runs (a debug, unoptimized build can be far slower), and 'zero overhead versus equivalent hand-written code' does not mean 'free' — it means 'no worse than doing the same thing yourself'.