一、前言

模板是现代 C++ 的一项强大特性，初衷是为了实现泛型编程。可以编写一次代码，然后使用不同的数据类型，不用为每种类型编写单独的函数或类。

C++ 模板主要分为两种类型：

• 函数模板。
• 类模板 。

这两种类型的模板都很容易理解，运行时编程差异不算大，没有太高深的技巧，这里就不多说了。但是，模板中有一个叫做“模板特化“的东西，对于优化特定类型的代码或处理特殊情况非常有用。

于是，有大佬（西门子的Erwin Unruh）在偶然中发现，结合模板的实例化和特化，模板系统竟然是图灵完备的。也就是说，任何可计算的问题都可以通过模板在编译时进行计算。

什么是模板元编程 (Template Metaprogramming, TMP)？

定义：利用 C++ 模板在编译时执行计算和生成代码。 简单来说，模板元编程是一种独特的编程，不再只是用来创建泛型函数或类，而是将模板本身视为一种图灵完备的“语言”，利用编译器在实例化模板时的行为来执行复杂的算法和逻辑。也就是编写的 TMP 代码不是直接生成运行时指令，而是指示编译器在编译期间生成最终的可执行代码。

和传统运行时编程的区别：

传统意义上的编程关注的是程序在运行时（即程序被加载到内存并执行时）的行为。模板元编程就完全颠覆了这个观念。把计算的“战场”从运行时转移到编译时。所有通过 TMP 实现的逻辑，都在编译器把源代码转换为机器码的过程中就已经确定并固定。只要程序编译完成，这些元编程的计算结果就成为了程序结构的一部分，不用在任何运行时重新计算。

为什么需要模板元编程？

1. 因为所有的计算都在编译时完成，在程序实际运行时，这些计算的结果已经“硬编码”到最终的可执行文件中。程序不再需要为这些逻辑分配 CPU 时间或内存资源，实现了真正的零运行时开销。
2. 将错误从运行时提前到编译时。 传统的运行时错误，只有在程序运行并触发相应代码路径时才会被发现。而模板元编程通过在编译时对类型进行严格的检查和操作，能够将许多潜在的运行时错误“前置”到编译阶段。如果类型或逻辑不符合预期，编译器会立即报告错误，而不是等到程序崩溃。
3. TMP 能够根据不同的类型参数或非类型参数，在编译时生成不同的代码路径或数据结构。

二、核心原理与机制

模板元编程建立在 C++ 模板机制的深厚基础之上。理解其核心原理，特别是模板的实例化、特化、参数类型以及 SFINAE 规则，是掌握 TMP 的关键。

2.1、模板实例化与特化

模板元编程的本质，就是利用编译器在处理模板时所执行的“计算”行为。这个计算过程主要体现在模板的实例化和特化上。

编译器遇到一个模板的使用时，会根据传入的模板实参来生成一个具体的类或函数。这个过程称为实例化。TMP 正是利用这种“按需生成”的机制，让编译器在生成代码的同时，也执行预设的编译时逻辑。

传统编程中的循环（for, while）和条件分支（if, else）在编译时是不能直接使用的。但 TMP 能通过递归的模板实例化和模板特化 来模拟这些控制流结构。

• 递归实例化：通过一个模板定义来调用自身，每次调用都处理问题的一个更小部分，直到达到一个基本情况。
• 模板特化：为特定模板参数提供一个独立的定义。用于定义递归的终止条件（基本情况），或者为某些特殊类型提供不同的行为，有点像运行时编程中的 if-else 分支。

例如：编译时阶乘

// 递归定义：Factorial<N> = N * Factorial<N-1>
template <int N>
struct Factorial {
    static const int value = N * Factorial<N - 1>::value;
};

// 特化（基本情况）：Factorial<0> = 1
template <>
struct Factorial<0> {
    static const int value = 1;
};

// 使用：
int result_5 = Factorial<5>::value; // 编译器会计算出 120
// 编译器在编译时会展开为：
Factorial<5>::value = 5 * Factorial<4>::value
Factorial<4>::value = 4 * Factorial<3>::value
// ...
Factorial<1>::value = 1 * Factorial<0>::value
Factorial<0>::value = 1 (特化终止递归)

好了，现在来了解一下全特化 和 偏特化。

• 全特化：一个模板的所有模板参数都被具体化时，称为全特化。它为特定的一组参数提供了一个完全独立的实现。在 TMP 中，全特化常用来定义递归的基准情况或处理特定类型。
• 偏特化：当一个类模板（注意：函数模板没有偏特化，只有重载）的某些模板参数被具体化，而另一些仍保持泛型时，称为偏特化。它允许为一类参数（而非单个具体参数）提供专门的实现。偏特化在 TMP 中非常有用，可以根据类型之间的关系来选择不同的编译时逻辑，实现更精细的控制。

2.2、模板参数的妙用

模板参数是 TMP 进行编译时计算和类型操作的“变量”。分为三种主要类型：

1. 类型参数：处理类型信息。 这是最常见的模板参数形式，以 typename T 或 class T 定义；模板接受任意类型作为参数。在 TMP 中，类型参数不仅仅是占位符，它们本身就是可以被操作的“数据”。可以通过模式匹配、特化等方式，根据传入的类型参数来决定编译时的行为。比如，判断一个类型是否是 const、是否是引用等。

2. 非类型参数：进行编译时数值计算。 非类型参数允许模板接受编译时常量作为参数，这些参数在编译时是已知的，所以可以直接参与编译时计算。常用于定义固定大小的数组、位掩码、编译时查找表等。

3. 模板的模板参数：以模板作为参数进行操作。 这种参数类型允许一个模板接受另一个模板作为参数。这在需要操作或生成其他模板时非常有用，提供了更高层次的抽象和泛化能力。

2.3、SFINAE机制

SFINAE 是 C++ 模板机制中一个很重要的规则，是许多高级 TMP 技巧的基础。

SFINAE 的全称是 “Substitution Failure Is Not An Error”，直译过来是“替换失败不是一个错误”。核心思想是：编译器在尝试实例化一个函数模板（或类模板的特化）时，如果因为模板参数替换（substitution）导致某个类型或表达式无效，那么这不会立即导致编译错误。相反，编译器会简单的将这个特定的模板（或特化）从重载集中移除，并继续寻找其他可行的重载或特化。只有当所有可能的模板都替换失败，或者没有其他可行的重载时，才会报告编译错误。

SFINAE 机制可以根据类型或表达式的某些特性来有条件的启用或禁用特定的函数重载或类模板特化。

条件性启用/禁用：通过在函数模板的返回类型、参数列表或类模板的非类型参数中使用依赖于模板参数的表达式，可以巧妙利用 SFINAE。如果表达式在替换时失败，则该模板不会被考虑。

std::enable_if 是 C++ 标准库中一个典型的利用 SFINAE 的工具。定义大致如下：

template <bool B, typename T = void>
struct enable_if {}; // 默认模板，当 B 为 false 时，没有 type 成员

template <typename T>
struct enable_if<true, T> { // 偏特化，当 B 为 true 时，有 type 成员
    using type = T;
};

当 B 为 true 时，enable_if<true, T>::type 会得到 T；而当 B 为 false 时，enable_if<false, T>::type 会导致替换失败，因为 enable_if<false, T> 这个模板没有 type 成员。这种替换失败不会导致编译错误，而是使得包含 enable_if 的函数重载被忽略。

示例：使用 enable_if 限制函数只接受整数类型。

#include <type_traits>

template <typename T>
typename std::enable_if<std::is_integral<T>::value, void>::type
print_integral_value(T value) {
   // 只有当 T 是整数类型时，这个函数才会被实例化和调用
   std::cout << "Integral value: " << value << std::endl;
}

int main() 
{
    print_integral_value(10);     // OK，T 是 int，is_integral<int>::value 为 true
    // print_integral_value(3.14); // 编译错误，T 是 double，is_integral<double>::value 为 false，导致替换失败，函数不参与重载决议
    return 0;
}

通过 SFINAE 和 std::enable_if，在编译时根据类型特性实现条件编译，这对于编写高度泛化且类型安全的库代码就很重要。

2.4、类型特征

类型特征是模板元编程中最常用和最强大的工具之一，它们是编译时对类型进行查询和操作的机制。

类型特征的概念：通过模板特化查询类型属性（是否为整数、是否可复制等）。

类型特征是一组类模板，通过特化机制来提供关于特定类型的信息。这些信息以 static const bool value 成员或 using type = ... 成员的形式提供。其实现原理是定义一个通用的模板，然后为特定的类型或类型模式提供特化版本，这些特化版本会设置 value 为 true 或定义 type 成员。

C++ 标准库在 <type_traits> 头文件提供非常多的的预定义类型特征，目的是要简化 TMP 的开发。这些特征涵盖了类型分类、类型属性、类型关系、类型转换等多个方面。

类型分类：

• std::is_void<T>：T 是否为 void。
• std::is_integral<T>：T 是否为整数类型。
• std::is_floating_point<T>：T 是否为浮点类型。
• std::is_array<T>：T 是否为数组类型。
• std::is_pointer<T>：T 是否为指针类型。
• std::is_class<T>：T 是否为类类型。
• std::is_function<T>：T 是否为函数类型。

类型属性：

• std::is_const<T>：T是否 const 限定。
• std::is_volatile<T>：T 是否 volatile 限定。
• std::is_lvalue_reference<T>：T 是否左值引用。
• std::is_rvalue_reference<T>：T 是否右值引用。
• std::is_default_constructible<T>：T 是否可以默认构造。
• std::is_copy_constructible<T>：T 是否可以拷贝构造。
• std::is_move_constructible<T>：T 是否可以移动构造。

类型关系：

• std::is_same<T, U>：T 和 U 是相同类型吗？
• std::is_base_of<Base, Derived>：Base 是否是 Derived 的基类。
• std::is_convertible<From, To>：From 是否可隐式转换为 To。

类型转换/修改：

• std::remove_const<T>::type：移除 T 的 const 限定。
• std::remove_reference<T>::type：移除 T 的引用。
• std::add_pointer<T>::type：将 T 转换为指针类型。
• std::decay<T>::type：将 T 转换为其“衰退”类型（例如，数组衰退为指针，函数衰退为函数指针）。

这些类型特征是构建复杂 TMP 逻辑的基石，能够以声明式的方式在编译时对类型进行细致的分析和操作，从而实现强大的泛型编程和编译时检查。

三、模板元编程的优势

模板元编程最引人注目的优势之一，就是能把计算任务从运行时转移到编译时，实现真正的零运行时开销。

1. 传统程序不管是简单的算术运算还是复杂的算法逻辑，都要在程序运行时消耗 CPU 周期和内存资源。而通过模板元编程实现的计算，都在程序编译成可执行文件之前就已经完成。所以，程序真正运行起来时，这些计算的结果已经固定在二进制代码里，不用再次计算。这种“预计算”的特性能最大限度的减少程序的运行时负担。
2. 编译器在编译时就掌握了通过 TMP 获得的精确信息，能够进行更激进、更有效的优化。
   • 常量传播：编译时计算出的常量直接替换到代码中，消除变量查找和计算的开销。
   • 死代码消除：如果某个代码分支在编译时根据 TMP 逻辑被确定为永远不会执行，编译器就可以直接将其移除，减小最终可执行文件的大小并提高运行时效率。
   • 消除虚函数调用：在基于策略的模板元编程中，通过将算法策略作为模板参数传入，编译器可以在编译时确定具体调用的函数，避免运行时的虚函数表查找开销，实现了静态多态，性能优于基于虚函数的动态多态。
3. 以往的编程中，许多类型不匹配、逻辑约束不满足等问题，只有在程序运行并触发相应代码路径时才会暴露，导致运行时崩溃或产生难以追踪的 Bug。模板元编程通过强大的编译时类型检查机制，能够在程序编译阶段就捕获这些问题。
4. TMP 在编译时对模板参数有严格的约束。

模板元编程超越了简单的泛型，可以在编译时根据不同的输入参数（类型或非类型）生成高度定制化的代码。

TMP 是实现很多高级泛型编程范式的核心工具，例如：

• 策略模式：通过模板参数传入不同的策略类，可以在编译时组合出具有不同行为的组件，而不用虚函数或函数指针。
• 奇异递归模板模式：基类是一个模板，以派生类作为模板参数。让基类在编译时访问派生类的成员，实现静态多态和一些编译时优化，避免运行时开销。
• 类型列表和元组：TMP 可以用来创建和操作编译时类型集合。通过类型列表，可以实现编译时的异构容器、类型映射、编译时反射等功能。

TMP 允许程序在编译时“自我构造”和“自我定制”。可以编写元函数，在编译时根据输入参数生成新的类型、新的函数或新的数据结构。让 C++ 能够实现“嵌入式”的领域特定语言（DSL）。

• 在科学计算库，表达式模板 可以把复杂的数学表达式在编译时进行优化和重组，生成高效的循环代码，避免创建大量的临时对象。
• 通过 TMP，可以编写通用的序列化框架，根据类的成员类型自动生成序列化和反序列化代码。
• 编译时状态机：可以定义一个状态机，状态转换逻辑完全在编译时确定，能避免运行时的状态查找和分支判断开销。

四、模板元编程的局限

尽管模板元编程（TMP）提供了强大的编译时能力和性能优势，但它并不是没有缺点。

模板元编程的思维范式与传统的运行时编程大相径庭，学习的难度比较大。

TMP 的本质是将编译器的模板实例化过程视为一种计算。所以要以一种非常规的方式思考问题：

• 递归替代循环：在 TMP 中，没有 for 或 while 循环，所有的重复逻辑都必须通过递归的模板实例化来实现。
• 特化替代条件分支：if-else 语句被模板特化所取代，根据不同的模板参数选择不同的实现路径。
• 类型作为数据：类型本身成为可以操作的“数据”，而编译时常量则充当“变量”。

这种范式转换对于习惯了命令式编程的人来说，需要投入大量时间去适应和理解。

TMP 代码高度抽象，大量使用模板参数、特化、类型特征和 SFINAE 等高级 C++ 特性。所以 TMP 代码的可读性较差，理解其意图和逻辑要比较深入的 C++ 模板知识。就算是经验丰富的 C++ 开发者，面对复杂的 TMP 代码也非常棘手。

将计算任务从运行时转移到编译时，虽然带来了性能上的优势，但也伴随着编译时间和资源消耗的增加。

1. 模板元编程的“计算”发生在编译阶段。每次模板实例化都会消耗编译器的 CPU 和内存资源。当 TMP 逻辑复杂、递归深度大或涉及大量类型操作时，编译器需要执行大量的实例化和类型推导工作，这会导致编译时间显著延长。对于大型项目，即使是微小的 TMP 改动也会导致数分钟甚至数小时的编译等待，严重影响开发效率。
2. 在编译过程中，编译器需要为每个模板实例化维护大量的元数据和符号表信息。复杂的 TMP 代码可能导致编译器占用巨大的内存，甚至超出系统可用内存，从而导致编译失败（“OOM”错误）。这在处理大型模板库或进行深度递归的元编程时尤为常见。

错误信息的可读性差 是 TMP 最令人诟病的问题之一，也是许多开发者对 TMP 望而却步的主要原因。

1. TMP 代码中出现错误时，编译器生成的错误信息真的是灾难性的。由于 SFINAE 机制的工作原理，一个简单的类型不匹配或逻辑错误可能导致一系列的替换失败，编译器会打印出所有失败的实例化路径，形成数千行甚至数万行的错误报告。
2. 由于错误信息的高度复杂性，很难快速准确地判断是哪一行代码、哪个模板特化或哪个类型推导出了问题。

TMP 的计算发生在编译时，运行时调试工具无法直接进行调试。

1. GDB、Visual Studio Debugger 等运行时调试器只能在程序执行时检查变量状态、设置断点和单步执行。而 TMP 的“执行”是在编译阶段完成的，无法像调试普通代码那样，在 TMP 逻辑中设置断点、查看中间变量的值或跟踪执行路径。
2. 为了调试 TMP，会有一些取巧的方法（但是，这些方法都远远不如运行时调试器直观和高效）：
   • 使用 static_assert 在编译时检查条件，如果条件不满足则导致编译错误，并输出自定义的错误信息。
   • 通过一些技巧来“打印”编译时的类型信息。
   • 把复杂的 TMP 代码拆分成更小的部分，逐一测试以定位问题。
3. 虽然现代 IDE 对 C++ 模板的支持有所改进，但对于复杂的 TMP 结构，它们的智能感知、代码补全和重构功能表现还不是很好。静态分析工具也很难理解 TMP 的复杂逻辑，导致误报或漏报。

TMP 功能确实强大，这不得不承认，但不是所有问题都适合用 TMP 解决。

1. TMP 只能处理编译时可确定的信息和逻辑。无法执行任何运行时行为。
2. 如果程序的行为需要在运行时根据外部输入或不可预测的条件动态改变，那么 TMP 就不适用。TMP 适用在编译时就能完全确定其行为和结构的问题。
3. TMP 是很强大的，但也不能滥用。对于一些简单的问题，如果强行使用 TMP 解决，会导致过度设计，代码变得不必要地复杂和难以理解。

五、模板元编程的典型应用场景

TMP 是 C++ 泛型编程的核心，也是许多 C++ 标准库和著名第三方库得以实现的基础。

C++ 标准模板库（STL）是 TMP 最常见的应用实例。std::vector、std::map、std::sort 等容器和算法都通过模板实现，能够操作任意类型的数据。

• 类型无关性，不用为每种类型单独编写代码。
• 算法泛化。
• 类型特征 在编译时提供关于类型的信息，使 STL 能够进行编译时类型检查和优化。

著名的 C++ 第三方库 Boost 库，也大量使用 TMP 来提供高级的泛型编程能力：

• Boost.MPL：提供了一套用来编译时序列、算法和元函数的工具集，在编译时进行复杂的类型操作和逻辑计算。
• Boost.Fusion / Boost.Hana：这些库利用 TMP 实现异构容器和编译时反射（有限），对不同类型集合的操作变得更加方便和高效。
• Boost.Spirit：一个用于解析器的库，其核心就是通过 TMP 在编译时构建解析器语法树，实现高效的文本解析。

在对性能有极高要求的应用中，TMP 能够把计算从运行时转移到编译时，消除运行时开销。

1. 在科学计算、线性代数库中，表达式模板是优化数学表达式的关键技术。可以把复杂的数学表达式在编译时表示为一种数据结构，然后编译器可以分析并生成高度优化的代码，避免创建大量的临时对象，并进行循环融合等优化。用户可以写出接近数学公式的自然语法，同时获得接近手写汇编的性能。
2. 通过把算法或类的行为策略作为模板参数传入，在编译时选择具体的实现，避免虚函数带来的运行时开销，实现静态多态。
3. 奇异递归模板模式 在编译时访问派生类的成员，从而实现：
   • 静态多态：在基类中定义通用接口，通过 static_cast<Derived*>(this) 调用派生类的具体实现，避免虚函数表查找。
   • 编译时接口检查：在基类中强制派生类实现某些方法。
   • 混入：为多个类注入通用功能。

TMP 让 C++ 能够进行编译时代码生成，甚至在 C++ 内部嵌入领域特定语言。

1. 通过 TMP，可以编写通用的序列化框架，在编译时分析类的成员类型和结构，自动生成用于将对象序列化到文件或网络、以及从文件或网络反序列化回对象的代码。
2. 对于状态转换逻辑在编译时就确定的状态机，可以使用 TMP 来实现。每个状态和转换都可以由类型表示，状态机的行为完全在编译时确定，从而消除了运行时的状态查找和条件判断开销，适用于高性能的协议解析或控制逻辑。
3. TMP 可以在 C++ 中创建一种“嵌入式”的领域特定语言，使得某些特定领域的问题可以用更自然、更接近该领域表达方式的 C++ 语法来描述，而底层的复杂性则通过 TMP 在编译时解决。

将错误从运行时提前到编译时。

1. static_assert 可以在编译时检查条件。如果条件不满足，编译器会报错并显示自定义的错误信息。这对于强制执行设计约束、验证模板参数的合法性以及在早期发现潜在问题非常有用。

2. 结合类型特征和 SFINAE，可以实现非常精细的编译时类型检查和函数重载选择。

六、模板元编程与运行时编程的对比

模板元编程（TMP）和传统的运行时编程代表了两种截然不同的编程范式。

核心差异：

特性	模板元编程 (TMP)	运行时编程
执行阶段	编译时：所有计算和代码生成都在编译阶段完成。	运行时：程序编译后，在执行时进行计算和操作。
计算模型	基于类型操作、模板实例化、递归和特化。将编译器视为一种“解释器”。	基于指令序列、变量操作、函数调用和控制流（循环、条件分支）。
数据表示	类型本身、编译时常量、类型特征。数据是“静态”的。	变量、对象、动态内存。数据是“动态”的。
错误发现	编译时错误：如果元程序逻辑有误，编译器会报错。错误冗长且难以理解。	运行时错误：逻辑错误、内存访问错误等在程序执行时才会显现，可能导致崩溃。
调试	极度困难，无法使用传统调试器。依赖 static_assert 和类型打印技巧。	相对容易，可使用 GDB、Visual Studio Debugger 等工具进行单步调试、查看变量。
性能	零运行时开销：所有计算在编译时完成，运行时无需额外计算。	存在运行时开销：函数调用、虚函数表查找、条件分支、循环等。
灵活性	只能处理编译时确定的逻辑，无法响应运行时动态变化。	能灵活处理动态输入、I/O、网络通信、动态内存分配等。
代码可读性	普遍较差，高度抽象，需要深入的 C++ 模板知识。	相对直观，符合人类思维习惯，易于理解和维护。
编译时间	显著增加，尤其是复杂元程序。	相对较快，除非代码量巨大。

模板元编程的优势：

1. 极致性能优化：把计算从运行时转移到编译时，消除运行时开销，生成高度优化的代码。
2. 编译时代码生成：减少手动编写重复代码的工作量，提高开发效率和代码一致性。
3. 强类型安全与编译时错误检测：在编译阶段捕获更多错误。
4. 强大的泛型编程能力：实现高度通用和可复用的组件。

模板元编程的劣势：

1. 非直观的编程范式，代码很难理解和维护。
2. 复杂的元程序导致编译时间显著延长，甚至内存溢出。
3. 编译器错误报告冗长且很难定位问题根源。
4. 不能使用传统调试器，依赖间接的编译时断言和类型打印技巧。
5. 不能进行 I/O、动态内存分配等运行时操作。

运行时编程的优势：

1. 更符合传统的命令式编程思维，易于上手。
2. 编译速度快，有成熟的调试工具支持。
3. 能够轻松应对运行时变化的需求。
4. 代码结构清晰，适合团队协作和长期维护。
5. 绝大多数的 C++ 库和框架都基于运行时编程。

运行时编程的劣势：

1. 函数调用、虚函数、条件分支、循环等都会带来一定的性能损耗。
2. 错误通常在运行时发现。
3. 虽然有模板，但对于类型本身的复杂操作不如 TMP 强大，有时需要运行时多态或类型擦除。

选择 TMP 应该基于明确的需求和权衡，而不是盲目追逐技术潮流。TMP 的理想应用场景：

1. 对性能有极致要求：应用程序的性能瓶颈在于运行时计算，且这些计算可以在编译时确定时，TMP 是消除开销的有效手段。
2. 想在程序运行前尽可能多地捕获错误。
3. 进行编译时代码生成 。
4. 实现高度泛化的库或组件。
5. 程序的行为和结构在编译时是固定的，不用运行时动态调整。

对于大多数日常的软件开发任务，运行时编程仍然是首选，因为能提供更好的开发效率、可读性和维护性。

1. 大多数通用应用开发：包括业务逻辑、用户界面、服务器端应用等，这些应用不追求极致的性能，更注重开发速度和可维护性。
2. 需要处理动态数据和运行时行为：涉及用户输入、文件 I/O、网络通信、动态内存分配、随机数生成等。
3. 程序行为需要在运行时根据外部条件灵活改变。
4. 如果运行时开销对整体性能影响不大，或可以通过其他手段优化，就不用引入 TMP 的复杂性了。

TMP 和运行时编程可以相补，发挥各自的优势。

• 用 TMP 定义编译时策略，然后在运行时代码中根据这些策略进行具体操作。
• 虽然现在 C++ 还没有原生的运行时反射，但可以通过 TMP 在编译时生成关于类型结构、成员信息等的元数据，然后在运行时通过这些元数据实现类似反射的功能。
• 用 TMP 自动生成框架代码、数据结构或协议解析器，然后由运行时代码填充具体的业务逻辑和动态行为。

七、结语

模板元编程推动了泛型编程的边界，并为性能优化和代码生成提供了独特的解决方案。随着 C++ 语言自身的发展，尤其是 Concepts 的标准化以及未来 C++26 出现的编译时反射等特性，TMP 的使用方式和复杂性会有所好转。一部分复杂的 TMP 技巧会被更高级、更易用的语言特性所取代，但核心思想——在编译时进行计算和代码生成——还是非常重要的，驱动着C++语言向更高性能、更强类型安全和更高抽象层次迈进。