我通常遵循一个拇指规则，我用3-4个简单的语句作为内联函数。但最好记住，这只是给编译器的一个提示。最终是否使它内联的调用仅由编译器执行。如果有超过这些语句，我不会用一个愚蠢的编译器进行内联声明，这可能会导致代码膨胀。

最好的方法是分析你的程序，把那些被多次调用并消耗CPU周期的小函数标记为内联函数。这里的关键字是“小”——一旦函数调用开销与函数中花费的时间相比可以忽略不计，那么内联它们就没有意义了。

我建议的另一种用法是，如果你有一些小函数在性能关键代码中经常被调用，以至于缓存不相关，你可能也应该内联这些函数。同样，这也是侧写师应该能够告诉你的。

过早的优化是万恶之源!

根据经验，我通常只内联“getter”和“setter”。一旦代码可以工作并且稳定，分析就可以显示哪些函数可以从内联中受益。

另一方面，大多数现代编译器都有很好的优化算法，并且会内联您应该内联的内容。

推理——编写内联单行函数，以后再考虑其他函数。

内联与优化关系很小。内联是给编译器的指令，如果给定的函数定义在程序中多次出现，则不会产生错误，并承诺该定义将出现在使用它的每次翻译中，并且在出现它的任何地方都具有完全相同的定义。

根据上述规则，内联适用于短函数，其函数体不需要包含超出声明所需的额外依赖项。每次遇到定义时，都必须对其进行解析，并可能生成其主体的代码，因此对于在单个源文件中只定义一次的函数，这意味着一些编译器开销。

编译器可以内联(即用执行该函数操作的代码替换对函数的调用)它选择的任何函数调用。过去的情况是，它“显然”不能内联一个没有在同一个翻译单元中声明的函数，但随着链接时间优化的使用越来越多，现在这种情况也不存在了。同样正确的是，标记为内联的函数可能不是内联的。

最好的方法是检查和比较生成的内联和非内联指令。但是，省略内联总是安全的。使用内联可能会导致您不想要的麻烦。

告诉编译器内联函数是一种优化，而最重要的优化规则是过早的优化是万恶之源。始终写清晰的代码(使用高效的算法)，然后分析你的程序，只优化那些花费太长时间的函数。

如果您发现一个特定的函数非常简短，并且在一个紧凑的内部循环中被调用了数万次，那么它可能是一个很好的候选者。

不过，您可能会感到惊讶——许多c++编译器会自动为您内联小函数——而且它们可能也会忽略您的内联请求。