C++模板元编程1

第1章概述

你可以将这一章看成是本书后续内容的热身。在本章中，你将有机会小试牛刀，试一试手头的编译器，大致检阅一些基本概念和术语。至本章结束，你至少应该对本书所要讲述的内容有大致的印象，并且（我们希望）届时你将会渴望学习更多的知识。

1.1 起步走

关于模板元程序（template metaprogram）的一个美妙之处在于，它们与传统的优秀系统一样具有一个共同的特性，即：一旦一个元程序（metaprogram）写好了，只要它能够工作，你就大可以放心使用，而不必关心其底层工作机制究竟是怎样的。

为了建立你的信心，让我们以一个C++小程序开始，该程序只是简单地使用了一个采用模板元编程实现的设施：

#include "libs/mpl/book/chapter1/binary.hpp"

#include

int main()

{

std::cout << binary<101010>::value << std::endl;

return 0;

}

即使你一向擅长二进制算术，无需真正运行这个程序即可口算出结果，我们还是建议你不要怕麻烦，尝试编译和运行这个例子。这除了有助于建立信心外，还是一个很好的测试，看看你的编译器能否处理本书展示的代码。该程序应该向标准输出打印出二进制值101010的十进制值：

42

1.2 元程序的概念

如果按字面剖析单词“metaprogram”，它的含义就是“a program about a program”，译成中文，意思就是“一个关于另一个程序的程序”。一个不那么有节奏感的说法是，“a metaprogram is a

program that manipulates code”，即“元程序就是用于操纵代码的程序”。听起来这个概念好像有点怪怪的，但其实你可能早已熟悉这方面的一些“怪兽”了。你手头的C++编译器就是一个例子：它操纵C++代码来生成汇编语言（assembly language）或机器码（machine code）。

像YACC[Joh79]这样的解析器生成器（parser generators ）是另外一类程序操纵程序（program-manipulating program ）。

YACC 的输入是一种高阶解析器描述（parser description ），这种描述依据文法规则（grammar rule ）编写，并且附加有采用封闭的大括号括起来的动作（action ）。例如，为了采用通常的优先规则来解析和评估算术表达式，我们可以给YACC 如下的文法描述（grammar description ）：

expression : term

| expression '+' term { $$ = $1 + $3; }

| expression '-' term { $$ = $1 - $3; }

;

term : factor

| term '*' factor { $$ = $1 * $3; }

| term '/' factor { $$ = $1 / $3; }

;

factor : INTEGER

| group

;

group : '(' expression ')'

;

作为响应，YACC 将会生成一个C/C++源文件，其中包含有一个yyparse

函数（以及一些别的东西），我们可以调用它以便根据文法来解析文本并执行适当的动作：

int main(){

extern int yyparse();

return yyparse();

}

YACC 的用户大多在解析器设计领域操作，因此我们将YACC 的输入语言称为该系统的领域语言（domain language ）。因为用户程序的其余部分通常需要一个通用的编程系统，并且必须和生成的解析器（generated parser ）互动，所以YACC 将领域语言翻译成宿主语言（host language ）—C 语言，然后用户编译生成的语言代码，并将其与所编写的其他部分代码进行链接（link ）。如此看来，领域语言经历了两个翻译（或转换，translation ）步骤，用户总是可以很清醒地意识到它与程序其余部分之间的分界。

2第1章

1.3 在宿主语言中进行元编程

YACC 是一个翻译器（translator ）的例子，即是这样的一个元程序：其领域语言不同于其宿主语言。在像Scheme[SS75]这样的语言中，还存在一种形式更有意思的元编程。Scheme 元编程程序员（metaprogrammer ）将他的领域语言定义为Scheme 自身的一个合法的子集，元程序在与“处理用户程序的其余部分”相同的翻译步骤中执行。程序员在普通编程、元编程以及在领域语言中编程之间穿梭往来，但他们通常不会意识到这个转换过程，并且能够将多个领域无缝地联合于同一个系统中。

令人惊讶的是，如果你拥有一个C++编译器，以上所述的元编程威力恰好唾手可得。本书的其余部分将讲解如何释放这种威力，并且展示如何以及何时去使用它。

1.4 在C++中进行元编程

在C++中，几乎是在不经意中发现模板机制为原生语言元编程（native language metaprogramming ）提供了丰富的设施（[Unruh94], [Veld95b]）。在这一节中，我们将探索元编程的基本机制以及在C++中进行元编程的一些惯用法。

1.4.1 数值计算

最早的C++元程序在编译期执行整数计算，其中最早的元程序之一是Erwin Unruh 在一次C++

标准委员会会议上所展示的。那实际上是一段不合法的代码，在其编译错误信息中含有一系列计算出来的质数值！

由于不合法的代码很难有效地应用于规模较大的系统中，因此让我们来考察一个稍微实际一点的应用。下面的元程序（这是我们上面用于测试编译器的那个小例子的“心脏”代码）将无符号的十进制数值转换为等价的二进制值，允许我们用一种易辨识的形式来表示二进制常数：template

struct binary

{

static unsigned const value

= binary::value * 2

// 将高位位移向低位

+ N%10;

};

template <>

// 特化struct binary<0>

// 终结递归{static unsigned const value = 0;};unsigned const one = binary<1>::value;unsigned const three = binary<11>::value;

unsigned const five = binary<101>::value;

概述3

译，台湾峰信息股份有限公司印行）第

4第1章

unsigned const seven = binary<111>::value;

unsigned const nine = binary<1001>::value;

如果你有这样的疑问：“程序在哪儿啊？”，那么请思考一下，当我们访问binary的嵌套成员::value时发生了什么。binary template针对一个较小的数N进行实例化，直到N变为0，并且该特化版被用做终结条件。这个处理过程有我们熟知的递归函数调用的味道，那么程序究竟是什么呢？毕竟这只是一个类模板而已？是这样的，本质上，这里编译器被用于解释（interpret）我们这个小型元程序。

错误检查

这儿没有采取任何措施来阻止用户向binary传递一个诸如678之类的值，即它的十进制表示并不是一个有效的二进制值。所得结果有几分奇怪（其值为6x22 + 7x21 + 8x20）。毋庸置疑，诸如678这样的输入很可能意味着用户的逻辑中出现了臭虫。在第3章，我们将向你展示如何确保只有当N的十进制表示仅由0和1构成时，才可以编译binary::value。

由于C++语言对编译期计算和运行期计算的表达方式强加了一些区别，因此，元程序看起来不同于它们的运行期对应物。如同在Scheme中一样，C++元编程程序员采用“和编写普通程序相同的”语言来编写代码，但是在C++中，程序员只能使用完整语言的一个编译期子集进行元编程。不妨将下面这个直观的运行期版本的binary和先前的例子比较一下：

unsigned binary(unsigned long N)

{

return N == 0 ? 0 : N%10 + 2 * binary(N/10);

}

运行期版本和编译期版本之间一个关键的不同在于终结条件的处理方式。我们的meta-binary（元程序版本的binary）使用模板特化（template specialization）来描述当N为0时干些啥。“存在用做终结条件的模板特化”是几乎所有C++ 元程序所具有的共性，尽管在某些情形下，它们隐藏在一个元编程程序库接口的背后。

下面这个使用for循环来取代递归的binary版本，凸现了存在于运行期C++和编译期C++之间的另一个重要区别：

unsigned binary(unsigned long N)

{

unsigned result = 0;

for (unsigned bit = 0x1; N; N /= 10, bit <<= 1)

{

if (N%10)

result += bit;

}

return result;

}

尽管这个版本比采用递归的那个版本冗长，然而很多C++程序员却感觉这个版本更舒服，原因并不仅在于运行期的迭代（iteration）有时比递归更高效，还在于这个版本看上去更加直观。

C++语言的编译期组成部分通常称为“纯函数性语言（pure functional language ）”，因为它和Haskell 这样的语言具有一个共同的特性：（元）数据是不可变的（常性的，immutable ），并且（元）函数没有副作用（side effect ）。结果导致编译期C++没有任何与用于运行期C++中的非常量变量相对应的东西。由于你无法在不检查其终结条件中一些可变的（mutable ）东西的状态的情况下编写一个（有限）循环，因此在编译期无法实现迭代（iteration ）。因此，对于C++ 元程序来说，递归（recursion ）是惯用的手段。

1.4.2 类型计算

远比在编译期进行数值计算的能力重要得多的是C++“对类型进行计算（compute with types ）”的能力。事实上，类型计算（type computation ）将在本书余下内容中占据支配性的地位，我们会在下一章的第一节就给出这方面的例子。在我们检视后续内容期间，你可能会把模板元编程想象成“对类型进行计算”。

尽管你可能必须阅读第2章才能了解有关类型计算（type computation ）的细节知识，然而在此我们希望给你一个有关其威力的初步认知。还记得我们的YACC 表达式求值器（expression evaluator ）吗？事实证明我们不需要使用一个翻译器（translator ）来获得那种威力和便利。利用来自Boost Spirit 程序库的适当的包覆代码（surrounding code ），以下合法的C++代码就可以发挥等价的功能：

expr =

( term[expr.val = _1] >> '+' >> expr[expr.val += _1] )

| ( term[expr.val = _1] >> '-' >> expr[expr.val -= _1] )

| term[expr.val = _1]

;

term =

( factor[term.val = _1] >> '*' >> term[term.val *= _1] )

| ( factor[term.val = _1] >> '/' >> term[term.val /= _1] )

| factor[term.val = _1]

;

factor =

integer[factor.val = _1]

| ( '(' >> expr[factor.val = _1] >> ')' )

;

每一个赋值都存储有一个函数对象（function object ），分别用于对其右侧的文法（grammar ）进行解析和评估。当被调用时，每一个被存储的函数对象的行为完全由“用于构造它的表达式”的类型所决定，而每一个表达式的类型则由一个关联有形形色色运算符的元程序进行计算的。

就像YACC 一样，Spirit 程序库是一个从文法规范（grammar specification ）生成解析器（parser ）的元程序。不同于YACC 的是，Spirit 采用C++自身的一个子集来定义其领域语言（domain language ）。如果此刻你还不明白是如何做到这一点的，不必忧心忡忡，到读完这本书时，你就会恍然大悟。

概述

5

1.5 为何进行元编程

那么，元编程有什么好处呢？毫无疑问，对于我们这里讨论的同类问题来说，还存在更简单的解决方案。让我们看看另外两种途径，考察当被应用于对二进制数值的解释（interpretation ）和解析器（parser ）的构造时它们是如何运作的。

1.5.1 替代方案1：运行期计算

最直截了当的方案是在运行期而非编译期执行计算。例如，我们可以使用早先展示的binary 函数实现之一，也可以使用一个用于在运行期解释（interpret ）输入文法（input grammar ）的解析系统（parsing system ）（解析操作发生于当我们第一次叫它去解析时）。

采用元程序最显而易见的理由是，通过在结果所得程序启动之前做尽可能多的工作，我们可以获得速度更快的程序。当一个文法（grammar ）被编译时，YACC 执行可观的解析表（parse table ）生成和优化步骤，如果在运行期做这些事，将会显著地降低程序的整体性能。类似地，由于binary 在编译期做工作，其::value 是一个编译期常数，编译器可以将其直接编码（encode ）到目的码（object code ）中，因而当需要使用它时可以节省内存查找时间。

使用元程序的一个更微妙但也更重要的理由是，这种做法可以使得计算结果和目标语言进行更深入地互动。例如，C++数组的大小只能利用binary::value 这样的编译期常数合法地进行指定，而不能通过一个运行期函数返回值进行指定。在YACC 文法中用大括号括起来的动作可以包含任意C/C++代码—这些代码作为生成的解析器的一部分而被执行。只有当动作（actions ）处理于文法编译期间并传递给目标C/C++编译器时，才有可能做到这一点。

1.5.2 替代方案2：用户分析

不是在运行期或编译期进行计算，我们也可以手动做这件事。毕竟，将二进制数值转换为十六进制值

从而使它们可被直接用做C++字面常数，是很常见的编程实践，何况YACC 和Boost.Spirit 程序库所执行的将文法描述转换为一个解析器（parser ）的翻译步骤也是众所周知的。

如果替代的是编写一个只被使用一次的元程序，我们就可以辩称用户分析（user analysis

）更加方便：手工转换一个二进制数值要比编写一个正确的元程序做这件事当然要容易得多。然而在大多数情况下，这种做法的方便性远不及元程序的方式。一旦一个元程序被写好了，整个C++社群的其他程序员均可受惠于它所带来的方便性。

不管一个元程序被使用多少次，它总是可以让用户编写出更富有表达力的代码，因为用户可以以相应于他的心智模型（mental model ）的形式来指定结果。在一个个体位（bit ）值有意义的环境（context ）中，写binary<101010>::value 要比42或传统的0x2a 更有意义。类似地，手写的解析器的C 源代码通常会使其文法元素之间的逻辑关系变得模糊不清、晦涩难懂。

最后，由于人类易犯错误，而一个元程序的逻辑只需要编写一次，结果所得程序更有可能

6第1章

正确且维护性更好。转换二进制值是一个如此平常的任务，以至于人们往往太不专心乃至犯错。相对而言，手工编写解析表（parse table ）则需要付出过多的注意力（任何做过这件事的人都可以证实这一点）。防止犯错误是使用一个像YACC 这样的解析器生成器（parser generator ）的充分理由。

1.5.3 为何进行C++ 元编程

在像C++这样的语言中，领域语言（domain language ）不过是程序其余部分所使用的语言的一个子集，在这种情形下，元编程甚至具有更大的威力和方便性：

? 用户可以径自使用领域语言，而无需学习一种异质的语法，而且也不会打断原先代码的流程。

? 将元程序与其他代码、尤其是其他元程序进行接口连接，会变得平滑得多。

? 无需附加的生成（build ）步骤（就像YACC 所强加的那样）。

在传统编程中，程序员常常要努力获得表达性、正确性和效率之间的恰当的平衡。元编程通常允许我们消除这种典型的紧张和压力，这是通过将表达性和正确性所需的计算从运行期转移至编译期而达成的。

1.6 何时进行元编程

你已经看到一些关于为何需要模板元编程的例子，你也已经一瞥如何进行模板元编程，但我们还没有讨论何时适合进行模板元编程。然而，我们其实已经接触了与它使用有关的大部分准则。作为一个指导方针，如果以下条件中有任何三个适合你，可能就适宜采用一个元编程解决方案：

? 你希望代码根据问题领域的抽象进行表达。例如，你可能需要将一个解析器（parser ）表达成这样的东西：它看起来像一个正式的文法（formal grammar ）而不是充满数值的表（table ）或子例程（subroutine ）的集合。你希望数组算术使用“针对矩阵或向量对象”的运算符记号编写而成，而不是根据对一系列数值的循环编写而成。

? 如果不使用模板元编程的话，你需要编写大量的刻板的实现代码。

? 你需要基于组件的类型参数的属性来选择组件实现。

? 你希望利用C++中泛型编程（generic programming ）的极富价值的特性，例如静态类型检查（static type checking ）和行为定制（behavioral customization ）能力，同时无需付出效率上的代价。

? 你希望全部在C++语言内做这件事，而无需使用第三方的工具或定制的源代码生成器（source code generator ）。

1.7 为何需要元编程程序库

不是白手起家构建元程序，我们将与Boost 元编程库（MPL ）提供的高阶设施协作。即使你没有选择这本书来探索MPL ，我们还是认为你会发现花在学习MPL 上的投资是值得的，因为它可以为你的日常编程工作带来诸多好处：

概述

7

1. 质量（Quality ）。大多数使用模板元编程组件的程序员将其看做“应用于一些更伟大目的”的实现细节。这种看法完全正确。比较而言，MPL 作者将开发有用的、高质量的工具和惯用法作为他们的中心使命。一般来讲，Boost 元编程库中的组件要比那些为了别的目标而开发的组件灵活性更大，且有着更好的实现。此外，你还可以期望从将来发布的升级版中获得更多的优化和改善。

2. 复用（Reuse ）。所有程序库都将代码封装为可复用的组件。更重要的是，一个设计良好的泛型程序库建立了一个有关概念和惯用法的框架（framework ），此框架为解决问题提供了一个可复用的心智模型（reusable mental model ）。就像C++ Standard Template Library 给与我们迭代器（iterators ）和函数对象（function object ）协议一样，Boost 元编程库提供了类型迭代器（type iterator ）和元函数协议。一个经过深思熟虑的惯用法框架，使得元编程程序员可以集中于自己的设计决策，专注于手头的任务。

3. 移植性（Portability ）。一个优秀的程序库可以“掩饰”平台有别的丑陋的现实。尽管在理论上，任何C++ 元程序都不必关心这方面的问题，然而在实践中，甚至在C++被标准化六年后，各家编译器对模板的支持仍然不一致。对此你不应感到意外，因为模板是C++语言力所能及的最复杂的特性，另一方面，这一事实也成就了C++ 元编程的威力。

4. 乐趣（Fun ）。一遍遍地重复相同的刻板代码是枯燥乏味的。将高级组件迅速组装成可读性好的、优雅的设计才是有趣的事情！MPL 通过消除对最常反复使用的元编程模式的需要，减少了这种无趣的行为。尤其是借助MPL ，我们可以容易且优雅地避免编写作为终结条件的模板特化版本（template specializations ）和显式递归代码。

5. 生产率（Productivity ）。除了个人满足外，我们项目的健康性仰仗于充满乐趣的编程。当我们不再有乐趣时就会感到身心疲倦，效率低下，马虎随便。你知道，充满臭虫的代码甚至比慢慢腾腾地编写代码本身要付出更高的代价。

正如你看到的那样，Boost 元编程库是出于同样的实践考虑所激发的，即成为任何其他程序库的开发基础。我们认为它的出现是一个征兆：模板元编程终将离开高深莫测的王国，并在普通C++程序员的日常必备技能中寻觅一席之地。

最后，我想特别强调一下上面所言的第四个条款：MPL 不但使得元编程切实可行且易于使用，而且与之过从亦其乐无穷。在此祝愿诸位就像我们在使用和开发它的过程中享受快乐一样，在学习它的过程中也其乐融融。8第1

章