C++ Function and Class Templates

An ordinary function fixes its parameter types. A function template replaces part of that type with a parameter such as T. Each call can instantiate a concrete function, preserving static type checking without duplicating the algorithm for int, double, or another suitable type.

Use a template when behavior is genuinely identical across types. If different types require different domain policies, named overloads or separate functions may communicate better.

#include <iostream>
#include <string>

template <typename T>
T larger(const T& first, const T& second)
{
  return second < first ? first : second;
}

int main()
{
  std::cout << larger(4, 9) << '\n';
  std::cout << larger(std::string{"Ada"}, std::string{"Grace"}) << '\n';
}

The larger template requires values that can be compared with < and returned safely through the chosen interface. Without a named constraint, those requirements emerge from the body and failures may produce long diagnostics.

C++20 concepts can name requirements such as total ordering. Even when supporting older compilers, document the expected operations and keep template bodies small enough that errors remain connected to the contract.

Standard containers are class templates: std::vector<int> and std::vector<std::string> are distinct concrete types generated from one design. Your own class template can model a fixed-size buffer, result wrapper, or generic pair when the type parameter is part of the concept.

Templates are typically defined where callers can see the implementation. Separating them into a source file requires explicit instantiation strategies and is an advanced build decision, not the default beginner layout.

A useful generic algorithm supports a coherent set of types with clear operations. It does not accept every possible type. Over-generalization can produce unreadable metaprogramming, slow builds, and contracts that appear only in diagnostics.

Start concrete, notice real duplication, then extract the stable common operation. Standard algorithms and containers already solve many generic needs; prefer them before creating another abstraction.