【资料整理】“将模板放在头文件中”

在讲到C++中的模板时，书上的一句话让我在网上搜过了一番。学习后整理如下，以备后查。

书上原话为：【将模板放在头文件中，并在需要使用模板的文件中包含头文件】。

以下整理自网上。

“通常情况下，你会在.h文件中声明函数和类，而将它们的定义放置在一个单独的.cpp文件中。但是在使用模板时，这种习惯性做法将变得不再有用，因为当实例化一个模板时，编译器必须看到模板确切的定义，而不仅仅是它的声明。因此，最好的办法就是将模板的声明和定义都放置在同一个.h文件中。这就是为什么所有的STL头文件都包含模板定义的原因。”

"标准要求编译器在实例化模板时必须在上下文中可以查看到其定义实体；而反过来，在看到实例化模板之前，编译器对模板的定义体是不处理的——原因很简单，编译器怎么会预先知道 typename 实参是什么呢？因此模板的实例化与定义体必须放到同一翻译单元中。"

"《C++编程思想》第15章(第300页)说明了原因：
模板定义很特殊。由template<…> 处理的任何东西都意味着编译器在当时不为它分配存储空间，它一直处于等待状态直到被一个模板实例告知。在编译器和连接器的某一处，有一机制能去掉指定模板的多重定义。所以为了容易使用，几乎总是在头文件中放置全部的模板声明和定义。"

"对C++编译器而言，当调用函数的时候，编译器只需要看到函数的声明。当定义类类型的对象时，编译器只需要知道类的定义，而不需要知道类的实现代码。因此，因该将类的定义和函数声明放在头文件中，而普通函数和类成员函数的定义放在源文件中。但在处理模板函数和类模板时，问题发生了变化。要进行实例化模板函数和类模板，要求编译器在实例化模板时必须在上下文中可以查看到其定义实体；而反过来，在看到实例化模板之前，编译器对模板的定义体是不处理的——原因很简单，编译器怎么会预先知道 typename 实参是什么呢？因此模板的实例化与定义体必须放到同一翻译单元中。"

=============================================================================

如果用传统编程方式来编写模板，会发生什么事呢？我们来看看：

// array.h        
template <typename T, int SIZE>
class array{
	T data_[SIZE];
	array (const array& other);
	const array& operator = (const array& other);
  public:
	array(){};
	T& operator[](int i);
	const T& get_elem (int i) const;
	void set_elem(int i, const T& value);
	operator T*();      
};  

// array.cpp
#include "array.h"

template<typename T, int SIZE> T& array<T, SIZE>::operator [](int i){
	return data_[i];
}

template<typename T, int SIZE> const T& array<T, SIZE>::get_elem(int i) const{
    return data_[i];
}

template<typename T, int SIZE> void array<T, SIZE>::set_elem(int i, const T& value){
    data_[i] = value;
}
template<typename T, int SIZE> array<T, SIZE>::operator T*(){
    return data_;
}

编译时会出现3个错误。问题出来了：
  为什么错误都出现在第一个地方？
  为什么只有3个链接出错？array.cpp中有4个成员函数。
对于第二个问题，答案是：实例化的惰性导致这种现象。在main.cpp中还没有用上operator[]，编译器还没有实例化它的定义。
  
要回答上面的问题，就要深入了解模板的实例化过程。

模板实例化
程序员在使用模板类时最常犯的错误是将模板类视为某种数据类型。所谓类型参量化(parameterized types)这样的术语导致了这种误解。模板当然不是数据类型，模板就是模板，恰如其名：

编译器使用模板，通过更换模板参数来创建数据类型。这个过程就是模板实例化(Instantiation)。模板实例化取决于编译器能够找到可用代码来创建实例(称之为实例化要素 point of instantiation)。要创建实例，编译器不但要看到模板的声明，还要看到模板的定义。

再回头看上面的例子，可以知道array是一个模板，array<int, 50>是一个模板实例 - 一个类型。从array创建array<int, 50>的过程就是实例化过程。实例化要素体现在main.cpp文件中。如果按照传统方式，编译器在array.h文件中看到了模板的声明，但没有 模板的定义，这样编译器就不能创建类型array<int, 50>。但这时并不出错，因为编译器认为模板定义在其它文件中，就把问题留给链接程序处理。

现在，编译array.cpp时会发生什么问题呢？编译器可以解析模板定义并检查语法，但不能生成成员函数的代码。它无法生成代码，因为要生成代码，需要知道模板参数，即需要一个类型，而不是模板本身。

这样，链接程序在main.cpp 或 array.cpp中都找不到array<int, 50>的定义，于是报出无定义成员的错误。

解决方法
认识了问题，就能够解决问题：

1.   在实例化要素中让编译器看到模板定义。
2.   用另外的文件来显式地实例化类型，这样链接器就能看到该类型。
3.   使用export关键字。

前两种方法通常称为包含模式，第三种方法则称为分离模式（第三种方法因表现性能很差，受到了几乎所有知名编译器供应商的强烈抵制）。

第一种方法意味着在使用模板的转换文件中不但要包含模板声明文件，还要包含模板定义文件。

• 要么在array.h中 定义了所有的成员函数。
• 要么在main.cpp文件中也包含进array.cpp文件。

这样编译器就能看到模板的声明和定义，并由此生成 array<int, 50>实例。这样做的缺点是编译文件会变得很大，显然要降低编译和链接速度。

第二种方法，通过显式的模板实例化得到类型。最好将所有的显式实例化过程安放在另外的文件中。在本例中，可以创建一个新文件TemplateInstantiations.cpp

// TemplateInstantiations.cpp                
#include "array.cpp"

template class array <int, 50>; // 显式实例化

array<int, 50>类型不是在main.cpp中产生，而是在TemplateInstantiations.cpp中产生。这样链接器就能够找到它的定义。用 这种方法，不会产生巨大的头文件，加快编译速度。而且头文件本身也显得更加“干净”和更具有可读性。但这个方法不能得到惰性实例化的好处，即它需要手动地显式生 成所要用到的成员函数，即要手动维护TemplateInstantiations.cpp文件。

第三种方法是在模板定义中使用export关键字，剩下的事就让编译器去自行处理了。标准 C++ 为此制定了“模板分离编译模式（Separation Model）”及 export 关键字。然而由于 template 语义本身的特殊性使得使用 export 的时候，性能很差。编译器不得不像 .net 和 java 所做的那样，为模板实体生成一个“中间伪代码（IPC，intermediate pseudo- code）”，使得其它翻译单元在实例化时可找到定义体；而在遇到实例化时，根据指定的 typename 实参再将此 IPC 重新编译一遍，从而达到“分离编译”的目的。因此，该标准受到了几乎所有知名编译器供应商的强烈抵制。

=======================================================================

本文译自《C++ Template: The Complete Guide》一书的第6章中的部分内容。最近看到C++论坛上常有关于模板的包含模式的帖子，联想到自己初学模板时，也为类似的问题困惑过，因此翻译此文，希望对初学者有所帮助。

模板代码有几种不同的组织方式，本文介绍其中最流行的一种方式：包含模式。

大多数C/C++程序员向下面这样组织他们的非模板代码：

• 类和其他类型全部放在头文件中，这些头文件具有.hpp（或者.H, .h, .hh, .hxx）扩展名。
• 对于全局变量和（非内联）函数，只有声明放在头文件中，而定义放在点C文件中，这些文件具有.cpp（或者.C, .c, .cc, .cxx）扩展名。

这种组织方式工作的很好：它使得在编程时可以方便地访问所需的类型定义，并且避免了来自链接器的“变量或函数重复定义”的错误。由于以上组织方式约定的影响，模板编程新手往往会犯一个同样的错误。下面这一小段程序反映了这种错误。就像对待“普通代码”那样，我们在头文件中定义模板：

// basics/myfirst.hpp 

#ifndef MYFIRST_HPP 
#define MYFIRST_HPP 

// declaration of template

template <typename T>

void print_typeof (T const&);

#endif // MYFIRST_HPP

print_typeof()声明了一个简单的辅助函数用来打印一些类型信息。函数的定义放在.CPP文件中：

// basics/myfirst.cpp

#include <iostream>
#include <typeinfo>
#include "myfirst.hpp"

// implementation/definition of template

template <typename T> 
void print_typeof (T const& x) {
    std::cout << typeid(x).name() << std::endl;
}

这个例子使用typeid操作符来打印一个字符串，这个字符串描述了传入的参数的类型信息。
最后，我们在另外一个.cpp文件中使用我们的模板，在这个文件中模板声明被#include：

// basics/myfirstmain.cpp 

#include "myfirst.hpp" 

// use of the template

int main() {
    double ice = 3.0; 
    print_typeof(ice);  // call function template for type double
}

大部分C++编译器（Compiler）很可能会接受这个程序，没有任何问题，但是链接器（Linker）大概会报告一个错误，指出缺少函数print_typeof()的定义。


这个错误的原因在于，模板函数print_typeof()的定义还没有被具现化（instantiate）。为了具现化一个模板，编译器必须知道 哪一个定义应该被具现化，以及使用什么样的模板参数来具现化。不幸的是，在前面的例子中，这两组信息存在于分开编译的不同文件中。因此，当我们的编译器看 到对print_typeof()的调用，但是没有看到此函数为double类型具现化的定义时，它只是假设这样的定义在别处提供，并且创建一个那个定义 的引用（链接器使用此引用解析）。另一方面，当编译器处理myfirst.cpp时，该文件并没有任何指示表明它必须为它所包含的特殊参数具现化模板定义。

解决上面这个问题的通用解法是，采用与我们使用宏或者内联函数相同的方法：我们将模板的定义包含进声明模板的头文件中。对于我们的例子，我们可以通 过将＃i nclude "myfirst.cpp"添加到myfirst.hpp文件尾部，或者在每一个使用我们的模板的点C文件中包含myfirst.cpp文件，来达到目 的。当然，还有第三种方法，就是删掉myfirst.cpp文件，并重写myfirst.hpp文件，使它包含所有的模板声明与定义：

//basics/myfirst2.hpp

#ifndef MYFIRST_HPP 
#define MYFIRST_HPP 

#include <iostream> 
#include <typeinfo>

// declaration of template 
template <typename T> 
void print_typeof (T const&); 

// implementation/definition of template 
template <typename T> 
void print_typeof (T const& x) {
    std::cout << typeid(x).name() << std::endl;
}

#endif // MYFIRST_HPP

这种组织模板代码的方式就称作包含模式。经过这样的调整，你会发现我们的程序已经能够正确编译、链接、执行了。从这个方法中我们可以得到一些观察结果。最值得注意的一点是，这个方法在相当程度上增加了包含myfirst.hpp的开销。在这个例子中，这种开 销并不是由模板定义自身的尺寸引起的，而是由这样一个事实引起的，即我们必须包含我们的模板用到的头文件，在这个例子中 是<iostream>和<typeinfo>。你会发现这最终导致了成千上万行的代码，因为诸 如<iostream>这样的头文件也包含了和我们类似的模板定义。

这在实践中确实是一个问题，因为它增加了编译器在编译一个实际程序时所需的时间。我们因此会在以后的章节中验证其他一些可能的方法来解决这个问题。但无论如何，现实世界中的程序花一小时来编译链接已经是快的了（我们曾经遇到过花费数天时间来从源码编译的程序）。抛开编译时间不谈，我们强烈建议如果可能尽量按照包含模式组织模板代码。

另一个观察结果是，非内联模板函数与内联函数和宏的最重要的不同在于：它并不会在调用端展开。相反，当模板函数被具现化时，会产生此函数的一个新的 拷贝。由于这是一个自动的过程，编译器也许会在不同的文件中产生两个相同的拷贝，从而引起链接器报告一个错误。理论上，我们并不关心这一点：这是编译器设 计者应当关心的事情。实际上，大多数时候一切都运转正常，我们根本就不用处理这种状况。 然而，对于那些需要创建自己的库的大型项目，这个问题偶尔会显现出来。