首先，如果某个test.h里有如下内容： class A { public: int x(); } int A::x() { }class A { public: int x(); } int A::x() { } 那如果只有一个test.cpp引用了它： #include "test.h" int main() { A a; a.x(); }#include "test.h" int main() { A a; a.x(); } 那还好。但如果还有一个test2.cpp引用了它： #include "test.h" int foo() { A a; a.x(); }#include "test.h" int …
关于这个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 #pragmas are not useful in most cases 以及 Currently (3.4) the only benefit of …