使用内联函数有什么问题？

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

内联函数有什么缺点吗？

结论:

显然,使用内联函数没有任何问题.

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

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

随着函数大小的增加,内联函数的速度优势趋于减小.在某些时候,与函数体的执行相比,函数调用的开销变小,并且失去了好处- Source

内联函数可能无法正常工作的情况很少:

对于返回值的函数; 如果存在return语句.

对于不返回任何值的函数; 如果存在循环,开关或goto语句.

如果函数是递归的.-资源

__inline仅当指定optimize选项时,关键字才会使函数内联.如果指定了optimize,则是否__inline遵循优先级取决于内联优化程序选项的设置.默认情况下,只要运行优化程序,内联选项就会生效.如果指定optimize,则还必须指定noinline选项(如果要__inline忽略关键字).-资源

Alan.. 21

值得指出的是,inline关键字实际上只是对编译器的一个提示.编译器可以忽略内联并简单地为某个地方的函数生成代码.

内联函数的主要缺点是它可以增加可执行文件的大小(取决于实例化的数量).这在某些平台(例如嵌入式系统)上可能是一个问题,特别是如果函数本身是递归的.

我还建议将内联函数设置得非常小 - 随着函数大小的增加,内联函数的速度优势会逐渐减弱.在某些时候,与函数体的执行相比,函数调用的开销变小,并且失去了益处.

值得指出的是,inline关键字实际上只是对编译器的一个提示.编译器可以忽略内联并简单地为某个地方的函数生成代码.

内联函数的主要缺点是它可以增加可执行文件的大小(取决于实例化的数量).这在某些平台(例如嵌入式系统)上可能是一个问题,特别是如果函数本身是递归的.

我还建议将内联函数设置得非常小 - 随着函数大小的增加,内联函数的速度优势会逐渐减弱.在某些时候,与函数体的执行相比,函数调用的开销变小,并且失去了益处.

它可能会增加可执行文件的大小,我不认为即使你使用了inline关键字,编译器也总是会实际内联它们.(或者是另一种方式,就像Vaibhav 所说的那样？......)

我认为如果函数只有1或2个语句通常都可以.

编辑:这是linux CodingStyle文档所说的内容:

第15章:内联疾病

似乎有一种常见的误解,即gcc有一个神奇的"让我更快"的加速选项称为"内联".虽然使用内联可能是合适的(例如,作为替换宏的一种方法,请参阅第12章),但通常不是.大量使用内联关键字会导致更大的内核,从而导致整个系统整体运行速度变慢,因为CPU的icache占用空间更大,而且因为页面缓存的可用内存更少.考虑一下; 页面缓存未命中导致磁盘搜索,这很容易花费5毫秒.有很多cpu周期可以进入这5毫秒.

一个合理的经验法则是不要将内联函数放在其中包含超过3行代码的函数中.此规则的一个例外是已知参数是编译时常量的情况,并且由于此常量,您知道编译器将能够在编译时优化大部分函数.有关后一种情况的一个很好的示例,请参阅kmalloc()内联函数.

通常人们争辩说,将内联添加到静态且仅使用一次的函数总是一个胜利,因为没有空间权衡.虽然这在技术上是正确的,但gcc能够在没有帮助的情况下自动内联这些内容,并且当第二个用户出现时删除内联的维护问题超过了告诉gcc无论如何都要做的事情的暗示的潜在价值.