我已经搜索过并且无法验证GCC编译器在声明位于.h文件中且定义是否在.cpp文件中时如何处理内联getter和setter.
大多数人似乎都说GCC无法看到这些源文件的障碍,根本无法内联这些障碍,而其他人则不同意.我查看了文档,但我也找不到答案.我错过了吗？
我确实认识到内联是由编译器做出的选择并不总能得到保证,但假设最佳情况,至少可能吗？
(你真正要问的是关于定义.cpp与你当前正在编译的文件不同的文件,然后在以后链接的情况.编译器不关心.hpp或者.cpp关于翻译单元.)
无论如何,在http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html上,向下滚动到"flno":
此选项运行标准链接时优化程序.[...]前两次调用GCC会将GIMPLE的字节码表示保存到foo.o和bar.o中的特殊ELF部分.最后的调用将从foo.o和bar.o读取GIMPLE字节码,将两个文件合并为一个内部图像,并照常编译结果.由于foo.o和bar.o都合并为一个图像,因此这会导致GCC中的所有过程间分析和优化跨两个文件一起工作,就像它们是单个文件一样.这意味着,例如,内联器将能够将bar.o中的函数内联到foo.o中的函数中,反之亦然.
所以,是的,可以跨模块边界优化内联.
但是,C++仍然要求:
内联函数应在每个使用它的翻译单元中定义.[3.2/3,C++ 03]
所以实际上如果你使用了关键字,你可能不会编写代码来利用这个inline; 相反,如果它看起来合适,你依赖链接器"只是决定"内联你的函数.因此,这不是允许您移动代码的选项.
请记住,inline在代码中写入与实际实际内联的函数没有一对一的关系; 它只是对编译器(或链接器,如果您启用了上述链接时优化)的提示.