为什么C++编译器不能支持对模板的分离式编译

[pongba]

以下是我的一些思考，大家该砸什么砸什么哦^_^
http://www.csdn.net/Develop/read_article.asp?id=21696

[blas]

这篇文章还没有审批通过，请稍后……
（说明：推荐给《程序员》杂志的文章只有没被采用，或者已经在杂志上发表了，才会审批通过。）

[Analyst]

因为很难实现。

[pongba]

对不起，一时偷懒，帖出来吧：、

为什么C++编译器不能支持对模板的分离式编译

--ppLiu

首先，C++标准中提到，一个编译单元[translation unit]是指一个.cpp文件以及它所include的所有.h文件，.h文件里的代码将会被扩展到包含它的.cpp文件里，然后编译器编译该.cpp文件为一个.obj文件，后者拥有PE[Portable Executable,即windows可执行文件]文件格式，并且本身包含的就已经是二进制码，但是，不一定能够执行，因为并不保证其中一定有main函数。当编译器将一个工程里的所有.cpp文件以分离的方式编译完毕后，再由连接器(linker)进行连接成为一个.exe文件。

举个例子：

//---------------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++中这个名字当然是经过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实际的地址。

完成。



然而，对于模板，你知道，模板函数的代码其实并不能直接编译成二进制代码，其中要有一个“具现化”的过程。举个例子：

//----------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中就找不到一行模板具现体的二进制代码，于是连接器也傻眼了！！！！！！！！！！！！！！！！！！！！！！！！！

[pongba]

写这篇文章的起因是一个朋友问我怎么将模板的声明和实现分开不能编译的。
想了一个晚上，想出这么一说。

[Lymtics]

没办法,即使解释了也只能干瞪眼...............打倒....

让我想想,该打倒谁??!!

[Analyst]

分离编译C++是支持的，要用export关键字定义。不过还没有什么实际的编译器实现export，因为很难实现，这里有一个标准的问题。

[Wolf0403]

那么,为什么可以在 VC 的 Per-compiled header 里面包含 vector 等模板类头文件？也可以包含自己写的模板类

[ttlb]

to: Wolf0403(完美废人)

<vector> 一个文件里包括了所有 vector 类的实现

你自己写的模板类头文件难道不包含函数的定义？我很想知道你是怎么弄的。

[blas]

那楼主能不能解释一下非模板程序的两种情况下编译器的处理：
（1）声明与定义分开
（2）声明与定义在同一个.h文件中（编译时不会生成相应的obj文件）
特别是对于（2），当有多个cpp文件包含它时编译器如何处理

[pongba]

靠，我都说成这样了，自己思考去

[blas]

我是想问（2）中的include guard是如何实现的

[arya]

实现export要改链接器模型, 等于要把一部分编译器的工作转移到链接器, 这是很费劲的工作, 还导致复杂得多的编译链接模式. 所以一般编译器都不支持.

[sham2k]

对模板，我认为是这样的：
编译器编译到使用模板的程序，就自动复制一份模板的实现代码，替换掉其中的类型定义，再编译成二进制形式供连接器连接。
如果要将模板实现分开编译，编译器编译到模板时，不知道该如何替换其中的类型，也就无法生成相应的二进制代码。如果想让模板能编译出二进制代码，则必须使用某种动态的地址和变量分配方案，有点象中间字节码，由连接程序根据需要连接的类型，将这个中间字节码进行地址和类型的转换，再连接。这样可能处理太复杂，所以难于实现。
换句话说，直接编译模板生成的二进制代码，和普通的.obj代码肯定不同，不能直接使用。

[sham2k]

在分离式编译的环境下，编译器编译某一个.cpp文件时并不知道另一个.cpp文件的存在，也不会去查找[当遇到未决符号时它会寄希望于连接器]。

这话可能有错。
如果编译器不关心符号，那么我们编写 #include .. extern..作什么？

[pongba]

to sham2k(sham2k):
我并非说编译器不关心符号，举个例子：对于一个只见声明不见定义的函数（对于编译器）而言，编译器无法将你在程序中调用函数之处的函数符号换成真实的地址，所以它只能寄希望于连接器能够在其它编译单元中找到这个符号（这个函数的定义）了。

[DarkSpy]

export 关键字目前只有 Comeau 编译器实现，其他地球上似乎没有一款大众点的编译器实现，至少在我知道的范围内。而在3个月前在C++新闻组和Comeau的负责人讨论了许多关于export的实现问题，当时除了Comeau，还有一位写gcc代码的人，最后，他们给了我两分资料，一份是PDF的，还有一份是关于C++标准委员会的，没什么关系。那份 PDF 的资料在以下 URL：
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf

[DaNiao]

关键的问题是linker不想回去调compiler
因为很麻烦