Function & Class Templates + Template Specialization
In modern C++, we never guess what the compiler does. We look directly at byte offsets, CPU registers, and object ownership lifetimes.
Monomorphization is the process where the C++ compiler generates a distinct concrete class or function for each unique combination of template arguments. The key benefit is zero runtime overhead: function calls can be directly inlined, member offsets are statically fixed, and no virtual dispatch or type boxing is required. The trade-off is code bloat: instantiating a template with 20 different types creates 20 distinct copies of machine code in the binary, potentially exhausting instruction cache.
Two-Phase Name Lookup divides template compilation into two stages: Phase 1 occurs when the template is defined; the compiler checks syntax and resolves non-dependent names (names that do not rely on template parameters). Phase 2 occurs when the template is instantiated with concrete types; the compiler binds dependent names using Argument-Dependent Lookup (ADL). This separation ensures that general syntax errors are caught immediately while type-specific operations are validated when types are known.
The C++ committee deliberately disallowed function template partial specialization to avoid intractable interactions with function overloading. To achieve the effect of partial specialization for functions, engineers either overload the function template (template <typename T> void fn(T*)), delegate to a partially specialized helper class template, or use C++17 compile-time branching with if constexpr (std::is_pointer_v<T>).
Interviewer's lens
C++ templates are the cornerstone of high-performance systems engineering. Interviewers probe templates to verify whether you understand how the compiler monomorphizes generic abstractions into zero-overhead machine instructions. Weak candidates view templates as simple macro text substitutions or fail to explain why function templates cannot be partially specialized. Senior candidates explain Two-Phase Name Lookup (dependent vs non-dependent names), why template definitions must reside in header files, write Non-Type Template Parameter (NTTP) containers, and use full and partial specialization to achieve radical memory optimizations (like bit-packed storage).
Under the hood & memory layout
Unlike languages that implement generics via runtime type erasure or boxing (such as Java or C#), C++ compiles templates via Monomorphization. When the compiler encounters RingBuffer<int, 4> and RingBuffer<double, 8>, it synthesizes two entirely distinct, concrete assembly classes in .text, optimizing registers, vectorization, and inlining for each specific type T and constant N with zero runtime indirection or virtual dispatch overhead. Compilation proceeds in Two Phases: In Phase 1 (Definition Time), the compiler parses non-dependent names and syntax without knowing T; in Phase 2 (Instantiation Time), concrete template arguments are substituted, dependent names are resolved (typename T::iterator), and machine code is generated. Because the compiler requires the full AST/implementation to generate code at every call site, template definitions must live in header files (unless explicitly instantiated in a .cpp). While monomorphization unlocks peak execution speed, instantiating templates with many distinct types can lead to binary code bloat, which skilled engineers mitigate through shared type-erased base implementations.
Each unique combination of template arguments generates a dedicated symbol in the .text segment (e.g. RingBuffer<int, 4> and RingBuffer<double, 8> have completely separate machine code and member offsets). Identical instantiations across translation units are deduplicated by the linker via COMDAT sections.
Integral, pointer, and C++20 structural non-type parameters (std::size_t N) are embedded as compile-time constants. std::array<T, N> allocates exactly N * sizeof(T) bytes inline on the stack without heap pointers or dynamic capacity overhead.
Class templates support partial specialization (e.g. TypeInspector<T*> matching all pointers). The compiler matches the most specialized pattern at compile time; if no partial specialization matches, it falls back to the primary template with zero runtime branch instructions.
A generic FixedStorage<T, N> consumes N * sizeof(T) bytes. In C++, sizeof(bool) == 1 byte (wasting 7 bits per boolean). A partial specialization FixedStorage<bool, N> stores booleans in a contiguous uint8_t array of (N + 7) / 8 bytes, reducing memory usage by 87.5%.
Core concepts & syntax traps
Two-Phase Name Lookup & Template Monomorphization
Two-Phase Name Lookup & Template Monomorphization
When compiling a template, the compiler employs Two-Phase Name Lookup:
- Phase 1 (Parsing / Non-Dependent Lookup): At the point of template definition, the compiler parses the code and verifies syntax. Any name that does not depend on a template parameter (e.g. standard library calls or local non-dependent types) is looked up and validated immediately. Errors in non-dependent code are caught even if the template is never instantiated.
- Phase 2 (Instantiation / Dependent Lookup): When the template is instantiated with a concrete type (e.g.
RingBuffer<int, 4>), the compiler substitutes the concrete types and performs Argument-Dependent Lookup (ADL) for dependent names (T::value_type,obj.process()). Because the compiler generates specialized machine code for every type combination, templates have zero runtime dynamic dispatch overhead.
template <typename T>
void process(T val) {
nonExistentFunction(); // Phase 1 Error: Non-dependent name fails immediately!
val.customMethod(); // Phase 2: Checked only when T is instantiated
}Non-dependent names are checked at template definition time (Phase 1); dependent names are checked at instantiation time (Phase 2).
Why Templates Must Be Defined in Header Files
Why Templates Must Be Defined in Header Files
In non-template C++, you can declare a function in a .h file (void compute(int);) and define it in a .cpp file because the compiler only needs to know the calling convention and argument types to emit a call instruction, leaving the address to be resolved by the linker. With templates, however, the compiler cannot emit concrete object code without having access to the full template definition when the template is invoked with concrete types. If a template function is defined in a separate .cpp file, other translation units will fail at link time with undefined reference errors. The only alternative to defining templates in headers is Explicit Template Instantiation (template class RingBuffer<int, 10>; placed in the .cpp file), which limits instantiation strictly to pre-declared types.
// RingBuffer.h:
template <typename T, std::size_t N>
class RingBuffer {
public:
bool push(const T& item); // If definition is in RingBuffer.cpp...
};
// main.cpp:
RingBuffer<int, 4> rb;
rb.push(10); // LINKER ERROR: undefined reference to RingBuffer<int, 4>::push!
// Fix: Move the definition of push() directly into RingBuffer.h!Templates must be defined in header files because the compiler needs the complete implementation to generate concrete code at the call site.
Non-Type Template Parameters (NTTP)
Non-Type Template Parameters (NTTP)
A template parameter does not have to be a type; it can also be a value known at compile time, known as a Non-Type Template Parameter (NTTP). Permissible NTTP types include integers (int, std::size_t), enumerations, pointers, lvalue references, and (since C++20) structural classes with public members. NTTPs allow containers like std::array<T, N> or RingBuffer<T, N> to embed storage directly inside the object layout, eliminating heap allocation and enabling loop unrolling, compile-time bounds checking, and static assertions (static_assert(N > 0)).
template <typename T, std::size_t Capacity>
class StaticStack {
T data_[Capacity]; // Stack allocated, zero dynamic memory!
std::size_t top_{0};
public:
static_assert(Capacity > 0, "Capacity must be positive");
constexpr std::size_t max_size() const noexcept { return Capacity; }
};NTTPs embed compile-time constants into types, enabling fixed-capacity, zero-heap containers.
Full vs Partial Template Specialization
Full vs Partial Template Specialization
Template specialization allows customizing implementation for specific types:
- Explicit (Full) Specialization: Replaces the primary template for an exact concrete type (
template <> class Serializer<bool>). Both class and function templates can be fully specialized. - Partial Specialization: Customizes a class template for a family of types (e.g. all pointer types
template <typename T> class Box<T*>, all reference typesBox<T&>, or fixed NTTP valuesBox<T, 0>). When multiple specializations match, the compiler chooses the most specialized candidate based on formal partial ordering rules.
// Primary template:
template <typename T> struct Formatter { /* generic */ };
// Partial specialization for all pointers:
template <typename T> struct Formatter<T*> { /* prints pointer target */ };
// Full specialization for const char* string:
template <> struct Formatter<const char*> { /* prints quoted C-string */ };Class templates support both full and partial specialization; use partial specialization to treat all pointers, references, or arrays uniformly.
Why Function Templates Cannot Be Partially Specialized
Why Function Templates Cannot Be Partially Specialized
A notorious trap in C++ is that function templates CANNOT be partially specialized—the language standard explicitly prohibits it! Writing template <typename T> void print(T* ptr) is NOT a partial specialization; it is a separate, overloaded function template. Mixing function template overloading with full specialization leads to subtle, counterintuitive lookup bugs because full specializations do not participate in overload resolution—they attach to whichever base template was chosen first. The idiomatic senior C++ solution is to delegate the function call to a static member of a helper struct template (which can be partially specialized cleanly) or to use C++17 if constexpr (std::is_pointer_v<T>).
template <typename T> void render(T val); // Base function template
template <typename T> void render(T* val); // Overload 1 (NOT partial specialization!)
// Modern Idiomatic Alternative: if constexpr
template <typename T>
void modernRender(const T& item) {
if constexpr (std::is_pointer_v<T>) {
std::println("Pointer value: {}", *item);
} else {
std::println("Direct value: {}", item);
}
}Never try to partially specialize a function template; use function overloading, helper structs, or C++17 if constexpr instead.
Unlock Live Implementation & Interview Scenarios
The C++23 production code, live coding steps, scenario twist solutions, and common UB traps are part of Brute2Best Pro. Module 1 is completely free.
First anchor question per pattern, Part 1 LLD & Module 1 C++ basics are 100% Free forever.