c++ - 'inline'的优缺点

Question

首先，我想陈述一下我所知道的关于“内联”的事实，这样您就不必费心去重述它们了。

1. 内联函数是一种特殊的函数，其定义必须在使用该函数的每个翻译单元中可用。
2. 这是对编译器的提示(它可以随意忽略)忽略函数调用，并展开主体而不是调用。
3. 我所知道的唯一优点是 (2.) 可以使代码更快。
4. 我知道的唯一缺点是 (1.) 增加了不好的耦合。

现在让我们考虑模板。如果我有一个模板库，我需要在每个翻译单元中提供功能模板的定义，对吗？让我们暂时忘掉有争议的“导出”，因为它并没有真正解决问题。所以，我得出的结论是，没有理由不将模板函数制作成内联的，因为我所知道的内联的唯一缺点是先验。

如有错误请指正。提前致谢。

Answer 1

The only pro I know of is that (2.) may make the code faster.

可能 是关键词。是的，内联函数可能使某些代码路径更快。

但是内联函数会给大多数现代 CPU 上的指令缓存带来额外压力。如果您的函数太大而无法放入 L1 指令缓存，它可能实际上运行比执行函数调用慢(CPU 可以通过预取函数和它的返回站点)。

内联函数还可能对 L2 缓存造成过度压力 - 如果内联函数使用次数异常多，额外的代码大小会增加缓存未命中的可能性，导致长时间延迟和流水线停顿，因为CPU 在等待内存总线做某事。

inline 远非 Elixir 。具有积极优化的编译器将完全忽略 inline 提示，因为它们将根据代码大小或分支的存在等启发式方法选择要内联的函数，而不管 是否存在内联关键字。

The only con I know if is that (1.) increases coupling which is bad.

这是我从未听说过的。 “耦合”是我只在描述代码的高级关系时才听说过的一个概念。这更多是代码的可维护性和通用性问题。 inline 是低级代码生成的问题。

同样，对于模板，如果其启发式方法显示出这样做的优势，积极优化的编译器将内联。

但是，有一个链接级别的问题需要考虑:您可能需要声明一个函数或模板 inline(或 static，视情况而定)为了在链接时消除重复符号或限制符号可见性。这当然不是优化。

总而言之，除非特别需要，否则不要费心使用 inline 关键字。