一. 前言

在前面我们写过不少关于 STL 容器的内容，比如 vector, list, stack 等。
如果你看过它们的源码，会发现一个共同点——几乎所有的 STL 容器都是通过模板（template） 实现的。

模板是 C++ 泛型编程的核心，它让代码能在不损失效率的前提下复用逻辑。
本篇就来带你进阶了解模板中更进阶的部分：非类型模板参数、模板特化以及模板分离编译。
这些语法表面抽象，其实是理解 STL 背后设计思想的关键。

二. 非类型模板参数

模板参数不仅可以是类型,也可以是常量值,这类类型叫做非类型模板参数

---

1.1 什么是非类型模板参数

非类型模板参数指的是

不是一个类型,而是编译期就可以确定的常量值

template<class T, size_t N = 5> 
class Array
{
private:
    T _data[N];
}

• T是类型参数
• N是非类型模板参数

使用时

Array<int, 10> a1;
Array<double, 20> a2;

不同的N,会生成完全不同的模板实例

1.2 非类型模板参数的特点

非类型模板参数的几个重要的特性

---

1. 必须是编译器常量

合法的:

Array<int, 10> a1;
Array<int, sizeof(double)> a2;

下面这种是不允许的:

int n = 10;
Array<int, n> a; // 编译报错

模板在编译期间完成实例化，而变量 n 的具体值要到程序运行时才能确定，因此在编译器试图确定n的数值时，它实际上无法获取n的具体值 

---

2. 常用于表达"规模", "大小", "策略"

在 STL 或模拟实现中，非类型模板参数经常用来表达：

• 固定大小（数组长度）

• 策略选择（如是否启用某种行为）

• 编译期配置

例如一个简单的固定容量容器

template<class T, size_t Capacity>
class Array
{
private:
    T _data[Capacity];
    size_t _size;
}

这里的 Capacity 在编译期就决定了容器能存多少元素

---

3. 非类型模板参数 vs 普通构造参数

这里可能会产生一个疑问:

既然容量可以写成构造函数参数，为什么还要用模板参数？

对比一下两种写法:

构造函数参数(运行期决定)

class Array
{
public:
    Array(size_t n = 10) : _capacity(n) {}

private:
    size_t _capacity;
}

非类型模板参数(编译器决定)

template<size_t N>
class Array
{
private:
    size_t _data[N];
}

本质区别:

对比	构造参数	非类型模板参数
决定时间	运行期	编译期
类型是否不同	类型相同	类型不同
是否参与类型系统	否	是
是否可用于数组长度	否	是

// 非类型模板参数
Array<int, 10> a1;
Array<int, 20> a2; // 这里a1, a2是不同类型

// 构造函数参数
Array<int> b1(10);
Array<int> b2(20); // 这里b1, b2是相同类型

非类型模板参数会影响类型本身，这是它最核心的价值。

---

1.3 小结

非类型模板参数是编译期常量参数

• 它参与类型系统，不同参数 = 不同类型

• 常用于表达容量、规模、策略等编译期信息

• STL 中的 std::array 是最经典的例子

三. 模板特化（Template Specialization）

在前面我们已经知道, 模板的本质是:

让编译器根据不同的模板参数, 生成不同的代码

但有些时候，我们并不希望所有类型都按同一套规则来生成代码，而是希望对某些特殊类型，使用特殊实现
这正是 模板特化 存在的意义

---

2.1 为什么需要模板特化

先看一个典型例子:比较大小

template<class T>
bool Less(const T& x, const T& y) const { return x < y; }

对于内置类型来说这种实现完全没问题

Less(1, 2);
Less(1.1, 2.2);

但如果是指针类型呢

int a = 10, b = 20;
Less(&a, &b);

此时比较的其实就是地址大小, 而不是我们期望的值大小

对于指针类型, 我们显然需要一套不同的实现方式

这时候就需要模板特化

---

2.2 模板特化的基本思想

模板特化的核心思想只有一句话

为某些特殊参数, 单独提供一份实现

模板特化主要分两类:

• 全特化（Full Specialization）
• 偏特化（Partial Specialization）

我们一个一个来看

---

2.3 全特化（Full Specialization）

全特化指的是:

对模板的所有参数都给出具体类型，从而完全替换通用模板的实现

先看一个普通模板:

template<class T>
struct Less
{
    bool operator(const T& x, const T& y) const { return x < y; }
}

我们现在对 char* 进行全特化

template<>
struct Less<char*>
{
    bool operator(const chat* x, const char* y) const 
    { return strcmp(x, y) < 0; }
}

此时

• Less<int> 使用通用模板
• Less<char*> 使用特化版本

Less<int>()(10, 20);
Less<char*>()("abc", "def")

特化的匹配规则

编译器在实例化模板时:

• 优先匹配特化版本

• 如果找不到合适的特化，才使用通用模板

特化不是重载, 而是更具体的模板匹配机制

---

2.4 偏特化（Partial Specialization）

注意：函数模板不支持偏特化

偏特化只支持类模板，不支持函数模板

---

偏特化指的是:

只对模板参数中的一部分特征进行限定，而不是完全指定所有参数。

举一个最经典的例子：指针类型偏特化

template<class T>
struct Pointer { static bool isPointer = false; }

针对所有指针类型进行偏特化：

template<class T>
struct Pointer<T*> { static bool isPointer = true; }

使用时：

Pointer<int>::isPointer;  // false
Pointer<int*>::isPointer; // true
Pointer<double*>::isPointer // true

这里的 T* 并不是某个具体类型，而是一类类型模式，这正是 “偏” 的含义

---

2.5 小结

• 模板特化用于为特殊类型提供特殊实现

• 全特化：参数全部具体化

• 偏特化：只限定一部分特征（仅类模板支持）

四. 模板分离编译

在学习 C++ 模板中, 我们经常会遇到一个问题: 

为什么普通函数, 普通类都可以在 .h / .cpp 文件中分离编译, 可是模板却只能写在头文件里

如果我们尝试把模板实现写在 .cpp 中, 链接阶段就会直接报错, 这一节我们来系统研究这个问题

---

3.2 什么是分离编译

先简单回顾一下普通程序的分离编译流程:

// test.h
void func();

// test.cpp
#include "test.h"
void func() {}

// main.cpp
#include "test.h"
int main()
{
    func();
}

大致编译流程:

• 每个 .cpp 单独编译, 生成目标文件 .o 
• 链接阶段把所有目标文件合并
• 链接器根据符号表找到 func() 的实现

普通函数在编译阶段就已经确定了具体的函数实体

---

3.2 模板和普通代码的根本区别

模板最大的区别在于一句话

模板不是具体代码, 而是生成代码的规则

template<class T>
void func(T x)
{}

在这一步, 编译器不会立即生成机器码, 只有当我们使用时:

func<int>(20);

编译器才会根据模板定义, 生成一个 func<int>(20) 的函数具体实例

模板实例化发生在使用模板的位置

---

3.3 模板分离编译为什么会失败

先来看一个错误示范:

// add.h
template<class T>
T add(T x, T y);

// add.cpp
#include "add.h"
template<class T>
T add(T x, T y) { return x + y; }

// main.cpp
#include "add.h"
int main()
{
    int x = add(10, 20);
}

看似和普通函数一样, 实际上会链接失败

---

编译阶段到底发生了什么

1. 第一步：编译 add.cpp

编译器看到

template<class T>
void add(T x, T y) { return x + y; }

可是并没有看到任何具体使用,例如

add<int>(10, 20);

所以他不会生成任何函数代码, 只会生成模板蓝图信息, 当编译完成生成可链接文件 add.o 的时候, 里面并没有 add<int>(10, 20) 的符号

---

2. 第二步：编译 main.cpp

当编译器看到

int x = add(10, 20);

编译器知道是

add<int>

但是, 此时编译器只在 add.h 中看到

template<class T>
T add(T x, T y);

由于未找到 add 函数的具体定义, 编译器无法实例化

此时他会假设外部单元会提供定义, 并生成一个 add<int> 的外部符号引用, 进而形成 add.o 文件

---

3. 第三步：链接阶段

此时链接器开始合并 main.o 和 add.o

main.o 此时说 : "我需要 add<int>"

但是 add.o 却说 : " 我没有生成 add<int> "

于是链接器说 :

undefined reference to add<int>

链接失败!!

---

本质问题

关键点在于

模板不是函数, 而是代码生成规则

编译器需要完整看到模板定义并结合具体类型使用才能生成实际函数。当模板定义位于 add.cpp 文件而使用代码在 main.cpp 文件时，由于两者分属不同翻译单元，编译器无法进行模板实例化。

---

3.4 普通函数为什么可以分离编译

举个例子:

add.cpp

int add(int x, int y) 
{ 
    return x + y; 
}

在编译 add.cpp 时，由于参数类型已经明确且函数签名固定，编译器能够直接生成对应的机器码。因此，add.o 目标文件中确实包含了该符号的定义

add(int, int)

main.cpp

int add(int, int);

int main()
{
    int x = add(10, 20);
    return 0;
}

在编译 main.cpp 时, 编译器会生成对 add 函数的外部引用, 随后链接器会去 add.cpp 里找对应的符号, 因为 add.cpp 中真的有那段机器码

所以可以分离编译

如果是模板函数:

add.cpp

template<class T>
T add(T x, T y) 
{
    return x + y;
}

在编译 add.cpp 时, 由于没有任何具体类型, 编译器不知道要生成 add<int> 还是 add<double>的实例化版本，因此只会保留模板定义信息。

普通函数	模板函数
函数实体	代码生成规则
编译时直接生成机器码	使用时才生成机器码
可以单独存在	必须结合具体类型
编译阶段就完整	实例化阶段才完整

---

从编译器角度看

普通函数:

源代码 -> 生成函数实体 -> 生成机器码 -> 写入目标文件

模板函数:

源代码 -> 保存模板规则 -> 等待具体类型实例化 (例如 add<int>) -> 替换 T 为 int -> 生成函数实体  -> 生成机器码

---

为什么 C++ 要这么设计

因为模板是

编译器泛型系统

如果模板像普通函数一样工作, 就需要在编译时生成所有可能类型, 但是类型组合可能是无限的

比如:

add<int>
add<long>
add<double>
add<std::string>
add<MyClass>
add<vector<int>>

编译器根本不知道要生成哪些, 所以他必须要看到具体使用才能生成

---

3.5 为什么写在头文件就能工作

每个翻译单元在遇到模板定义时，都会生成相应的实例化版本。每个目标文件(.o)都会包含自己的实例副本，最终由链接器根据单定义规则(ODR)进行合并处理。

---

3.6 模板分离编译的特殊写法(了解即可)

理论上, 模板是可以分离编译的, 但是条件非常苛刻

// func.cpp
template void func<int>(int);

这种写法叫做显示实例化, 意思是

明确告诉编译器, 我要生成 func<int>

然而，这种方法缺乏灵活性且可维护性极差，因此很少在通用库中使用。

STL 这种泛型库，根本无法预知用户会用哪些类型

---

3.7 为什么 STL 全部是头文件

现在我们可以总结出答案了

由于STL广泛采用模板，而模板实例化必须在代码使用处完成，这就要求使用点能够获取完整的模板定义。因此，STL只能以头文件库的形式存在。

我们经常写的

#include <string>
#include <vector>
#include <map>

实际上引入的都是模板定义本身

---

3.8 一句话总结

模板不是函数，不会提前生成代码；
模板的实例化发生在使用处，因此定义必须对使用者可见。

五. 模板在 STL 中的整体设计思想总结

通过前面几节对非类型模板参数、模板特化以及模板分离编译的介绍，我们已经能够从语法层面理解模板是如何工作的
但如果站在 STL 的视角来看，模板真正重要的并不是语法本身，而是它背后所体现的设计思想

---

4.1 用模板实现泛型而不牺牲效率

STL 的核心目标是

写一次算法和数据结构, 让他适用于任意类型, 同时保持接近手写代码的效率

模板完美契合这一特性：类型在编译期确定，实例化后生成完全具体的代码，无需依赖运行时多态，也不产生虚函数开销。

这也是为什么 STL 更倾向于模板, 而不是基于继承的多态设计

---

4.2 用偏特化解决特殊类型问题

STL 采用差异化处理策略：对通用类型采用统一实现方案，同时针对特殊类型（如指针）提供定制化优化。

这正是模板偏特化的典型应用场景。

例如，STL 通过偏特化技术对原生指针（作为迭代器）、字符串及 POD 类型进行特殊处理，实现了

接口统一，内部实现按类型分流

---

代码实例: std::copy 的优化

标准库 copy 中有类似逻辑 (简化版)

template<class InputIt, class OutputIt>
OutputIt copy(InputIt start, InputIt last, OutputIt result)
{
    for(; start != last; ++start, ++result)
        *result = *start;
}

这是通用实现, 但如果是 int* 拷贝到 int*, 我们就可以直接采用效率更高的做法

memcpy(result, start, n * sizeof(int));

所以 STL 会做类型检测

if constexpr (is_trivially_copyable<T>::value)
    use_memcpy();
else
    use_loop_copy();

接口仍然是 std::copy, 但是内部根据类型选择不同实现

---

4.3 用适配器 + 模板组合限制使用方式

在 stack, queue, priority_queue 等容器适配器中，STL 并没有重新发明数据结构，而是：

• 复用已有容器（如 deque, vector）

• 通过模板参数指定底层容器

• 通过接口封装，限制访问方式

比如 stack

template<class T, class Container = std::deque<T>>
class stack 
{
private:
    Container _con;
}

stack 本身不存数据, 真正存数据的是底层容器, 无论底层是 vector 或 deque, stac 都只暴露这些接口

st.push(10);
st.pop();
st.top();

而不会提供

st.begin();
st[0];

即便底层容器支持遍历, 随机访问, stack 也刻意屏蔽这些能力，从接口层面强制只能后进先出。这体现的是一种非常重要的思想：

模板不仅用于“扩展能力”，也用于“约束能力”。

---

4.4 头文件实现并非缺点

STL 全部采用头文件实现，并不是历史包袱，而是模板机制下的必然选择：模板实例化必须在代码使用处完成，而使用点必须能够访问完整定义，且由于泛型库无法预先知道用户的具体类型，这种实现方式是必然选择。

因此 STL 天生就是一个 header-only library。