我知道您可以使用 inline 关键字，或者只是将方法放在类声明中，比如短 ctor 或 getter 方法，但是编译器是否会最终决定何时内联我的方法？
例如：
inline void Foo::vLongBar()
{
//several function calls and lines of code
}
如果编译器认为它会使我的代码效率低下，它会忽略我的内联声明吗？
作为一个附带问题，如果我在我的类之外声明了一个 getter 方法，如下所示：
void Foo::bar() { std::cout << "baz"; }
编译器会在幕后内联吗？
【问题讨论】：
标签： c++ compiler-theory compiler-optimization
是的，是否内联代码的最终决定权在于 C++ 编译器。 inline 关键字是一个建议，而不是要求。
以下是有关如何在 Microsoft C++ 编译器中处理此决定的一些详细信息
【讨论】：
__forceinline 在 VC++ 中。这仍然不允许您内联不可能内联的函数，但否则它将覆盖编译器的成本/收益分析。
最终，函数是否内联完全取决于 编译器。通常，函数在流程方面越复杂，编译器内联它的可能性就越小。并且某些函数（例如递归函数）根本无法内联。
不内联函数的主要原因是它会大大增加代码的整体大小，从而阻止 iot 被保存在处理器的缓存中。这实际上是一种悲观，而不是一种优化。
至于让程序员决定在脚上或其他地方开枪，您可以自己内联函数 - 在函数的调用站点编写本应进入函数的代码。
【讨论】：
正如许多人已经发布的那样，最终决定始终取决于编译器，即使您可以给出诸如 forceinline 之类的坚定提示。
部分理由是内联不是自动的“更快”开关。过多的内联会使您的代码变得更大，并且可能会干扰其他优化。见The C++ FAQ Lite about inline functions and performance。
【讨论】：
正如其他人所指出的，inline 关键字只是对编译器内联代码的建议。由于编译器通常会内联未标记为inline 的代码，而不是具有标记的内联代码，因此该关键字似乎与register 或（C++0x 之前的）auto 一样多余。
然而，inline 关键字还影响了另一件事：它将函数的 链接 从 external（函数的默认值）更改为 内联。内联链接允许每个编译单元包含它自己的目标代码副本，并让链接器从最终的可执行文件中删除冗余副本。如果这让您想起模板，是的，模板也使用内联链接。
【讨论】：
是的，编译器拥有最终决定权。 In VS you can even inline recursive functions into specified depth ;)
#pragma inline_depth( [0... 255] )
【讨论】：
只是为了加我的 5 美分 ...
我发现这篇关于内联的Guru of Week 文章非常有用。
据我所知，我在某处读到，当链接器链接目标文件并发现被链接的代码可以被内联时，即使是链接器也可能进行内联。
【讨论】：
作为一个附带问题，如果我在我的类之外声明了一个 getter 方法，如下所示：
void Foo::bar() { std::cout << "baz"; }
编译器会在幕后内联吗？
这取决于。它可以用于同一翻译单元中的所有调用者（.cpp 文件及其所有 #included 定义）。但它仍然必须编译非内联版本，因为在翻译单元之外可能有该函数的调用者。您可能会在高优化级别上看到这一点（如果您的编译器确实可以做到的话）。 （特别是：比较将所有 .cpp 文件#include 到一个 .cpp 与典型布局时发生的情况。在一个翻译单元中使用所有定义，这种内联的机会显着增加。）
【讨论】：
inline 是最大的一个，但是 .h 和 .cpp 中的区别，static 的含义，模板可以放在哪里......这些都出现了。不幸的是，如果您对 C++ 没有基本的了解，那么链接真的会让您陷入困境。
据我所知，如果编译器发现 for、while 等循环，它会自动将您声明为内联（或在类声明中编写）的函数设为非内联。 这是编译器在内联函数中拥有最后发言权的一个示例。
【讨论】：
如果您确实、肯定、绝对地需要内联代码，那么总会有宏。 C 多年来一直支持这些，因为它们只是在编译之前的文本替换，它们真的，真的，内联你写的任何东西。
这就是为什么 'inline' 关键字（甚至在某些情况下是强制变体）可以承受没有强制它的标准方式的原因 - 你总是可以只写一个宏。
也就是说，inline 关键字通常更好，因为编译器通常知道将函数内联是否有意义，并且内联可以与编译器的其余优化交互。
【讨论】：