在决定是否使用内联时，我通常记住以下想法:在现代机器上，内存延迟可能是比原始计算更大的瓶颈。众所周知，经常调用的内联函数会增加可执行文件的大小。此外，这样的函数可以存储在CPU的代码缓存中，当需要访问代码时，这将减少缓存失败的数量。

因此，您必须自己决定:内联是否会增加或减少生成的机器代码的大小?调用该函数会导致缓存丢失的可能性有多大?如果它遍布整个代码，那么我认为可能性很高。如果它被限制在一个单一的紧密循环，那么可能性很低。

我通常使用内联的情况下，我列出如下。然而，当您真正关心性能时，概要分析是必不可少的。此外，您可能希望检查编译器是否真的接受了提示。

在紧密循环中调用的简短例程。 非常基本的访问器(get / set)和包装器函数。 不幸的是，头文件中的模板代码会自动获得内联提示。 像宏一样使用的短代码。(例如min() / max()) 简短的数学程序。

过早的优化是万恶之源!

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

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

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

避免函数调用的开销只是故事的一半。

do:

使用inline代替#define 非常小的函数适合内联:更快的代码和更小的可执行文件(更多的机会留在代码缓存中) 这个函数很小，并且经常被调用

别:

large functions: leads to larger executables, which significantly impairs performance regardless of the faster execution that results from the calling overhead inline functions that are I/O bound the function is seldom used constructors and destructors: even when empty, the compiler generates code for them breaking binary compatibility when developing libraries: inline an existing function change an inline function or make an inline function non-inline: prior version of the library call the old implementation

在开发一个库的时候，为了让一个类将来可以扩展，你应该:

即使主体为空，也要添加非内联虚析构函数 使所有构造函数都是非内联的 除非类不能按值复制，否则编写复制构造函数和赋值操作符的非内联实现

记住，inline关键字是给编译器的一个提示:编译器可能决定不内联某个函数，也可能决定内联那些一开始就没有标记为内联的函数。我通常避免将函数标记为内联(可能在编写非常非常小的函数时分开)。

关于性能，明智的方法(一如既往)是分析应用程序，然后最终内联一组表示瓶颈的函数。

引用:

内联还是不内联 [9]内联函数 c++的策略/二进制兼容性问题 GotW #33:内联 内联回来的 有效的c++ -项目33:明智地使用内联

编辑:Bjarne Stroustrup, c++编程语言:

函数可以定义为内联的。例如:

inline int fac(int n)
{
  return (n < 2) ? 1 : n * fac(n-1);
}

The inline specifier is a hint to the compiler that it should attempt to generate code for a call of fac() inline rather than laying down the code for the function once and then calling through the usual function call mechanism. A clever compiler can generate the constant 720 for a call fac(6). The possibility of mutually recursive inline functions, inline functions that recurse or not depending on input, etc., makes it impossible to guarantee that every call of an inline function is actually inlined. The degree of cleverness of a compiler cannot be legislated, so one compiler might generate 720, another 6 * fac(5), and yet another an un-inlined call fac(6). To make inlining possible in the absence of unusually clever compilation and linking facilities, the definition–and not just the declaration–of an inline function must be in scope (§9.2). An inline especifier does not affect the semantics of a function. In particular, an inline function still has a unique address and so has static variables (§7.1.2) of an inline function.

EDIT2: ISO-IEC 14882-1998, 7.1.2功能说明

使用内联说明符的函数声明(8.3.5,9.3,11.4)声明了一个内联函数。内联说明符向实现指示，在调用点对函数体进行内联替换将优先于通常的函数调用机制。实现不需要在调用点执行这种内联替换;然而，即使省略了这个内联替换，7.1.2中定义的内联函数的其他规则仍应遵守。

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

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

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

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

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

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