关于这个pragma,有某文档: http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Interface.html 里面还有它的伴生pragma: #pragma implementation
大体意思是说,比如你有个A.h,有个A.cpp。A.h里面包含了一些除了类接口以外的一些东西,例如一部分类实现之类的,比方说,里面有类A,以及A::foo()的实现。
原来假如我是B.cpp,只要我#include你这个A.h,那我编译出来的B.o里面,就会有你的那一部分实现的副本,也就会有A::foo()的副本……
然后有人觉得这样B.o会变大,于是发明了那俩pragma……
定义了#pragma interface A 的头文件,引用它的B.cpp编译出来的B.o就不会包含那一部分实现的副本,而会有undefined symbol: undefined A::foo()
而与其对应的定义了#pragma implementation A的A.cpp,它编译出来的A.o里面,就会包含那一部分实现,也就是那些undefined symbol对应的东西: defined A::foo()
这样俩.o链接起来,就啥都有了,很好
=== bug的分隔线 ===
但是有时候有别的情况…… 例如其实那个类在一个C.so里面,而引用它的B.cpp是一个用了那个C.so的程序的一部分
于是B.cpp编译出来的B.o里面,那部分实现依旧是undefined symbol。但是,那些对应的symbol,在A.o和其他.o一起变成C.so的时候,都到了C.so里面。但是大概是由于链接的过程,原来的symbol信息没有导出来……
于是C.so的导出symbol里面,并没有defined A::foo()
于是B.cpp位于的那个程序在链接的时候,就找不到那个A::foo()了,就有linker error了……
=== 结论的分割线 ===
总的来说,就是尽可能别用这个pragma…… 省那点空间没啥意义的……
它文档里也说了
Note: As of GCC 2.7.2, these
#pragma
s are not useful in most cases
以及
Currently (3.4) the only benefit of these
#pragma
s is reduced duplication of debugging information, and that should be addressed soon on DWARF 2 targets with the use of COMDAT groups.