一、基本说明
C++标准中提到，一个编译单元是指一个.cpp文件以及它所include的所有.h文件，.h文件里的代码将会被扩展到包含它的.cpp文件里，然后编译器编译该.cpp文件为一个.obj文件，后者拥有PE[PortableExecutable,即Windows可执行文件]文件格式，并且本身包含的就已经是二进制码，但是，不一定能够执行，因为并不保证其中一定有main函数。当编译器将一个工程里的所有.cpp文件以分离的方式编译完毕后，再由连接器(linker)进行连接成为一个.exe文件。
模板函数
template
const T& compareMax(const T &a, const T &b )
{
return a > b ? a : b;
}
模板函数为对近似类型的共性操作的提取，然后在编译期间根据类型进行实例化（特化），因为编译期间能够检查函数类型。
内联函数
inline int compareMax(int a, int b)
{
return a > b ? a : b;
}
inline函数对编译器而言必须是可见的，以便它能够在调用点内展开该函数。与非inline函数不同的是，inline函数不是一次函数的跳转，而是指令的展开（从而提高执行效率）。如果内联函数过大，就会导致目标码过大，增加额外的换页行为，降低指令高速缓存装置的击中率。
二、头文件
1、区别&联系
模板函数一般声明为inline函数，但是不是必须的。一个是调用点的函数展开、一个为根据类型对函数的重载。两个功能没有必然要黏在的理由。也就是说函数模板先执行，通过函数模板产生一系列的函数，具体要拿这些函数当做函数调用还是当做内联展开，那就要看inline申请是否被编译器接受。
模板函数是需要实例化的，而inline函数不一定需要实例化（当使用到inline函数指针时，需要实例化）。
2、头文件
模板函数放在头文件是因为编译器检查类型，编译器看得见函数实现才能实例化模板。如果放到函数的模板的声明和实现分开，那么将会找不到模板实现从而后面引发链接错误（目前的编译器是如此）
inline函数放在头文件是因为方便统一，如果inline函数的定义和声明是分开的，而在另外一个文件中需要调用这些inline函数得时候，内联是无法在这些调用函数内展开的（上面得第二个例子），只能调用。这样内联函数在全局范围内就失去了作用。
三、代码实例--inline函数与头文件
两个文件：
main.c中得代码如下
#include
#include "print_inline.h"
int main(int argc, char *argv[])
{
print_inline();
system("PAUSE");
return 0;
} #include
inline void print_inline()
{
printf("This is a inlinefunction\n");
} # 3 "main.c" 2
# 1 "print_inline.h" 1
inline void print_inline()
{
printf("This is a inline function\n");
}
# 4 "main.c" 2
int main(int argc, char *argv[])
{
print_inline();
system("PAUSE");
return 0;
}
很明显，在print_inline.h头文件中定义得函数print_inline()在main函数中被直接展开了，相当与我们把print_inline()函数的定义放在了main.c中，这样在编译的时候，编译器就可以把print_line()函数直接内联到main函数中。
但是如果我们把print_inline()函数的声明和定义分开，即把print_inline()函数的定义放到另外一个文件print_inline.c中，结果就不一样了，在main.i文件中得内容变为了
# 3 "main.c" 2
# 1 "print_inline.h" 1
inline void print_inline();
# 4 "main.c" 2
int main(int argc, char *argv[])
{
print_inline();
system("PAUSE");
return 0;
}
这个时候，print_inline()函数将无法在main函数中内联，我们可以查看生成得main.s汇编代码中包含了如下
代码：
LM3:
call _print_inline
其实原理很简单，就相当于用#include包含一个文件得时候，预处理得时候会直接展开这一个文件，如果文件中放有某个函数的定义，事实上就相当于把该函数定义放在了这个包含这个文件（上面得例子中的print_inline.h）的文件(main.c)中，这样就可以在main中将print_inline函数内联展开。
在很多时候，由于某些函数需要经常被调用，为了加快程序的执行速度，经常要用到inline，但是如果inline函数的定义和声明是分开的，而在另外一个文件中需要调用这些inline函数得时候，内联是无法在这些调用函数内展开的（上面得第二个例子），只能调用。这样内联函数在全局范围内就失去了作用。解决的办法就是把内联函数得定义放在头文件中，当其它文件要调用这些内联函数的时候，只要包含这个头文件就可以了。void f(); //声明一个函数f
test.cpp的代码
#include "test.h"
void f()
{
//do something
}//这里给出void f的实现
main.cpp的代码
#include "test.h"
int main()
{
f(); //调用f，f具有外部链接类型
return 0;
}
在这个例子中，test. cpp和main.cpp各被编译成为不同的.obj文件[姑且命名为test.obj和main.obj]，在main.cpp中，调用了f函数，然而当编译器编译main.cpp时，它所仅仅知道的只是main.cpp中所包含的test.h文件中的一个关于void f();的声明，所以，编译器将这里的f看作外部连接类型[external reference]，即认为它的函数实现代码在另一个.obj文件中，本例也就是test.obj，也就是说，main.obj中实际没有关于f函数的哪怕一行二进制代码，而这些代码实际存在于test.cpp所编译成的test.obj中。在main.obj中对f的调用只会生成一行call指令，像这样：
call f [C++中这个名字当然是经过mangling[处理]过的]
在编译时，这个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实际的地址。
对于模板，你知道，模板函数的代码其实并不能直接编译成二进制代码，其中要有一个“具现化”的过程。举个例子：
template
void f(T t)
{
}
int main()
{
//do something
f(10); //call f编译器在这里决定给f的具体实现
//do something
}
也就是说，如果你在main.cpp文件中没有调用过f，f也就得不到具现，从而main.obj中也就没有关于f的任意一行二进制代码！！如果你这样调用了：
f(10); //f得以具现化出来
f(10.0); //f得以具现化出来
这样main.obj中也就有了f
然而具现化要求编译器知道模板的定义，不是吗？
看下面的例子：[将模板和它的实现分离]
test.h代码
template
class A
{
public:
void f(); //这里只是个声明
};
test.cpp代码
#include "test.h"
template
void A::f() //模板的实现，但注意：不是具现
{
//do something
}
main.cpp代码
#include "test.h"
int main()
{
A a;
a.f(); //编译器在这里并不知道A::f的定义，因为它不在test.h里面
//于是编译器只好寄希望于连接器，希望它能够在其他.obj里面找到
//A::f的实现体,在本例中就是test.obj，然而，后者中真有A::f的
//二进制代码吗？NO！！！因为C++标准明确表示，当一个模板不被用到的时
//侯它就不该被具现出来，test.cpp中用到了A::f了吗？没有！！所以实
//际上test.cpp编译出来的test.obj文件中关于A::f的一行二进制代码也没有
//于是连接器就傻眼了，只好给出一个连接错误
//但是，如果在test.cpp中写一个函数，其中调用A::f，则编译器会将其
//具现出来，因为在这个点上[test.cpp中]，编译器知道模板的定义，所以能
//够具现化，于是，test.obj的符号导出表中就有了A::f这个符号的地
//址，于是连接器就能够完成任务。
return 0;
}
在分离式编译的环境下，编译器编译某一个.cpp文件时并不知道另一个.cpp文件的存在，也不会去查找[当遇到未决符号时它会寄希望于连接器]。这种模式在没有模板的情况下运行良好，但遇到模板时就傻眼了，因为模板仅在需要的时候才会具现化出来，所以，当编译器只看到模板的声明时，它不能具现化该模板，只能创建一个具有外部连接的符号并期待连接器能够将符号的地址决议出来。然而当实现该模板的.cpp文件中没有用到模板的具现体时，编译器懒得去具现，所以，整个工程的.obj中就找不到一行模板具现体的二进制代码，于是连接器也傻了!
所以该部分的文章涉及到了编译器的编译和链接的部分知识：.cpp文件与.h文件，函数声明定义分离，外部链接类型，函数地址重定位，导出表与导入表，偏移地址。