我对C中的内联函数有疑问.我知道类似的问题多次出现在此.我希望我的有点不同.

我知道当你指定一些内联函数时,它只是编译器的“建议”.以防万一：

inline int func1()
{
    return 2;
}

Some code later

cout << func1() << endl; // replaced by cout << 2 << endl;

所以那里没有神秘感,但是这样的情况呢：

inline int func1()
{
    return 2;
}

inline int func2()
{
    return func1() * 2;
}

inline int func3()
{
    return func2() * func1() * 2;
}

And so on…

哪些函数有机会内联,是否有益以及如何检查编译器实际执行的操作？

解决方法:

Which of these functions have a chance to become inlined

如果执行内联的工具(1)可以访问函数的定义(= body),那么任何和所有函数都有机会被内联…

is it benefitial

……并认为这样做是有益的.如今,优化器的工作是确定内联在哪里是有意义的,对于99.9％的程序,程序员可以做的最好的事情就是远离优化器的方式.剩下的几个案例是像Facebook这样的程序,其中0.3％的性能损失是一个巨大的倒退.在这种情况下,手动调整优化(以及分析,分析和分析)是可行的方法.

how to check what compiler actually did

通过检查生成的组件.每个编译器都有一个标志,使其以“人类可读”的格式输出汇编,而不是(或除了)二进制形式的目标文件.

(1)通常,此工具是编译器,并且内联在编译步骤中发生(将源代码转换为汇编/目标文件).这也是为什么你可能需要使用inline关键字来实际允许编译器内联的唯一原因：因为函数的定义必须在正在编译的转换单元(=源文件)中可见,并且通常这意味着放置函数定义到头文件中.如果没有内联,如果头文件包含在多个翻译单元中,则会导致多重定义错误.

请注意,编译不是可以进行内联的唯一阶段.启用整体程序优化(也称为链接时代码生成)时,一旦创建了所有目标文件,就会在链接时再发生一次优化.此时,内联关键字完全无关紧要,因为链接可以访问所有函数定义(否则二进制文件不会成功链接).因此,这是从内联中获得最大收益的方法,而不必在编写代码时考虑它.缺点是时间：WPO需要时间来运行,对于大型项目,可能会将链接时间延长到不可接受的水平(我个人经历了一个有点病态的情况,即启用WPO将程序的链接时间从7分钟缩短到46分钟).