问题标签 [inline-functions]

虽然在某些情况下使用内联函数会非常方便，

内联函数有什么缺点吗？

结论：

显然，使用内联函数并没有错。

但值得注意的是以下几点！

• 过度使用内联实际上会使程序变慢。根据函数的大小，内联它可能会导致代码大小增加或减少。内联非常小的访问器函数通常会减少代码大小，而内联非常大的函数会显着增加代码大小。在现代处理器上，由于更好地使用指令缓存，较小的代码通常运行得更快。- 谷歌指南

• 随着函数大小的增长，内联函数的速度优势趋于减弱。在某些时候，函数调用的开销与函数体的执行相比变得很小，并且失去了好处- 来源

• 在少数情况下内联函数可能不起作用：

  • 对于返回值的函数；如果存在 return 语句。
  • 对于不返回任何值的函数；如果存在循环、switch 或 goto 语句。
  • 如果函数是递归的。-来源

• 仅当您指定优化选项时，__inline关键字才会内联函数。如果指定了优化，是否__inline兑现取决于内联优化器选项的设置。默认情况下，只要运行优化器，内联选项就会生效。如果您指定 optimize ，如果您希望__inline关键字被忽略，则还必须指定 noinline 选项。-来源

以下代码有什么不同：

这两个函数都会被内联吗？内联实际上有什么不同吗？关于何时应该或不应该内联代码是否有任何规则？我经常使用AnotherFunc语法（例如访问器），但很少inline直接指定。

我是一名 C/C++ 开发人员，这里有几个问题一直困扰着我。

• “常规”代码和内联代码之间有很大区别吗？
• 主要区别是什么？
• 内联代码只是宏的“形式”吗？
• 选择内联代码时必须做什么样的权衡？

谢谢

在 C++ 中使用内联函数的优点/缺点是什么？我看到它只会提高编译器输出的代码的性能，但是对于今天优化的编译器、快速的 CPU、巨大的内存等（不像 1980 年那样，内存稀缺，所有东西都必须适合 100KB 的内存）什么他们今天真的有优势吗？

Visual Studio 包括对 __forceinline 的支持。Microsoft Visual Studio 2005 文档指出：

__forceinline 关键字覆盖了成本/收益分析，而是依赖于程序员的判断。

这就提出了一个问题：编译器的成本/收益分析什么时候出错了？而且，我怎么知道这是错的？

在什么情况下假设我在这个问题上比我的编译器更了解？

见标题：C++ 函数内联意味着什么？

我有一个在头文件中声明和定义的函数。这本身就是一个问题。当该函数未内联时，使用该标题的每个翻译单元都会获得该函数的副本，并且当它们链接在一起时，就会出现重复。我通过使函数内联来“修复”该问题，但恐怕这是一个脆弱的解决方案，因为据我所知，即使您指定了“内联”关键字，编译器也不保证内联。如果这不是真的，请纠正我。

无论如何，真正的问题是，这个函数中的静态变量会发生什么？我最终得到多少份？

我知道这inline本身就是对编译器的建议，它可能会或可能不会内联函数，它也会产生可链接的目标代码。

我认为这样static inline做是一样的（可能是内联的，也可能不是内联的），但在内联时不会产生可链接的目标代码（因为没有其他模块可以链接到它）。

哪里extern inline适合图片？

假设我想用一个内联函数替换一个预处理器宏，并要求这个函数被内联（例如，因为它使用__FILE__and__LINE__宏，应该为调用者而不是这个被调用函数解析）。也就是说，如果函数没有内联，我想查看编译器或链接器错误。这样做extern inline吗？（我认为，如果没有，除了坚持使用宏之外，没有其他方法可以实现这种行为。）

C++ 和 C 之间有区别吗？

不同的编译器供应商和版本之间是否存在差异？

我经常在 C++ 中遇到大型的非模板类，其中简单方法直接在头文件的类主体中定义，而不是在实现文件中单独定义。例如：

为什么要这样做？好像有缺点。实现没有应有的隐藏，代码可读性较差，如果类的头文件包含在许多不同的地方，也会增加编译器的负担。

我的猜测是人们打算将这些函数内联到其他模块中，这可以显着提高性能。但是，我听说较新的编译器可以在跨模块的链接时进行内联（和其他过程间优化）。对这种链接时优化的支持有多广泛，它实际上是否使这些定义变得不必要？这些定义还有其他充分的理由吗？

我将 VB6 用于应用程序。

是否可以强制编译器内联函数？

或者有没有实现相同功能的插件？

我的代码中有一个安全部分，我想让它难以破解，方法是在使用它的每个点重复代码，而不是作为函数列出一次。

希望有人能回答我的问题！