C: inline 关键字值得吗？答案

【问题标题】：C: Is the inline keyword worth it?C: inline 关键字值得吗？
【发布时间】：2011-04-08 16:56:50
【问题描述】：

是否值得使用 inline 关键字，或者编译器足够聪明，知道何时需要内联函数？

【问题讨论】：

一句不值得回答：如果您不打算从它所在的编译单元外部使用该函数，则关键字“static”比“inline”对编译器的帮助更大。例如，如果只有一个调用站点，编译器就可以内联，而不管大小。

标签： c performance inline

【解决方案1】：

编译器非常聪明，并且有多个指标来确定是否值得内联。但是，有时开发人员会知道应用程序将如何运行，并且会知道内联编译器不会自动执行的操作。但是，除非我做了一些基准测试并发现内联可以提高我的性能，否则我永远不会手动内联内容。

你可以阅读更多关于GCC uses inline的信息。

【讨论】：

编译器处理的方式还是一样吗？

【解决方案2】：

明确意图总是值得的。

同样值得注意的是，如果编译器认为它更好，它甚至不需要内联。

【讨论】：

【解决方案3】：

是的，它足够聪明。但在过去的 40 年里，完全没有进步的是 C 程序的构建方式。它仍然是一次一个源代码文件。

因此，要将函数内联到多个 .c 文件中，请将函数定义放入 .h 文件中。如果你不将它们标记为内联，链接器会抱怨多个定义。

【讨论】：

+1, inline 现在的意思是“允许多个定义”。事实上，它也是对编译器“快速调用这个函数”的一个提示，这是一个不相关且不相关的副作用:-)我认为并不是“程序的构建方式”没有进步——一些编译器/链接器有。但是标准允许的最低公分母并没有提高。
说inline 意味着“允许多个定义”是完全错误的。这个问题是关于 C 语言，而不是 C++。 C 没有extern inline 函数，没有inline 关键字是无效的static，并且一个函数的多个定义是不允许的。

【解决方案4】：

标准说

7.1.2 函数说明符

2。带有 inline 说明符的函数声明（8.3.5、9.3、11.4）声明了一个内联函数。 inline 说明符向实现表明，在调用点对函数体进行内联替换优于通常的函数调用机制。在调用点执行此内联替换不需要实现；但是，即使省略了这个内联替换，7.1.2 中定义的内联函数的其他规则仍应遵守。

所以我将inline 比作HTML 中的<br /> —— 始终使用自动关闭<br /> 是一个好习惯。但有人可能会争辩说，几乎所有浏览器实现对待<br> 和<br /> 完全相同，IMO 没有抓住重点。

正如其他人所指出的，这可能与如今的性能价值不太相关。但我认为它仍然可以很好地用作语义、传达意图的关键字。

【讨论】：