The problem: one algorithm, many types
By now you can build a leak-free owning container in C++ — a unique_ptr, a small vector, a node holding a resource. But look closely and you will notice each one is married to a single type. A stack of `int` and a stack of `double` are line-for-line the same algorithm, differing only in the type word. In C you had two honest but ugly escapes from this: write the code twice (and maintain both copies forever), or erase the type behind a `void *` and lose all type checking. Neither is good, and you felt the sting of both in the earlier rungs.
A template is C++'s third answer, and it is the one that costs nothing. You write the algorithm once, with the type left as a blank to be filled in later — a parameter named `T` instead of a concrete type. This is generic programming: code parameterized over types, not just over values. The crucial thing to grasp first is that a template is not itself code that runs. It is a pattern the compiler reads and then generates code from, once per distinct type you actually use. Think of it as a stencil: the stencil is not paint, but you can press real paint through it as many times as you like.
template <typename T>
T max_of(T a, T b) {
return (a < b) ? a : b == b ? (a < b ? b : a) : a; // illustrative; see below
}
// the honest, normal version:
template <typename T>
T maxv(T a, T b) { return (a < b) ? b : a; }
int x = maxv(3, 7); // compiler stamps out maxv<int>(int, int)
double y = maxv(2.5, 1.5); // and a SEPARATE maxv<double>(double, double)
// two real functions now exist in the binary, each compiled for its own typeMonomorphization: where the magic (and the cost) hides
The step where the compiler fills in the blank and produces a concrete function is called instantiation, and the overall strategy of generating a fresh, fully-typed copy for each type is monomorphization — literally "making it single-typed." When you call `maxv(3, 7)`, the compiler deduces `T = int`, instantiates `maxv<int>`, and from that point on it is just an ordinary function taking two ints. There is no `T` left at runtime, no type tag travelling alongside the data, no decision made while the program runs about which version to call. The type was resolved entirely at compile time.
This is precisely why generics in C++ (and in Rust, which monomorphizes the same way) are fast. Each instantiated copy is specialized for its exact type, so the optimizer sees concrete operations it can inline and tune. Compare this with the alternative strategy of type erasure, where a single compiled function handles every type by going through a pointer or a vtable — that is dynamic dispatch, and it pays an indirection at every call. Templates instead resolve everything statically, so a call into a templated container compiles down to the same instructions you would have hand-written for that one type.
Templates as the zero-overhead principle made concrete
Recall the zero-overhead principle from the RAII guide, stated by Bjarne Stroustrup in two halves: you do not pay for what you do not use, and what you do use is as efficient as hand-written code. Templates are the second half made real for abstraction. A `std::sort` written generically, when instantiated for your type, produces machine code as tight as a sort you hand-coded for that one type — often tighter, because the comparison can be inlined straight into the loop with no function-call overhead at all.
Put this beside the alternatives a systems programmer actually faces and the win is stark. A `void *`-based generic in C cannot inline its callback — the comparison goes through a function pointer the optimizer cannot see through, so every element comparison is a real indirect call. A garbage-collected language boxes small values on the heap to make them generic. The template pays neither price: the type is known at compile time, so the optimizer sees everything and can specialize the loop completely. This is the deep reason C++ templates and Rust generics let you write one expressive abstraction and still hit the performance of bespoke code.
Concepts: constraining the blank
Templates have one famously sharp edge. Because `T` is just a blank, the only check the compiler can do is to try the substitution and see if the body compiles. If you call `maxv` with a type that has no `<` operator, the error does not appear at your call — it erupts deep inside the template body, often as a wall of text mentioning instantiations you never wrote. For decades this was the tax you paid for generic code, papered over with a fragile trick called SFINAE ("substitution failure is not an error") that let library authors hide overloads a type could not satisfy, at the cost of unreadable code.
Concepts, added in C++20, fix this honestly. A concept is a named, compiler-checked predicate on a type: a way to say in the template's own signature "`T` must support `<`," or "`T` must be an integer." If you call the function with a type that fails the concept, the error now points at your call and reads like a sentence — "the type does not satisfy `std::totally_ordered`" — instead of vomiting the template's guts. Crucially, concepts are a pure compile-time check: they constrain which instantiations are allowed and add not one byte and not one cycle to the running program. They make generic code safer and the diagnostics humane, at zero runtime cost.
Reading a template instantiation, step by step
To make all of this concrete, trace exactly what the compiler does when it meets the call `auto v = maxv(2.5, 1.5);` for the first time. Follow the sequence and notice that every interesting decision happens before the program ever runs.
- Argument deduction: the compiler looks at the arguments 2.5 and 1.5, sees both are double, and deduces T = double for this call.
- Constraint check: if maxv has a concept (say, requires std::totally_ordered<T>), the compiler verifies double satisfies it. If not, you get a clear error here, at the call.
- Instantiation: the compiler stamps the template body out with T replaced by double, producing a concrete function maxv<double>(double, double). No T remains.
- Optimization: that concrete function is now ordinary code. The optimizer inlines it into the caller, and the comparison becomes a single double-compare instruction — zero abstraction overhead.
- Reuse: a later maxv(9.0, 4.0) deduces double again and reuses the SAME maxv<double>; only a brand-new type triggers a fresh instantiation.
Step back and the whole arc of this rung lines up. RAII gave deterministic cleanup at no runtime cost; move semantics let resources travel without copying; smart pointers wrote ownership into the type; and now templates let you write those owning, cleanup-aware abstractions once and have them stay zero-overhead across every type. The next and final guide pushes the timeline even further left — to constexpr and consteval, where whole computations run during compilation — and looks at custom allocators and non-owning views that let you control exactly where memory comes from while keeping the same abstraction-with-no-tax bargain you have now seen four ways.