6、编译期循环：递归模板实现编译期循环、循环展开技术
说到编译期循环，我得先坦白一件事——C++模板元编程里其实没有真正的「循环」。你可能会问，那怎么实现重复操作？嗯，答案就是递归。说白了，我们用递归来模拟循环，让编译器在编译阶段替我们把活干了。
6.1 为什么需要编译期循环？
运行时循环大家都熟悉：for、while，跑起来一遍遍执行。但有些场景，你希望循环在编译期就完成。比如：
- 计算一个数的阶乘，值在编译期就确定
- 生成固定长度的数组，每个元素都经过计算
- 展开循环，减少运行时分支开销
我在项目中遇到过这样一个场景：一个嵌入式设备上跑信号处理算法，循环次数固定为8次。用运行时循环，每次都要检查循环变量、跳转，性能始终上不去。后来改成编译期展开，速度直接提升了30%。
6.2 递归模板：最朴素的编译期循环
先看一个经典例子——编译期阶乘：
template <unsigned int N>
struct Factorial {
static constexpr unsigned int value = N * Factorial<N - 1>::value;
};
template <>
struct Factorial<0> {
static constexpr unsigned int value = 1;
};
// 使用
constexpr auto result = Factorial<5>::value; // 120这个模式你一看就懂了：Factorial<5> 依赖 Factorial<4>，一路递归到 Factorial<0> 这个特化版本终止。编译器在实例化模板时，就把整个计算链展开了。
核心要点：递归模板的终止条件必须用模板特化来实现。没有特化，编译器会无限递归下去，最终报错。
6.3 编译期循环的通用模式
我习惯把编译期循环抽象成三个部分：
- 循环体——每次迭代要执行的操作
- 循环变量——当前迭代的索引
- 终止条件——什么时候停止递归
来看一个更通用的例子——编译期求和：
template <unsigned int N, unsigned int Current = 0>
struct Sum {
static constexpr unsigned int value =
Current + Sum<N, Current + 1>::value;
};
// 终止特化：当 Current 等于 N 时
template <unsigned int N>
struct Sum<N, N> {
static constexpr unsigned int value = N;
};
// 使用：计算 0+1+2+3+4+5
constexpr auto sum = Sum<5>::value; // 15你想想看，这个模式是不是很像 for (int i = 0; i <= N; ++i)？只不过循环变量 Current 变成了模板参数，每次递归都「递增」一次。
小技巧：如果你觉得模板参数太多写起来麻烦，可以用 std::integer_sequence 配合 constexpr 函数来简化。C++17 之后，很多编译期循环可以用 constexpr 函数直接写，更直观。
6.4 循环展开技术
循环展开，说白了就是把循环体复制多份，减少循环控制开销。运行时展开靠编译器优化，编译期展开则是我们手动控制。
我曾经在写一个矩阵乘法库时，发现小矩阵（4x4）的乘法用循环展开后，性能提升了将近一倍。为什么？因为循环展开后，编译器能更好地做指令流水线调度和寄存器分配。
来看一个编译期循环展开的例子——对数组每个元素加1：
template <typename T, size_t N, size_t Index = 0>
struct ArrayIncrement {
static void apply(T* arr) {
arr[Index] += 1;
ArrayIncrement<T, N, Index + 1>::apply(arr);
}
};
// 终止特化
template <typename T, size_t N>
struct ArrayIncrement<T, N, N> {
static void apply(T*) {} // 什么也不做
};
// 使用
int data[4] = {1, 2, 3, 4};
ArrayIncrement<int, 4>::apply(data);
// data 变为 {2, 3, 4, 5}编译器实例化后，apply 函数会展开成：
data[0] += 1;
data[1] += 1;
data[2] += 1;
data[3] += 1;没有循环变量，没有跳转，没有分支预测失败的风险。这就是编译期循环展开的魅力。
注意：循环展开不是万能的。展开太多会导致代码膨胀，指令缓存命中率下降。我建议展开次数控制在 4-8 次之间，具体要看目标平台的指令缓存大小。
6.5 编译期循环 vs 运行时循环
| 对比维度 | 编译期循环（递归模板） | 运行时循环 |
|---|---|---|
| 执行时机 | 编译期 | 运行期 |
| 循环次数 | 必须编译期常量 | 可以是变量 |
| 性能 | 零运行时开销 | 有循环控制开销 |
| 代码体积 | 可能膨胀 | 紧凑 |
| 灵活性 | 低（次数固定） | 高 |
说白了，编译期循环适合那些「次数固定、追求极致性能」的场景。如果你的循环次数在运行期才能确定，那还是老老实实用运行时循环吧。
6.6 实战：编译期生成斐波那契数列
最后，我带你写一个稍微复杂点的例子——编译期生成斐波那契数列数组：
template <size_t N>
struct Fibonacci {
static constexpr size_t value =
Fibonacci<N - 1>::value + Fibonacci<N - 2>::value;
};
template <>
struct Fibonacci<0> {
static constexpr size_t value = 0;
};
template <>
struct Fibonacci<1> {
static constexpr size_t value = 1;
};
// 生成数组的辅助模板
template <size_t... Indices>
constexpr auto make_fib_array(std::index_sequence<Indices...>) {
return std::array<size_t, sizeof...(Indices)>{
Fibonacci<Indices>::value...
};
}
template <size_t N>
constexpr auto fibonacci_array() {
return make_fib_array(std::make_index_sequence<N>{});
}
// 使用
constexpr auto fibs = fibonacci_array<10>();
// fibs = {0, 1, 1, 2, 3, 5, 8, 13, 21, 34}这个例子把递归模板、参数包展开、std::index_sequence 都用上了。编译期就把斐波那契数列算好，运行时直接读取数组，没有任何计算开销。
避坑指南：我曾经在项目中用递归模板计算一个较大的编译期序列，结果编译时间从几秒飙到了几分钟。原因是递归深度太大，编译器实例化了大量模板。后来我改用 constexpr 函数配合循环，编译时间降到了正常水平。所以，递归深度超过几百的编译期计算，建议用 constexpr 函数替代。
6.7 知识体系总览
下面这张图帮你理清本章的核心逻辑：
嗯，编译期循环这块内容就这些。记住一个原则：能用 constexpr 函数解决的问题，尽量别用递归模板。但当你需要极致的编译期控制，或者要操作类型而非值时，递归模板依然是不可替代的工具。