参考：
https://www.cnblogs.com/cnsec/p/3789824.html
general的编译链接过程：
首先，C++标准中提到，一个编译单元[translation unit]是指一个.cpp文件以及它所include的所有.h文件，.h文件里的代码将会被扩展到包含它的.cpp文件里，然后编译器编译该.cpp文件为一个.obj文件，但是，不一定能够执行，因为并不保证其中一定有main函数。当编译器将一个工程里的所有.cpp文件以分离的方式编译完毕后，再由连接器(linker)进行连接成为一个可执行文件。
举个例子：
-
//---------------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中，调用了f函数，然而当编译器编译main.cpp时，它所仅仅知道的只是main.cpp中所包含的test.h文件中的一个关于void f();的声明，所以，编译器将这里的f看作外部连接类型，即认为它的函数实现代码在另一个.obj文件中，本例也就是test.obj，也就是说，main.obj中实际没有关于f函数的哪怕一行二进制代码，而这些代码实际存在于test.cpp所编译成的test.obj中。在main.obj中对f的调用只会生成一行call指令，像这样： call f （C++中这个名字当然是经过处理的）
在编译时，这个call指令显然是错误的，因为main.obj中并无一行f的实现代码。那怎么办呢？这就是连接器的任务，连接器负责在其它的.obj中[本例为test.obj]寻找f的实现代码，找到以后将call f这个指令的调用地址换成实际的f的函数进入点地址。需要注意的是：连接器实际上将工程里的.obj“连接”成了一个.exe文件，而它最关键的任务就是上面说的，寻找一个外部连接符号在另一个.obj中的地址，然后替换原来的“虚假”地址。
这个过程如果说的更深入就是： call f这行指令其实并不是这样的，它实际上是所谓的stub，也就是一个jmp 0x23423[这个地址可能是任意的，然而关键是这个地址上有一行指令来进行真正的call f动作。也就是说，这个.obj文件里面所有对f的调用都jmp向同一个地址，在后者那儿才真正”call”f。这样做的好处就是连接器修改地址时只要对后者的call XXX地址作改动就行了。但是，连接器是如何找到f的实际地址的呢[在本例中这处于test.obj中]，因为.obj于.exe的格式都是一样的，在这样的文件中有一个符号导入表和符号导出表[import table和export table]其中将所有符号和它们的地址关联起来。这样连接器只要在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中悬而未决的call XXX地址改成f实际的地址。
完成。
模板的编译链接过程：
然而，模板函数的代码其实并不能直接编译成二进制代码，其中要有一个“具现化”的过程。举个例子：
-
//----------main.cpp------//
-
template<
class T>
-
void
f(
T
t) {}
-
-
int main()
-
{
-
…
//do something
-
f(
10);
//call f<int> 编译器在这里决定给f一个f<int>的具现体
-
…
//do other thing
-
}
也就是说，如果你在main.cpp文件中没有调用过f，f也就得不到具现，从而main.obj中也就没有关于f的任意一行二进制代码！！如果你这样调用了：
f(10); //f<int>得以具现化出来
f(10.0); //f<double>得以具现化出来
这样main.obj中也就有了f<int>,f<double>两个函数的二进制代码段。以此类推。
然而具现化要求编译器知道模板的定义，不是吗？
看下面的例子：[将模板和它的实现分离]
-
//-------------test.h----------------//
-
template<
class T>
-
class
A
-
{
-
public:
-
void f();
//这里只是个声明
-
};
-
-
//---------------test.cpp-------------//
-
＃include”test.h”
-
template<
class T>
-
void
A<T>::f()
//模板的实现，但注意：不是具现
-
{
-
…
//do something
-
}
-
-
//---------------main.cpp---------------//
-
＃include”test.h”
-
int main()
-
{
-
A<
int> a;
-
a. f();
//编译器在这里并不知道A<int>::f的定义，因为它不在test.h里面
-
//于是编译器只好寄希望于连接器，希望它能够在其他.obj里面找到
-
//A<int>::f的实现体,在本例中就是test.obj，然而，后者中真有A<int>::f的
-
//二进制代码吗？NO！！！因为C++标准明确表示，当一个模板不被用到的时
-
//侯它就不该被具现出来，test.cpp中用到了A<int>::f了吗？没有！！所以实
-
//际上test.cpp编译出来的test.obj文件中关于A::f的一行二进制代码也没有
-
//于是连接器就傻眼了，只好给出一个连接错误
-
//但是，如果在test.cpp中写一个函数，其中调用A<int>::f，则编译器会将其
-
//具现出来，因为在这个点上[test.cpp中]，编译器知道模板的定义，所以能够具现化，
-
//于是，test.obj的符号导出表中就有了A<int>::f这个符号的地址，于是连接器就能
-
//够完成任务。
-
-
}
关键是：在分离式编译的环境下，编译器编译某一个.cpp文件时并不知道另一个.cpp文件的存在，也不会去查找[当遇到未决符号时它会寄希望于连接器]。这种模式在没有模板的情况下运行良好，但遇到模板时就傻眼了，因为模板仅在需要的时候才会具现化出来，所以，当编译器只看到模板的声明时，它不能具现化该模板，只能创建一个具有外部连接的符号并期待连接器能够将符号的地址决议出来。然而当实现该模板的.cpp文件中没有用到模板的具现体时，编译器懒得去具现，所以，整个工程的.obj中就找不到一行模板具现体的二进制代码，于是连接器也黔驴技穷了。
总结：
像上面的这个例子，模板函数的声明在头文件内，用到这个模板函数的另一个源文件A中包含了这个头文件（但是没有包含模板函数的定义所在的文件）时，编译器只看到了声明，这时候并没有把函数的定义实例化出来，编译器直接把找到函数定义的工作甩锅给链接器。但是链接器拿到的所有.obj文件中都没有这个模板函数的实例化定义，所以链接的时候就找不到。
如果模板函数的定义也在头文件内，编译器在编译的时候就直接拿着模板实例化出这个模板函数的定义，并把这份定义存放在编译输出的.obj文件内。
所以其实模板的实例化都是在编译期完成的，如果在编译的时候，找不到模板函数的定义，就先不在这一次编译中实例化该模板函数，直接生成一个不含这个模板函数实例化结果的.obj文件，等到与其他.obj文件链接的时候再链接到一起。
因此只要让编译器能够在某一次编译时看到模板函数的定义并将其实例化出来，最后把这些编译得到的目标文件链接在一起，就不会有模板函数链接失败的问题。例如可以：（1）将模板函数的定义直接写在头文件内；（2）可以写在源文件B内，并将这个源文件B包含在源文件A内；（3）在源文件A内想办法触发这个模板函数的实例化（例如可以显式实例化：template void f<int>();）在编译A时将实例化结果写入生成的.obj文件内，让B的.obj文件与A的.obj文件链接时能够找到实例化结果。
上面的三种方法，前两种都是在编译期让所有用到模板函数的地方直接实例化函数定义，这样做会使每一个编译结果都包含实例化结果，导致目标文件较大，链接的时候需要把重复的实例化定义去重，编译链接的时间也会长一些。使用第三种方法，可以用一个特定的.cc文件显示实例化所有会被用到的模板实例，单独编译这个文件，最后让它参与链接，用这种方法，不会产生巨大的头文件，加快编译速度。而且头文件本身也显得更加“干净”和更具有可读性。但这个方法不能得到惰性实例化的好处，即它将显式地生成所有的成员函数，另外还要维护一个这样的文件。所以为了容易使用，几乎总是在头文件中放置全部的模板声明和定义。
805
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
