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

The __forceinline keyword overrides
  the cost/benefit analysis and relies
  on the judgment of the programmer
  instead.

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

在哪种情况下，假定我比我的编译器对此问题了解更多？

解决方案

确保的唯一方法是在有无情况下衡量性能。除非我们正在编写对性能要求很高的代码，否则通常是不必要的。

仅当概要分析数据告诉我们时，我们才比编译器更了解。

在几种情况下，编译器无法分类确定内联函数是否适当或者有益。内联可能涉及编译器不愿进行的折衷，但是我们却需要这样做(例如，代码膨胀)。

通常，现代编译器实际上很擅长做出此决定。

编译器基于静态代码分析来做出决策，而如果我们按照don所说的那样进行分析，则我们正在进行的动态分析可能会涉及到更深的范围。特定代码段的调用次数通常在很大程度上取决于使用它的上下文，例如数据。对一组典型的用例进行概要分析可以做到这一点。我个人通过在自动回归测试中启用概要分析来收集此信息。除了强制内联之外，我还展开了循环，并根据这些数据进行了其他手动优化，以达到良好的效果。之后也必须再次进行概要分析，因为有时最大努力实际上可能导致性能下降。再者，自动化使痛苦减轻了很多。

以我的经验，与通常的代码优化相比，调整alogorithms往往会获得更好的效果。

我已经为有限资源的设备开发了9年左右的软件，而我唯一见过需要使用__forceinline的情况是一个紧密的循环，其中相机驱动程序需要将像素数据从捕获缓冲区复制到相机中。设备屏幕。在那里，我们可以清楚地看到，特定函数调用的成本确实降低了覆盖图的性能。

我正在使用的一个地方是许可证验证。

防止轻松破解的一个重要因素是，要验证是否在多个地方而不只是一个地方获得许可，并且我们不希望这些地方成为同一函数调用。

*)请不要在讨论中知道我可以破解所有内容。同样，仅此一点并没有多大帮助。

当用于以下功能时，内联指令将完全没有用：

递归的
长，
由循环组成

如果要使用__forceinline强制执行此决定