为什么C++编译器不能支持对模板的分离式编译 整理
来源:互联网 发布:罗马2全面战争优化 编辑:程序博客网 时间:2024/06/05 05:00
http://blog.csdn.net/pongba/article/details/19130
C++对模板的分离式编译问题的解答
首先,C++标准中提到,一个编译单元[translation unit]是指一个.cpp文件以及它所include的所有.h文件,.h文件里的代码将会被扩展到包含它的.cpp文件里,然后编译器编译该.cpp文件为一个.obj文件,后者拥有PE[PortableExecutable,即windows可执行文件]文件格式,并且本身包含的就已经是二进制码,但是,不一定能够执行,因为并不保证其中一定有main函数。当编译器将一个工程里的所有.cpp文件以分离的方式编译完毕后,再由连接器(linker)进行连接成为一个.exe文件。
举个例子:
---------------test.h-------------------
void f();这里声明一个函数f
---------------test.cpp--------------
#include”test.h”
void f()
{
…dosomething
} 这里实现出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,也就是一个jmp0x23423[这个地址可能是任意的,然而关键是这个地址上有一行指令来进行真正的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
void f(Tt)
{}
int main()
{
…dosomething
f(10);call f 编译器在这里决定给f一个f的具现体
…do otherthing
}
也就是说,如果你在main.cpp文件中没有调用过f,f也就得不到具现,从而main.obj中也就没有关于f的任意一行二进制代码!!如果你这样调用了:
f(10); //f得以具现化出来
f(10.0);//f得以具现化出来
这样main.obj中也就有了f,f两个函数的二进制代码段。以此类推。
然而具现化要求编译器知道模板的定义,不是吗?
看下面的例子:[将模板和它的实现分离]
//-------------test.h----------------//
template
class A
{
public:
void f();//这里只是个声明
};
//---------------test.cpp-------------//
#include”test.h”
template
voidA::f() //模板的实现,但注意:不是具现
{
…//dosomething
}
//---------------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这个符号的地址,于是连接器就能够完成任务。
}
关键是:在分离式编译的环境下,编译器编译某一个.cpp文件时并不知道另一个.cpp文件的存在,也不会去查找[当遇到未决符号时它会寄希望于连接器]。这种模式在没有模板的情况下运行良好,但遇到模板时就傻眼了,因为模板仅在需要的时候才会具现化出来,所以,当编译器只看到模板的声明时,它不能具现化该模板,只能创建一个具有外部连接的符号并期待连接器能够将符号的地址决议出来。
然而当实现该模板的.cpp文件中没有用到模板的具现体时,编译器懒得去具现,所以,整个工程的.obj中就找不到一行模板具现体的二进制代码,于是连接器也傻眼了!
换句话说 模板类 不能同其他类一样生成obj,它只能附属到调用它的CPP编译单元去具体化产生二进制代码。我想这个二进制代码属于具体化它的cpp的obj里面的。
考虑用模板实现单例.在不同的库,静态,动态中.
关于模板的分离式编译可以在定义模板的.cpp文件中的函数前加上export,即:
//---------------test.cpp-------------//
#include”test.h”
export template<class T>
void A<T>::f() //模板的实现,但注意:不是具现 { …//do something }不过很遗憾,一般的编辑器不支持export
C++编译器不支持export是有充足的理由的,这个特性很可能会从C++标准里消失,你可以参考C++标准提案之一:-)里面详细解释了这个特性:-)
Thinking in C++第一版15章P300头文件甚至是在定义非内联函数时,模板的头文件中也会放置所有的声明和定义。这似乎违背了通常的头文件规则:“不要在分配存储空间前放置任何东西”,这条规则是为了防止在连接时的多重定义错误。但模板定义很特殊。由t e m p l a t e <>处理的任何东西都意味着编译器在当时不为它分配存储空间,它一直处于等待状态直到被一个模板实例告知。在编译器和连接器的某一处,有一机制能<br>去掉指定模板的多重定义。所以为了容易使用,几乎总是在头文件中放置全部的模板声明和定义。有时,也可能为了满足特殊的需要(例如,强制模板实例仅存在于一简单的Windows DLL文件中)而要在一个独立的C P P文件中放置模板的定义。大多数编译器有一些机制允许这么做,那么我们就必须检查我们特定的编译器说明文档以便使用它。
- 为什么C++编译器不能支持对模板的分离式编译 整理
- 为什么C++编译器不能支持对模板的分离式编译 (精华编译原理)
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译?
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译_刘未鹏
- 为什么C++编译器不能支持对模板的分离式编译
- 为什么C++编译器不能支持对模板的分离式编译
- Jabber -- 著名的Linux即时通讯服务服务器
- 使用xmanager3.0 远程桌面管理redhat 5
- vs2010 未能加载类型
- 设计模式之建造者模型
- 数据绑定(七)使用ObjectDataProvider对象作为Binding的Source
- 为什么C++编译器不能支持对模板的分离式编译 整理
- 移动开发的那些痛
- Tomcat连接池,以及 Webservice配置,以及log4j日志输出
- ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
- LINUX学习专题——alias,unalias使用,命令DIY
- jxl去掉excel有效性验证
- dxBarManagerToDxNavBar方法
- 在WPF中开始Async的学习
- Qt在Linux下无法debug解决方法