C++模板声明和定义分离

C++有一个重要特性就是不支持分离编译，因此对于公共的模板函数或者模板类的声明和实现，一般都要放到头文件中。

1.C++的编译和链接

首先我们来看看C++中的代码如何处理成为可执行文件。在C++中，一个编译单元是指一个.cpp文件以及它所#include的所有头文件，因为头文件的代码将会被扩展到包含它的.cpp文件中，因此C++中常见的做法就是在头文件中进行函数的声明，在同名的.cpp文件中进行函数的定义（实现），然后编译该.cpp文件为一个.obj文件（win32），后者拥有PE（Portable Executable）文件格式，并且本身包含的就已经是二进制码。但是这个文件不一定能够执行，因为不能够保证其中一定有main函数的入口。当编译器将一个工程里的所有.cpp文件以分离的方式编译完成之后，再由链接器（linker）链接成为可执行文件（exe）。

示例1：

//---------------test.h-------------------//

void f();//这里声明一个函数f


//---------------test.cpp--------------//
#include”test.h”

void f() {
    //do something
    //这里实现出test.h中声明的f函数
}


//---------------main.cpp--------------//

#include”test.h”

int main(){
    f(); //调用f，f具有外部链接类型
}

在这个例子中，test. cpp和main.cpp各自被编译成不同的.obj文件（姑且命名为test.obj和main.obj），在main.cpp中，调用了void f() 函数，然而当编译器编译main.cpp时，它所仅仅知道的只是main.cpp中所包含的test.h文件中的一个关于void f();的声明，所以，编译器将这里的void f()看作外部链接类型，即认为它的函数实现代码在另一个.obj文件中，本例也就是test.obj，也就是说，main.obj中实际没有关于f()的哪怕一行二进制代码，而这些代码实际存在于test.cpp所编译成的test.obj中。这个一定要牢记，这是分离编译模式固有的。

在main.obj中对void f()的调用只会生成一行call指令，像这样：

1	call f // C++中这个名字当然是经过mangling处理过的

在编译时，这个call指令显然是错误的，因为main.obj中并无一行void f()的实现代码。那怎么办呢？编译器完成了，那么链接器就要登场了，链接器负责在其它的.obj中（本例为test.obj）寻找void f()的实现代码，找到以后将call f这个指令的调用地址换成实际的void f()的函数进入点地址。需要注意的是：链接器实际上将工程里的多个.obj链接成了一个.exe文件，而它最关键的任务就是上面说的，寻找一个外部链接符号在另一个.obj中的地址，然后替换原来的“虚假”地址。

这个过程如果说的更深入就是：

call f这行指令其实并不是这样的，它实际上是所谓的stub，也就是一个jmp 0xABCDEF。这个地址可能是任意的，然而关键是这个地址上有一行指令来进行真正的call f动作。也就是说，这个.obj文件里面所有对void f()的调用都jmp向同一个地址，在后者那儿才真正call f。这样做的好处就是链接器修改地址时只要对后者的call XXX地址作改动就行了。但是，链接器是如何找到void f()的实际地址的呢（在本例中这处于test.obj中），因为.obj与.exe的格式是一样的，在这样的文件中有一个符号导入表和符号导出表（import table和export table），其中将所有符号和它们的地址关联起来。这样链接器只要在test.obj的符号导出表中寻找符号f（当然C++对f作了mangling）的地址就行了，然后作一些偏移量处理后（因为是将两个.obj文件合并，当然地址会有一定的偏移，这个链接器会自己处理）写入main.obj中的符号导入表中f所占有的那一项即可。

这就是大概的过程，总结其中最关键的几点就是：

编译main.cpp时，编译器不知道void f()的实现，所以当碰到对它的调用时只是给出一个指示，指示链接器应该为它寻找void f()的实现体。这也就是说main.obj中没有关于void f()的任何一行二进制代码。
编译test.cpp时，编译器找到了void f()的实现。于是void f()的实现（二进制代码）出现在test.obj里。
链接时，链接器在test.obj中找到void f()的实现代码（二进制）的地址（通过符号导出表）。然后将main.obj中悬而未决的call XXX地址改成void f()实际的地址，完成。

2.模板的实例化

讲完了C++一般的编译和链接，再看看模板。模板有一个非常重要的特性就是“实例化”：模板函数的代码其实并不能直接编译成二进制代码，其中要有一个实例化的过程。

示例2：

template <typename T>
void f(T t) {
    // 函数实现
}

int main() {

    f(10);  //  call f<int> 编译器在这里决定给f一个f<int>的实例

    // ...
}

也就是说，如果你在main.cpp文件中没有调用过f，f也就得不到实例化，从而main.obj中也就没有关于f的任意一行二进制代码！如果你这样调用了：

f(10); // f()得以实例化出来

f(10.0); // f()得以实例化出来

这样main.obj中也就有了f<int>()，f<double>()两个函数的二进制代码段。以此类推。然而实例化要求编译器知道模板的定义，也就是说在编译器所编译的单元中，需要看到模板的定义，看下面的例子（将模板的声明和实现分离）。

示例3：


//-------------test.h----------------//
template <typename T>
class A {
public:
    void f();   // 这里只是个声明
};


//---------------test.cpp-------------//
#include "test.h"

template <typename T>
void A<T>::f();     // 模板的实现


//---------------main.cpp---------------//

#include "test.h"

int main() {
    A<int> a;
    a.f();      // #1 实际调用

    // ....
}

分析一下上述的程序的编译和链接过程：

编译器在#1处调用了模板函数，需要实例化，实例化就必须知道模板的定义，然后在#1处并不知道A<int>::f()的定义，因为它不在test.h里面；
于是编译器只好寄希望于连接器，希望它能够在其他.obj里面找到A<int>::f()的实例，在本例中就是test.obj；
因为C++标准明确表示，当一个模板不被用到的时侯它就不该被实例化出来，test.cpp并没有用到A<int>::f()，所以实际上test.cpp编译出来的test.obj文件中也没有关于A<int>::f的二进制代码。
于是连接器就傻眼了，只好给出一个连接错误。

但是，如果在test.cpp中写一个函数，其中调用A<int>::f()，则编译器会将其实例化出来，因为在这个点上（test.cpp中），编译器知道模板的定义，所以能够实例化，于是，test.obj的符号导出表中就有了A<int>::f()这个符号的地址，于是连接器就能够完成任务。

3.总结

综合上述分析，总结如下：

在分离式编译的环境下，编译器编译某一个.cpp文件时并不知道另一个.cpp文件的存在，也不会去查找（当遇到未决符号时它会寄希望于连接器）。这种模式在没有模板的情况下运行良好，但遇到模板时就傻眼了，因为模板仅在需要的时候才会实例化出来，所以，当编译器只看到模板的声明时，它不能实例化该模板，只能创建一个具有外部连接的符号并期待连接器能够将符号的地址决议出来。然而当实现该模板的.cpp文件中没有用到模板的实例时，编译器懒得去实例化，所以，整个工程的.obj中就找不到一行模板实例的二进制代码，于是连接器也黔驴技穷了。