为什么C++编译器不能支持对模板的分离式编译首先，C++标准中提到，一个编译单元[translationunit]是指一个.cpp文件以及它所include的所有.h文件，.h文件里的代码将会被扩展到包含它的.cpp文件里，然后编译器编译该.cpp文件为一个.obj文件，后者拥有PE[PortableExecutable,即windows可执行文件]文件格式，并且本身包含的就已经是二进制码，但是，不一定能够执行，因为并不保证其中一定有main函数。当编译器将一个工程里的所有.cpp文件以分离的方式编译完毕后，再由连接器(linker)进行连接成为一个.exe文件。举个例子：//---------------test.h-------------------//voidf();//这里声明一个函数f//---------------test.cpp--------------//#include”test.h”voidf(){…//dosomething}//这里实现出test.h中声明的f函数//---------------main.cpp--------------//#include”test.h”intmain(){f();//调用f，f具有外部连接类型}在这个例子中，test.cpp和main.cpp各被编译成为不同的.obj文件[姑且命名为test.obj和main.obj]，在main.cpp中，调用了f函数，然而当编译器编译main.cpp时，它所仅仅知道的只是main.cpp中所包含的test.h文件中的一个关于voidf();的声明，所以，编译器将这里的f看作外部连接类型，即认为它的函数实现代码在另一个.obj文件中，本例也就是test.obj，也就是说，main.obj中实际没有关于f函数的哪怕一行二进制代码，而这些代码实际存在于test.cpp所编译成的test.obj中。在main.obj中对f的调用只会生成一行call指令，像这样：callf[C++中这个名字当然是经过mangling[处理]过的]在编译时，这个call指令显然是错误的，因为main.obj中并无一行f的实现代码。那怎么办呢？这就是连接器的任务，连接器负责在其它的.obj中[本例为test.obj]寻找f的实现代码，找到以后将callf这个指令的调用地址换成实际的f的函数进入点地址。需要注意的是：连接器实际上将工程里的.obj“连接”成了一个.exe文件，而它最关键的任务就是上面说的，寻找一个外部连接符号在另一个.obj中的地址，然后替换原来的“虚假”地址。这个过程如果说的更深入就是：callf这行指令其实并不是这样的，它实际上是所谓的stub，也就是一个jmp0x23423[这个地址可能是任意的，然而关键是这个地址上有一行指令来进行真正的callf动作。也就是说，这个.obj文件里面所有对f的调用都jmp向同一个地址，在后者那儿才真正”call”f。这样做的好处就是连接器修改地址时只要对后者的callXXX地址作改动就行了。但是，连接器是如何找到f的实际地址的呢[在本例中这处于test.obj中]，因为.obj于.exe的格式都是一样的，在这样的文件中有一个符号导入表和符号导出表[importtable和exporttable]其中将所有符号和它们的地址关联起来。这样连接器只要在test.obj的符号导出表中寻找符号f[当然C++对f作了mangling]的地址就行了，然后作一些偏移量处理后[因为是将两个.obj文件合并，当然地址会有一定的偏移，这个连接器清楚]写入main.obj中的符号导入表中f所占有的那一项。这就是大概的过程。其中关键就是：编译main.cpp时，编译器不知道f的实现，所有当碰到对它的调用时只是给出一个指示，指示连接器应该为它寻找f的实现体。这也就是说main.obj中没有关于f的任何一行二进制代码。编译test.cpp时，编译器找到了f的实现。于是乎f的实现[二进制代码]出现在test.obj里。连接时，连接器在test.obj中找到f的实现代码[二进制]的地址[通过符号导出表]。然后将main.obj中悬而未决的callXXX地址改成f实际的地址。完成。然而，对于模板，你知道，模板函数的代码其实并不能直接编译成二进制代码，其中要有一个“具现化”的过程。举个例子：//----------main.cpp------//template<classT>voidf(Tt){}intmain(){…//dosomethingf(10);//callf<int>编译器在