Chapter 5: Template Foundations

STL 的泛型接口看起来像一组普通函数和普通类型：std::vector<int> 是一个类型，std::sort(first, last) 是一次函数调用，std::array<int, 4> 把元素类型和长度写进类型本身。编译器处理这些写法时，先看到的是模板定义，再根据具体实参生成某个特化版本。读模板源码时，核心任务是判断参数从哪里来、什么时候实例化、名字在什么时机查找、错误会在定义点还是使用点出现。

本章用一个贯穿材料串起模板基础：一个最小的固定容量缓冲区 StaticBuffer<T, N>，再配合几个函数模板和 trait。它接近 std::array<T, N> 的形状，也能解释后续 iterator、allocator、algorithm 和 traits 为什么大量使用模板。材料很短，重点放在编译期类型规则、运行时对象关系和 STL 设计后果之间的连接。

#include <cstddef>
#include <type_traits>
#include <utility>

template<class T, std::size_t N>
struct StaticBuffer {
    using value_type = T;

    T data[N]{};

    constexpr std::size_t size() const noexcept {
        return N;
    }

    constexpr T& operator[](std::size_t index) noexcept {
        return data[index];
    }

    constexpr const T& operator[](std::size_t index) const noexcept {
        return data[index];
    }
};

template<class Buffer>
constexpr auto first(Buffer& buffer) -> typename Buffer::value_type& {
    return buffer[0];
}

这段教学材料把 N > 0 作为前提，用来突出模板参数和依赖名路径；真实 std::array 还要处理零长度、聚合初始化、迭代器接口和标准要求。

这段代码包含本章要追踪的全部问题：T 是类型模板参数，N 是非类型模板参数，StaticBuffer<int, 4> 才是具体类型，first 的返回类型依赖 Buffer::value_type，constexpr 让部分调用可以进入常量表达式，模板定义通常放在头文件中让使用点能够实例化。读 STL 源码时，可以先按这个顺序拆解：参数列表决定泛型入口，实例化点决定错误暴露位置，依赖名决定查找时机，constexpr / inline 决定头文件边界和编译期求值能力。

5.1 函数模板、类模板与实例化时机

模板定义描述一组潜在实体，模板特化才是编译器真正检查并生成的具体函数或具体类型。cppreference 的模板页面把模板归为类模板、函数模板、别名模板、变量模板和 C++20 concept 等实体，并说明给出模板实参或推导出实参后，会用这些实参替换模板参数得到某个特化版本。对 STL 来说，这个规则解释了为什么一个 std::vector 模板能生成 std::vector<int>、std::vector<std::string> 和 std::vector<std::unique_ptr<T>> 等不同类型。

函数模板更像一组候选函数的生成规则。调用发生时，编译器先做名字查找，再进行模板参数推导和替换，然后进入重载决议。下面的 max_value 只有一个定义，但 max_value(1, 2) 和 max_value(1.0, 2.0) 会指向不同的特化版本。

template<class T>
constexpr T max_value(T left, T right) {
    return left < right ? right : left;
}

int a = max_value(1, 2);          // T 推导为 int
double b = max_value(1.0, 2.0);   // T 推导为 double

这里的运行时对象关系很直接：max_value<int> 接收两个 int，返回一个 int；max_value<double> 接收两个 double，返回一个 double。模板本身不携带某个统一的运行时对象，编译期为每组参数建立相应的函数特化。这个规则支撑 STL 算法的零额外抽象开销模型：std::sort 针对 iterator 类型、比较器类型和元素操作生成具体调用路径，运行时不需要通过一个公共基类转发所有操作。

类模板生成的是类型家族。StaticBuffer<int, 4> 和 StaticBuffer<int, 8> 是两个不同类型，因为非类型模板参数 N 也参与类型身份；StaticBuffer<int, 4> 和 StaticBuffer<double, 4> 同样是两个不同类型，因为元素类型不同。

StaticBuffer<int, 4> small{};
StaticBuffer<int, 8> large{};

static_assert(!std::is_same_v<decltype(small), decltype(large)>);

实例化时机决定错误暴露位置。类模板特化在需要完整对象类型时会被实例化；类模板的成员函数体通常在被使用时才实例化。这个规则解释了很多 STL 报错会沿着调用链延迟爆发：定义一个容器类型可能通过，真正调用某个成员或算法时才暴露元素类型缺少拷贝构造、比较操作或 allocator 接口的问题。

template<class T>
struct DelayedCheck {
    void only_for_four_byte_type() {
        static_assert(sizeof(T) == 4);
    }
};

DelayedCheck<double> object;      // 类型可形成
// object.only_for_four_byte_type(); // 使用该成员时触发 static_assert

这个例子的覆盖范围是成员函数体延迟实例化。非依赖语法错误、模板定义中可立即确定的名字错误、当前实例化中可判定的成员访问错误，会在模板定义阶段或更早阶段被诊断。读源码时要区分两类材料：模板定义中已经固定的部分，和依赖模板参数的部分。前者在定义点绑定，后者等到实参进入后继续处理。

模板实例化可以用下面的路径理解。本图只描述常见隐式实例化路径，显式实例化、显式特化和模块边界另有更细规则。

工程判断顺序是：先确认眼前名字是模板定义还是某个特化，再确认模板实参由调用推导、显式指定还是默认参数提供，接着判断当前上下文是否要求完整类型或函数体，最后再分析报错来自定义点、替换阶段、重载决议还是成员实例化。STL 的报错信息长，根因经常在这个顺序的中间某一步。

5.2 模板参数推导与非类型模板参数

模板参数推导把调用实参的类型和值映射到模板形参。模板参数推导规则涉及数组退化、引用、cv 限定、函数指针、初始化列表、重载集等细节，本节先固定读 STL 最常用的判断：函数模板调用中，编译器从函数形参模式和调用实参进行匹配；多个匹配结果必须合并成一致的模板实参。

下面的 same_type 要求两个参数推导出同一个 T。same_type(1, 2) 推导成功；same_type(1, 2.0) 中第一个实参给出 T = int，第二个实参给出 T = double，两个结果不一致，调用失败。

template<class T>
bool same_type(T left, T right) {
    return left == right;
}

bool ok = same_type(1, 2);
// bool bad = same_type(1, 2.0);

这个失败发生在模板参数推导阶段，尚未进入函数体。调用者可以显式指定模板实参，让普通转换在函数调用阶段发生。

bool converted = same_type<double>(1, 2.0);

这个写法的语义是先固定 T = double，再把第一个实参从 int 转成 double。STL 算法中经常出现类似边界：某个模板参数能从 iterator、value、predicate 推导出来；某个参数位于不可推导上下文时，需要显式给出，或者通过 traits、默认模板参数、重载形状间接提供。

非类型模板参数把值放进类型或函数特化中。StaticBuffer<T, N> 的 N 是 std::size_t 值，它参与 StaticBuffer<int, 4> 的类型身份。这个能力让 std::array<T, N> 这类固定大小对象把长度作为编译期信息传播给算法。

template<class T, std::size_t N>
constexpr std::size_t extent_of(const StaticBuffer<T, N>&) noexcept {
    return N;
}

StaticBuffer<int, 16> buffer{};
static_assert(extent_of(buffer) == 16);

运行时对象 buffer 中有 data 数组；编译期类型 StaticBuffer<int, 16> 中携带长度 16。extent_of 返回的值来自模板参数，不需要读取运行时成员。这个模式在 STL 中很常见：std::array<T, N> 的大小、std::span<T, Extent> 的静态 extent、某些 traits 的布尔值，都把一部分信息提前到编译期。

非类型模板参数也有边界。C++ 标准版本会影响可用参数种类：早期常见的是整型、枚举、指针、引用等；C++20 放宽了结构化非类型模板参数的能力。写跨版本库时，应先确认目标标准版本，再决定是否把某个值写入模板参数列表。STL 读源码时也应保持这个习惯：看到 template<class T, size_t N> 可以直接按 C++11 之后的固定大小模式理解；看到更现代的 class type 非类型模板参数，需要检查标准版本边界。

模板参数推导的工程后果可以浓缩成一个顺序：先看函数形参模式是否暴露了某个模板参数，再看调用实参是否能提供唯一结果，再看显式模板实参是否已经固定部分参数，再看普通隐式转换发生在哪个阶段。把这四步拆开后，很多 “为什么这里推导不出来” 的 STL 问题会变成可定位的匹配失败。

5.3 variadic templates、特化与偏特化

可变参数模板用参数包表达“数量未知的一组模板参数”。参数包规则让模板能接收任意数量的类型、值或模板参数。STL 中的 std::tuple、std::variant、std::function 的包装构造、std::make_unique、容器的 emplace 家族，都依赖这种“把调用参数原样带入构造路径”的能力。

下面的 construct_in_place 是简化版 emplace 思路：Args&&... 接收一组参数，std::forward<Args>(args)... 对每个参数做一次展开，把参数交给 T 的构造函数。

template<class T, class... Args>
T construct_value(Args&&... args) {
    return T(std::forward<Args>(args)...);
}

struct Point {
    int x;
    int y;
};

Point p = construct_value<Point>(1, 2);

这里有两组信息同时移动：Args... 是类型参数包，args... 是函数参数包。std::forward<Args>(args)... 中的省略号表示对包中每个元素分别生成一个表达式。容器的 emplace_back(args...) 会把这组表达式继续传给 allocator 的构造路径，从而在目标存储上直接构造元素。后续容器章节会把对象生命周期路径展开，本章先固定模板层面的事实：参数包保留了参数个数、类型和值类别信息。

特化表达“某些模板实参需要专门实现”。全特化为一组完整实参提供单独定义；偏特化为一类实参模式提供单独定义。偏特化规则主要用于类模板和变量模板，函数模板没有偏特化机制，函数模板通常用重载、约束或 tag dispatch 表达分支。

template<class T>
struct StoragePolicy {
    static constexpr bool cheap_to_copy = false;
};

template<class T>
struct StoragePolicy<T*> {
    static constexpr bool cheap_to_copy = true;
};

template<>
struct StoragePolicy<int> {
    static constexpr bool cheap_to_copy = true;
};

StoragePolicy<T*> 是偏特化，因为它匹配所有指针类型；StoragePolicy<int> 是全特化，因为它只匹配 int。STL 的 traits 常用这个形式把类型信息转成编译期值，例如 iterator 能力、类型是否可平凡拷贝、allocator 是否应在容器移动时传播。traits 的价值在于把“类型具备什么性质”转成统一字段或别名，让算法和容器按同一接口读取信息。

偏特化的选择在编译期完成。编译器根据模板实参选择最匹配的特化版本，选中后只看该版本提供的成员。这个性质让泛型库可以把分支提前到编译期：一个算法可以对随机访问 iterator 使用距离计算，对前向 iterator 使用循环推进；一个容器可以对平凡可移动元素使用更低成本的批量搬运策略。具体策略受标准语义和实现约束控制，模板机制只提供分发工具。

可变参数、特化和偏特化合在一起，就形成 STL 泛型分支的基本表达力。参数包解决“数量变化”，偏特化解决“类型形状变化”，全特化解决“单个类型或单组实参的独立规则”。读源码时可以先把每个 trait 当成一个小型查询表：主模板给默认答案，偏特化覆盖某类类型，全特化处理具体类型。这样阅读会比直接在多层模板中追展开结果更稳定。

5.4 typename、dependent name 与二阶段查找

依赖名是模板中含义依赖模板参数的名字。dependent name 规则说明，模板定义内部的某些类型和表达式会随实参变化；非依赖名在模板定义点查找和绑定，依赖名延后到模板实参已知时处理。这个规则就是通常说的二阶段查找的核心：第一阶段检查模板定义中已经能确定的内容，第二阶段在实例化时处理依赖部分。

贯穿材料中的 first 函数有一个典型依赖名：Buffer::value_type。在模板定义阶段，编译器只知道 Buffer 是一个模板参数，不知道 Buffer::value_type 到底是类型、静态数据成员，还是别的成员名字。typename 的作用是告诉编译器：这里把这个 qualified dependent name 当作类型使用。

template<class Buffer>
constexpr auto first(Buffer& buffer) -> typename Buffer::value_type& {
    return buffer[0];
}

去掉 typename 后，编译器没有足够信息把 Buffer::value_type 解析成类型。这个要求在 iterator 和 traits 源码里非常高频：typename iterator_traits<It>::value_type、typename allocator_traits<Alloc>::pointer、typename Container::iterator 都是在依赖类型名上显式标注类型语义。

二阶段查找还影响普通函数调用。下面的 call_log 中，log(0) 不依赖 T，所以 log 在模板定义点绑定。后面再声明更匹配的 log(int)，也不会改变 call_log<int> 内部这个非依赖调用的绑定结果。

#include <iostream>

void log_value(double) {
    std::cout << "double\n";
}

template<class T>
void call_log(T) {
    log_value(0);
}

void log_value(int) {
    std::cout << "int\n";
}

log_value(0) 里的名字和参数类型都不依赖 T，所以它在定义点只能看到 log_value(double)。这种行为让模板定义具有稳定含义，也会让读者产生疑惑：某个更近、更匹配的重载在使用点可见，但模板内部调用仍然按定义点规则执行。

依赖调用会延后处理。把实参类型写进表达式后，查找和重载决议会等到实例化阶段才能完成。典型场景是算法内部对 iterator、predicate、comparator 调用操作：*it、++it、pred(value)、comp(left, right) 的合法性依赖具体类型。STL 源码中的错误往往从这些依赖表达式暴露：类型缺少 operator++，解引用结果不满足赋值要求，比较器的参数列表与元素引用不匹配，allocator traits 中缺少可推导的成员。

读依赖名时可以按三个问题判断。第一，名字是否写在模板定义中，并且含有模板参数。第二，当前位置语法是否要求类型名；如果要求，而名字形如 T::x 或 Traits<T>::x，通常需要 typename。第三，表达式的合法性是定义点已经确定，还是等到实例化时才由具体类型决定。这个顺序能把许多模板错误从长报错中剥离出来。

5.5 constexpr、inline 与编译期边界

constexpr 表示某个变量或函数在满足条件时可以用于常量表达式。cppreference 的 constexpr 页面说明，constexpr 声明让实体的值能够在只接受编译期常量的上下文中出现；同时，函数或静态数据成员首次声明为 constexpr 时具有 inline 语义。对模板库来说，constexpr 是编译期能力边界的标记，它决定某些泛型操作能否进入 static_assert、数组边界、非类型模板参数、std::array 长度计算和编译期分支。

贯穿材料中的 size() 是 constexpr，因为它只返回模板参数 N。当对象在常量求值上下文中可用时，调用结果可以参与 static_assert。

constexpr StaticBuffer<int, 3> values{{1, 2, 3}};
static_assert(values.size() == 3);

这个例子的关键点是：constexpr 函数并不强制每一次调用都在编译期求值。它表示该函数在给定实参和函数体满足常量表达式规则时可以被常量求值。普通运行时对象调用 buffer.size() 时，结果也可以作为普通运行时值使用。STL 中大量成员函数从 C++20、C++23 起逐步获得 constexpr 支持，工程含义是更多容器和算法操作可以参与编译期计算；具体可用范围仍受标准版本、元素类型和实现支持影响。

inline 在现代 C++ 中更直接的工程语义是多翻译单元定义规则。inline 规则允许外部链接的 inline 函数或 C++17 inline 变量在多个翻译单元中拥有相同定义，并要求使用处可达。模板定义通常放在头文件中，是因为隐式实例化需要在使用点看到定义；头文件中的非模板函数、非模板变量和变量模板辅助对象则需要按 ODR 与 inline 规则处理。

template<class T>
inline constexpr bool small_object_v = sizeof(T) <= sizeof(void*) * 2;

template<class T>
constexpr bool can_store_inline() noexcept {
    return small_object_v<T> && std::is_nothrow_move_constructible_v<T>;
}

small_object_v<T> 是变量模板。inline constexpr 让它适合放在头文件中，被多个翻译单元包含时仍然指向同一套 ODR 语义。can_store_inline<T> 是函数模板，定义需要在使用点可见以便实例化。读 STL 源码时，头文件中同时出现模板定义、inline 辅助函数、inline constexpr 变量和类型 traits，要分别判断它们承担的是实例化入口、链接规则、编译期常量还是类型查询。

编译期边界还包括 if constexpr。它在 C++17 引入，允许模板根据编译期条件选择分支，未选中分支在语义检查上有特殊规则。下面的例子根据类型性质选择拷贝策略，代码只是教学简化，真实 STL 实现还要考虑对象生命周期、异常安全和 allocator 参与。

template<class T>
T duplicate_value(const T& value) {
    if constexpr (std::is_trivially_copyable_v<T>) {
        return value;
    } else {
        return T(value);
    }
}

这个分支发生在编译期。它和普通 if 的差异是：if constexpr 的条件必须是编译期常量，选中路径由模板实参决定。STL 中类似模式常出现在 traits 分发、范围适配、构造策略选择和异常安全路径选择中。判断这类代码时，先看条件是否由类型 traits、非类型模板参数或 concept 约束给出，再看每个分支分别要求类型满足什么操作。

5.6 模板机制对 STL 泛型设计的支撑

STL 的泛型设计建立在一个稳定分层上：容器暴露类型和 iterator，traits 把类型能力归一化，算法用函数模板接收 iterator 和 predicate，allocator 用模板参数替换内存策略，特化和编译期分支根据类型性质选择实现路径。模板机制给这些层提供的是编译期连接方式。

以 first 为例，函数模板只要求 Buffer 提供 value_type 和下标访问。它不关心 Buffer 是 StaticBuffer、std::array，还是某个用户自定义容器。这个接口形状就是后续 STL 算法的基础：算法通过表达式要求约束输入，通过 traits 或 concepts 查询能力，通过模板实例化把具体类型带进函数体。

template<class Buffer>
constexpr auto first(Buffer& buffer) -> typename Buffer::value_type& {
    return buffer[0];
}

StaticBuffer<int, 4> ints{{1, 2, 3, 4}};
int& head = first(ints);

标准库容器和算法会把这种要求做得更严密。std::sort 需要随机访问 iterator，因为它要做跳跃访问和距离计算；std::list::sort 是成员函数，因为链表 iterator 不提供随机访问能力，但链表可以通过节点重连完成排序。模板让这两类操作共享“泛型写法”，同时保留不同底层结构的能力边界。

traits 是 STL 源码中连接模板和工程判断的中心工具。iterator_traits<It> 把不同 iterator 类型的 value_type、difference_type、iterator_category 等信息统一成一个查询入口；allocator_traits<Alloc> 把 allocator 的可选成员和默认行为统一成容器可调用接口；type_traits 把类型性质转成布尔值或类型别名。这些 traits 大多使用主模板、偏特化、别名和变量模板组织答案。

allocator 也依赖模板参数。std::vector<T, Alloc> 把元素类型和内存策略都写成模板参数。容器实现可以在编译期知道 T 的构造、移动、析构能力，也可以通过 allocator_traits<Alloc> 调用 allocate、deallocate、construct 和 destroy。模板机制不会自动保证资源安全；资源安全来自容器实现对对象生命周期、异常路径和 allocator 协议的正确组织。模板只让这些策略在类型层面被组合。

源码阅读时可以使用一套固定顺序：先找主模板参数列表，确认哪些参数代表元素、iterator、allocator、predicate、policy；再找 traits 查询入口，确认实现读取了哪些能力；接着看特化、重载、if constexpr 或 tag dispatch 如何选择路径；最后回到标准语义，确认该路径承诺的复杂度、异常安全和 iterator 有效性。这个顺序能把 STL 模板代码从“符号很长”还原成“参数、能力、分支、承诺”四个层次。

模板机制的最终工程结论是：STL 在编译期为具体类型生成匹配的代码路径，共同基类和动态派发只在少数显式设计中出现。这样做带来强类型、内联优化和零额外动态派发的机会，也带来长错误信息、头文件实现暴露、编译时间增加和 ABI 边界更敏感等成本。读 STL 时，应把模板当作类型级连接系统来分析：它把接口现象连接到语言规则，把语言规则连接到实现形状，再把实现形状连接到工程后果。

最小自检任务

阅读下面的代码，判断三个位置分别会发生什么：use_same_type 的调用能否通过推导，read_first 的返回类型是否需要改写，tiny_v 适合放在头文件中的原因是什么。

#include <cstddef>
#include <type_traits>

template<class T>
bool use_same_type(T left, T right) {
    return left == right;
}

template<class Buffer>
auto read_first(Buffer& buffer) -> Buffer::value_type& {
    return buffer[0];
}

template<class T>
inline constexpr bool tiny_v = sizeof(T) <= sizeof(void*);

struct IntBuffer {
    using value_type = int;
    int data[2]{};

    int& operator[](std::size_t index) {
        return data[index];
    }
};

int main() {
    bool a = use_same_type(1, 2);
    // bool b = use_same_type(1, 2.0);

    IntBuffer buffer{{1, 2}};
    int& x = read_first(buffer);

    static_assert(tiny_v<int>);
}

答案要点

use_same_type(1, 2) 可以通过，两个实参都推导出 T = int。use_same_type(1, 2.0) 会在模板参数推导阶段失败，因为同一个 T 从两个实参位置得到 int 和 double 两个结果；写成 use_same_type<double>(1, 2.0) 后，T 被显式固定为 double，第一个实参再按普通调用规则转换。

read_first 的返回类型需要写成 typename Buffer::value_type&。Buffer::value_type 是 qualified dependent name，模板定义阶段无法直接确定它表示类型。typename 明确告诉编译器该名字在这里作为类型使用。这个规则对应 iterator traits、allocator traits 和容器嵌套类型读取的常见源码形状。

tiny_v 是变量模板，并且使用 inline constexpr。constexpr 提供编译期常量语义，inline 支撑头文件中多翻译单元可见的定义规则。把它放在头文件中后，不同翻译单元可以使用 tiny_v<int>，同时保持 inline 变量的 ODR 语义。

本章知识点总结

模板定义：模板定义描述实体家族，具体函数或类型来自特化。
实例化点：模板在使用点获得实参，当前上下文要求完整类型或函数体时才实例化相应定义。
成员延迟：类模板成员函数体通常在成员被使用时实例化，因此部分错误会延迟暴露。
参数推导：函数模板推导从形参模式和调用实参匹配模板实参，多个位置的结果必须一致。
非类型参数：非类型模板参数把值写入类型或函数特化，常用于固定大小和编译期策略。
参数包：可变参数模板用参数包保存参数数量、类型和值类别，并通过包展开传递给下一层调用。
特化分支：全特化处理完整实参组合，偏特化处理一类类型形状，选择发生在编译期。
依赖名：依赖模板参数的名字会延后处理，qualified dependent type name 通常需要 typename 标注。
查找阶段：非依赖名在模板定义点绑定，依赖表达式在实例化阶段结合实参继续处理。
constexpr：constexpr 让满足条件的变量和函数可进入常量表达式上下文，具体能力受标准版本和类型条件约束。
inline 边界：inline 的关键工程语义是头文件多翻译单元定义规则，C++17 inline 变量也遵循这条边界。
traits 入口：traits 把类型能力归一化为统一查询接口，算法和容器借此选择实现路径。
STL 判断顺序：读模板源码时先看参数，再看 traits 查询，再看分发方式，最后验证复杂度、异常安全和 iterator 有效性。

5.1 函数模板、类模板与实例化时机​

5.2 模板参数推导与非类型模板参数​

5.3 variadic templates、特化与偏特化​

5.4 typename、dependent name 与二阶段查找​

5.5 constexpr、inline 与编译期边界​

5.6 模板机制对 STL 泛型设计的支撑​

最小自检任务​

答案要点​

本章知识点总结​