Templates

When you call getMax(5, 3), the compiler looks at the arguments, sees they're both int, and generates a real, concrete version of the function with T replaced by int — as if you'd hand-written the int version yourself. Call it again with doubles, and it generates a SEPARATE concrete version for double. This process is called instantiation.

template <typename T>
class Box {
private:
    T contents;
public:
    Box(T value) : contents(value) {}
    T getContents() { return contents; }
};

Box<int> intBox(42);
Box<std::string> strBox("Hello");

std::cout << intBox.getContents();   // 42
std::cout << strBox.getContents();   // Hello

This is precisely Phase 5's class syntax, with template <typename T> added and T used wherever a specific type would normally appear. Box<int> and Box<std::string> are genuinely different, separate types once instantiated — but they share one single piece of source code.

std::vector itself is essentially a (far more sophisticated) class template — that's exactly why std::vector<int> and std::vector<std::string> both work identically, using the exact same underlying code, just instantiated for different types. You now understand the actual mechanism behind syntax you've been using since Phase 7.

getMax(5, 3);           // compiler infers T = int
getMax<int>(5, 3);    // explicitly stating T = int — identical result, rarely needed

Genuinely similar to Phase 8 Module 7's auto — the compiler looks at the actual arguments you pass and deduces T automatically. You almost never need to write getMax<int>(...) explicitly; it's available when genuinely needed, but the implicit version is the normal, everyday style.

template <typename T1, typename T2>
void printPair(T1 first, T2 second) {
    std::cout << first << " and " << second << std::endl;
}

printPair(42, "apples");   // T1 = int, T2 = const char* — genuinely different types, no problem

You can declare as many independent placeholder types as you genuinely need, separated by commas. Each parameter's type is deduced independently — this directly fixes Module 4's mismatched-type trap, since T1 and T2 are no longer forced to match.

template <typename T1, typename T2>
class Pair {
public:
    T1 first;
    T2 second;
};

std::pair<std::string, int> from Phase 7 Module 9 is precisely this pattern — two independent template parameters, letting the key and value hold genuinely different types. std::map<K, V> follows the exact same idea underneath.

Suppose a generic describe(T value) template prints a value directly — that works fine for numbers, but for a bool, printing raw 1 or 0 is far less readable than printing "true" or "false". Template specialization lets you write a genuinely different implementation specifically for one particular type, while every OTHER type still uses the generic version.

template <typename T>
void describe(T value) {
    std::cout << "Value: " << value << std::endl;
}

template <>   // empty <> means this is a full specialization
void describe<bool>(bool value) {
    std::cout << "Value: " << (value ? "true" : "false") << std::endl;
}

describe(42);     // uses the generic version — "Value: 42"
describe(true);   // uses the bool specialization — "Value: true"

The compiler always prefers a specialization that exactly matches the type being used — describe(true) genuinely calls the bool version, while everything else falls through to the generic template.

template <typename Iterator>
void sort(Iterator begin, Iterator end) {
    // sorting logic that works for ANY container's iterators
}

This is exactly why Phase 7 Module 7's std::sort worked identically on a vector<int> and could equally work on a vector<std::string> or your own Box<T> objects (if they supported comparison) — one function template, genuinely reused across countless different types.

Build a Stack<T> class template — last-in-first-out storage — with push, pop, and top operations, that works identically whether T is int, std::string, or a custom class, without writing it more than once.

#include <iostream>
#include <vector>
#include <stdexcept>

template <typename T>
class Stack {
private:
    std::vector<T> items;
public:
    void push(T value) {
        items.push_back(value);
    }

    void pop() {
        if (items.empty()) {
            throw std::runtime_error("Cannot pop from an empty stack");
        }
        items.pop_back();
    }

    T& top() {
        if (items.empty()) {
            throw std::runtime_error("Cannot access top of an empty stack");
        }
        return items.back();
    }

    bool empty() {
        return items.empty();
    }
};

int main() {
    Stack<int> intStack;
    intStack.push(1);
    intStack.push(2);
    intStack.push(3);
    std::cout << "Top: " << intStack.top() << std::endl;   // 3
    intStack.pop();
    std::cout << "Top after pop: " << intStack.top() << std::endl;   // 2

    Stack<std::string> strStack;   // the SAME class template, a completely different type
    strStack.push("hello");
    std::cout << "String stack top: " << strStack.top() << std::endl;

    return 0;
}

(throw std::runtime_error(...) is a preview of Phase 10's exception handling — for now, just recognize it as "signal that something went genuinely wrong.")

• std::vector<T> internally handles the actual storage — Module 6's insight that STL containers are themselves templates, reused here directly rather than reinventing dynamic storage.
• Both pop() and top() check empty() first — Phase 5 Module 6's encapsulation/validation principle, protecting the class from an invalid operation.
• Stack<int> and Stack<std::string> are genuinely separate types (Module 3), yet came from writing this class exactly once.