C++模板为什么不支持分离编译?

C++模板为什么不支持分离编译?




首先,一个编译单元(translation unit)是指一个.cpp文件以及它所#include的所有.h文件,.h文件里的代码将会被扩展到包含它的

.cpp文件里,然编译器编译该.cpp文件为一个.obj文件(假定我们的平台是win32),后者拥有PE(Portable Executable,即windows

可执行文件)文件格式,并且本身包含的就已经是二进制码,但是不一定能够执行,因为并不保证其中一定有main函数。当编译器将一

工程里的所有.cpp文件以分离的方式编译完毕后,再由连接器(linker)进行连接成为一个.exe文件.


举个例子:


    
    
  1. //----- test.h -----//
  2. void f(); //这里声明一个函数f
  3. // ----- test.cpp -----//
  4. #include"test.h"
  5. void f()
  6. {
  7. //do something.
  8. } //这里实现出test.h当中生命的f函数.
  9. // ----- main.cpp -------//
  10. #include"test.h"
  11. int main()
  12. {
  13. f(); //调用f,f具有外部连接类型.
  14. }

在这个例子中,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函

扫描二维码关注公众号,回复: 4894372 查看本文章

数的哪怕一行二进制代码,而这些代码实际存在于test.cpp所编译成的test.obj当中. 在main.obj中对f的调用只会生成一行call指令,

像这样:


call f[C++中的这个名字当然是经过mangjing处理过的]


在编译时,这个call指令显然是错误的,因为main.obj中并无一行f的实现代码 那怎么办? 这就是连接器的作用了,连接器负责在它

的.obj当中(test.obj)寻找f的,找到以后将call f这个指令的调用地址换成实际的f的函数进入点地址.需要注意的是: 连接器实

际上将工程里的.obj"连接"成了一个.exe文件,而它最关键的任务就是上面说的,寻找一个外部连接符号在另一个.obj中的地址,然

后替换原来的"虚假"地址.    关键就在于:


编译main.cpp的时候,编译器不知道f的实现,所以当碰到对它的调用时,只是给出一个指示,指示连接器应该为它寻找f的实现体. 这

也就是说main.obj中没有关于f的任何一行二进制代码. 


然后编译test.cpp的时候,编译器找到了f的实现. 于是乎f的实现出现在了test,obj当中.


连接时,连接器在test.obj中找到f的实现代码(二进制)的地址(通过符号导出表). 然后将main.obj中悬而未决的call xxx地址改为f实

际的地址.完成好,我们再来看模板的情况: 首先我们应该知道模板函数的代码其实并不能直接编译成二进制代码.其中要有一个"实例

化"的过程:



    
    
  1. //-------------test.h----------------//
  2. template< class T>
  3. class A
  4. {
  5. public:
  6. void f(); // 这里只是个声明
  7. };
  8. //---------------test.cpp-------------//
  9. #include”test.h"
  10. template<class T>
  11. void A<T>::f() // 模板的实现
  12. {
  13. …//do something
  14. }
  15. //---------------main.cpp---------------//
  16. #include”test.h”
  17. int main()
  18. {
  19. A<int> a;
  20. f(); // #1
  21. }

器编译器在#1处被并不知道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中就找不到一行模板实例的二进制代码,于是连接器也没有办法了. 他只能无奈的报错

C++模板为什么不支持分离编译?




首先,一个编译单元(translation unit)是指一个.cpp文件以及它所#include的所有.h文件,.h文件里的代码将会被扩展到包含它的

.cpp文件里,然编译器编译该.cpp文件为一个.obj文件(假定我们的平台是win32),后者拥有PE(Portable Executable,即windows

可执行文件)文件格式,并且本身包含的就已经是二进制码,但是不一定能够执行,因为并不保证其中一定有main函数。当编译器将一

工程里的所有.cpp文件以分离的方式编译完毕后,再由连接器(linker)进行连接成为一个.exe文件.


举个例子:


  
  
  1. //----- test.h -----//
  2. void f(); //这里声明一个函数f
  3. // ----- test.cpp -----//
  4. #include"test.h"
  5. void f()
  6. {
  7. //do something.
  8. } //这里实现出test.h当中生命的f函数.
  9. // ----- main.cpp -------//
  10. #include"test.h"
  11. int main()
  12. {
  13. f(); //调用f,f具有外部连接类型.
  14. }

在这个例子中,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++中的这个名字当然是经过mangjing处理过的]


在编译时,这个call指令显然是错误的,因为main.obj中并无一行f的实现代码 那怎么办? 这就是连接器的作用了,连接器负责在它

的.obj当中(test.obj)寻找f的,找到以后将call f这个指令的调用地址换成实际的f的函数进入点地址.需要注意的是: 连接器实

际上将工程里的.obj"连接"成了一个.exe文件,而它最关键的任务就是上面说的,寻找一个外部连接符号在另一个.obj中的地址,然

后替换原来的"虚假"地址.    关键就在于:


编译main.cpp的时候,编译器不知道f的实现,所以当碰到对它的调用时,只是给出一个指示,指示连接器应该为它寻找f的实现体. 这

也就是说main.obj中没有关于f的任何一行二进制代码. 


然后编译test.cpp的时候,编译器找到了f的实现. 于是乎f的实现出现在了test,obj当中.


连接时,连接器在test.obj中找到f的实现代码(二进制)的地址(通过符号导出表). 然后将main.obj中悬而未决的call xxx地址改为f实

际的地址.完成好,我们再来看模板的情况: 首先我们应该知道模板函数的代码其实并不能直接编译成二进制代码.其中要有一个"实例

化"的过程:



  
  
  1. //-------------test.h----------------//
  2. template< class T>
  3. class A
  4. {
  5. public:
  6. void f(); // 这里只是个声明
  7. };
  8. //---------------test.cpp-------------//
  9. #include”test.h"
  10. template<class T>
  11. void A<T>::f() // 模板的实现
  12. {
  13. …//do something
  14. }
  15. //---------------main.cpp---------------//
  16. #include”test.h”
  17. int main()
  18. {
  19. A<int> a;
  20. f(); // #1
  21. }

器编译器在#1处被并不知道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中就找不到一行模板实例的二进制代码,于是连接器也没有办法了. 他只能无奈的报错

猜你喜欢

转载自blog.csdn.net/Ferlan/article/details/86406568