在inline specifier的cppreference页面上，它说，
当在函数的 decl-specifier-seq 中使用inline说明符时，说明符声明该函数为 * 内联函数 *。
- 内联函数 * 具有以下属性：
程序中可以有多个 inline function 的定义，只要每个定义出现在不同的翻译单元中，并且所有定义都相同。
...
然后，往下一点，它说，inline关键字的最初意图是向优化器指示函数的内联替换优先于函数调用。
除了这一行，没有引用inline的这种用法。inline的后一种含义在C++标准中仍然有效吗？或者后一种形式比前一种形式更不受欢迎吗？
如果后一种形式仍然有效，那么在现代编译器中是否值得使用它呢？我听说过，* 即使是编译器决定是否内联，使用inline关键字也会使它有点困难。* 这是真的吗？对于这种情况，我应该在程序中使用inline关键字吗？
2条答案
按热度按时间cyej8jka1#
该标准本身并不关心程序集是如何生成的，因此不能强制“内联”函数。
[dcl.inline]/2将此作为建议：...向实现指示首选在调用点对函数体进行内联替换...不需要实现来执行此内联替换...
This blog post表明GCC和Clang确实在一定程度上遵守了
inline提示。或者后一种形式比前一种形式更不受欢迎？
从
[dcl.inline]/2中可以看出，它不是。我原本想说他们不能否决它，因为他们不能强制它，但他们未能将他们的建议标记为“注意”（这将意味着它缺乏“标准化权力”），这在我看来像是编辑错误。
eqqqjvef2#
关键字
inline使得所有的翻译单元都可以访问函数的定义，这使得编译器更容易内联函数而不是调用它。所以，是的，它确实促进了内联，尽管它没有（也从来没有）强制要求内联。当你想内联函数时，你应该使用
inline关键字吗？也许不应该，因为你可能误解了它对性能的影响。注意，如果你打开链接时间优化，内联在主要编译器上的翻译单元之间仍然是可能的。所以我建议你这样做，剩下的留给编译器。还需要注意的是，许多编译器都有一些扩展，更强烈地建议编译器内联一个函数，比如GCC中的always_inline。如果你打算使用这些扩展，我建议你在前后分析你的代码，看看你是在帮助还是伤害你的代码的性能。