我已经搜索过，并且无法验证GCC编译器在声明位于.h文件中且定义是否在.cpp文件中时如何处理内联getter和setter。
大多数人似乎都说GCC无法看到这些源文件的障碍，根本无法内联这些障碍，而其他人不同意。我查看了文档，但我也找不到答案。我错过了吗？
我确实认识到内联是编译器做出的选择并不总能得到保证，但假设最佳情况，至少可能吗？
答案 0 :(得分：5)
（你真正想要问的是这个定义与你当前正在编译的文件不同的.cpp文件，然后在以后链接的情况。编译器不关心{ {1}}或.hpp，但约为translation units。）
无论如何，在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]
因此，如果您使用.cpp关键字，可能不会编写代码以利用此功能;相反，如果它看起来合适，你依赖链接器“只是决定”内联你的函数。因此，这不是允许您移动代码的选项。
请记住，在代码中编写inline与函数实际实际上内联并没有一对一的关系;它只是对编译器（或链接器，如果你打开了上面提到的链接时优化）的提示。
答案 1 :(得分：0)
1 /声明内联的函数必须在所有使用它们的编译单元中定义。
2 /假设正确的参数，gcc将始终能够内联函数，只要它看到定义，它们不需要内联声明。 （但是将它们声明为内联将有助于在所有编译单元中提供定义，并且您可能需要更高级别的优化以内联未声明为内联的函数。）
3 /最新版本的gcc可以进行链接时优化。 IIRC，链接时可能的优化之一是内联。