23. Templates

Advanced perspective: generality must be earned at the boundary

A template earns its generality only when every admitted argument preserves the same relationship

A template defines a family of declarations. It is not one function or class that changes type at runtime, and it is not untyped text pasted into a program. Template arguments determine which member of the family is considered, constraints decide whether that use is admitted, and the resulting specialisation is checked as C++.

The tempting measure of success is that one definition compiles for several types. That proves reuse of syntax. It does not prove reuse of meaning. If an operation called add truncates one type, overflows another and has no sensible interpretation for a third, increasing the number of accepted types has made the interface broader without making it better.

Trace the preserved program before claiming that it is generic

#include <concepts>
#include <iostream>

template<std::integral T>
T add(T left, T right) {
    return left + right;
}

int main() {
    std::cout << add(4, 7) << '\n';
    std::cout << add(20L, 22L) << '\n';
}

The first call presents two int arguments, so deduction selects T = int. The associated constraint is satisfied, the program can use the add<int> specialisation, and the call prints 11. The second call presents two long arguments. It uses add<long> and prints 42. Nothing in either call asks a runtime object which implementation it prefers. The types have already settled the relationship during compilation.

The mixed call is important. The compiler does not silently invent a common template argument merely because int can convert to long. This template asks both function parameters to establish the same T, and deduction finds different answers. An explicit add<long>(4, 22L) would state a conversion policy visibly. A two-parameter template could state another policy. The interface must choose; the word generic cannot choose on its behalf.

Deduction, viability, selection and instantiation answer different questions

A long diagnostic becomes less mysterious when the compilation decisions are separated. The precise language rules contain qualifications, but the following trace is a useful account of these calls:

Failure at one stage does not justify changing another at random. If deduction conflicts, removing a concept does not repair deduction. If a constraint fails, adding a cast inside the function body cannot make the candidate satisfy that constraint. If two viable overloads are ambiguous, proving that either body would compile does not select between them.

A constraint states what may enter; it does not establish what the operation means

std::integral is a precise type-category requirement. It admits the language's integral types, which include Boolean and character types as well as the familiar signed and unsigned integer types. Consequently, add(true, true) satisfies this constraint: built-in addition produces an int, which is converted back to the declared bool result. The call compiles and returns true. Whether that deserves to be called addition is a design question the concept does not answer.

The same boundary does not prevent signed overflow, guarantee that a result is representable, reconcile signed and unsigned arithmetic or prove algebraic laws. Concepts and requires-expressions can state operations and type relationships that the compiler can check. The behavioural contract must still explain what valid inputs mean and what result the caller is entitled to expect.

Template checking occurs at more than one point

A template definition is parsed when it is declared, and non-dependent names and constructs can be checked in that definition context. Other constructs depend on template parameters. Their meaning can only be completed after substitution for a particular specialisation. It is therefore too broad to say either that the template is fully checked when first seen or that no checking occurs until use.

This distinction matters when reading an error. A misspelled visible function name may be diagnosed while the template is defined. An expression such as value.process(), where the validity depends on T, may fail for a particular attempted specialisation. The location of the diagnostic tells you where the compiler discovered the problem; the dependency tells you why it could or could not decide earlier.

Choose parameters that expose the real variation

A type parameter is appropriate when an algorithm retains one relationship across a family of types. A constant template parameter records a compile-time value, such as the extent in Fixed<T, N>. A template template parameter accepts another template. These are not three ways to make code look more advanced. Each exposes a different decision to the caller and creates a different family of specialisations.

Class templates add another useful qualification. Naming a class specialisation does not necessarily instantiate every member definition immediately. The language instantiates what the context requires. A member that would be invalid for one T may remain irrelevant until that member is used, although the class boundary and any constraints still need coherent design.

Definition visibility is a reachability rule, not a header superstition

An implicitly instantiated function or member needs a reachable definition. Headers are the usual solution because each translation unit that needs a specialisation can see the template definition. That does not make a header the only possible organisation. Explicit instantiation can place selected specialisations in a controlled translation unit, provided declarations, definitions and the supported argument set are organised consistently.

The trade-off is real. A visible general definition permits new specialisations wherever the interface allows them. A controlled explicit-instantiation set can reduce repeated work and hide implementation detail, but it also turns the supported types into a list that must be maintained. Choose according to the intended extension boundary, not from the slogan that templates live in headers.

Overload or specialise only when the variation genuinely changes

Constraints can order function-template candidates when one expresses a more specific admitted set. An ordinary overload is often clearer when one type needs different behaviour. Class and variable templates can be partially specialised for a family of arguments; function templates cannot be partially specialised, so function overloading normally expresses that form of variation. Full explicit specialisation exists, but it introduces reachability and ordering obligations that should not be hidden behind a convenient exception.

The criterion is whether the variation belongs to the interface. If every type follows the same operation and only its representation differs, a primary template may be enough. If one family has a stronger requirement, a constrained overload or partial specialisation may state it. If the meaning changes completely, a different named operation may be more honest than forcing the case into the same template family.

Generic code moves costs; it does not abolish them

Templates can expose types and operations to optimisation and remove some runtime indirection. They can also increase compilation work, diagnostic volume and generated code size when many distinct specialisations are formed. Linkers and compilers may merge or remove some generated material, and a larger binary is not proof of a runtime problem. Measure the build or execution concern that matters, then decide whether explicit instantiation, a non-template boundary or type erasure addresses that measured cost.

Transfer task: test whether one arithmetic template really has one meaning

Consider template<std::integral T> T mean(T left, T right) with the body return (left + right) / 2;. Trace deduction, constraint satisfaction, intermediate expression types and the returned value for mean(3, 4), two maximum int values, two bool values, two character values and a mixed int/long call. Separate rejection at the boundary from truncation, overflow and surprising admitted types inside the boundary.

Produce two designs. The first may remain a constrained template, but it must state its admitted types, result type, rounding rule and overflow policy, with tests for every boundary. The second should be a narrower ordinary function or overload set for the domain that actually needs a mean. Choose between them by the relationship callers can rely upon, not by the number of types made to compile.

#include <concepts>
#include <numeric>
#include <type_traits>

template<class T>
concept MeanInteger =
    std::integral<T>
    && !std::same_as<std::remove_cv_t<T>, bool>
    && !std::same_as<std::remove_cv_t<T>, char>
    && !std::same_as<std::remove_cv_t<T>, signed char>
    && !std::same_as<std::remove_cv_t<T>, unsigned char>
    && !std::same_as<std::remove_cv_t<T>, wchar_t>
    && !std::same_as<std::remove_cv_t<T>, char8_t>
    && !std::same_as<std::remove_cv_t<T>, char16_t>
    && !std::same_as<std::remove_cv_t<T>, char32_t>;

template<MeanInteger T>
T mean(T left, T right) noexcept
{
    return std::midpoint(left, right);
}

#include <stdexcept>

int mean_mark(int left, int right)
{
    if (left < 0 || left > 100 || right < 0 || right > 100) {
        throw std::out_of_range{"mark must be in [0, 100]"};
    }

    return (left + right) / 2; // round down for a non-negative odd total
}

A useful template preserves one named relationship while types or compile-time values vary. Deduction and constraints can police the entrance to that family. They cannot decide the family should exist. Generalise only after the invariant operation, the admitted variation and the evidence for both are clear.