首先,我想陈述我所知道的"内联"事实,这样你就不用费心去重述它们了.
现在让我们考虑模板.如果我有一个模板库,我需要在每个翻译单元中提供功能模板的定义,对吧？让我们忘记有争议的"出口"一段时间,因为它无论如何都没有真正解决问题.所以,我得出一个结论,没有理由不将内联模板函数,因为我所知道的内联的唯一内容是先验的.
如果我错了,请纠正我.提前致谢.
gre*_*ade 11
我所知道的唯一专业是(2.)可以使代码更快.
可能是一个有效的词.内联函数可以使某些代码路径更快,是的.
但内联函数会给大多数现代CPU上的指令缓存带来额外压力.如果您的函数太大而无法放入L1指令高速缓存中,它实际上可能比执行函数调用运行得慢(CPU可以通过预取函数及其返回站点来优化).
内联函数也可能对L2缓存施加不适当的压力 - 如果内联函数的使用次数非常多,额外的代码大小将增加缓存未命中的可能性,导致长时间延迟和流水线停滞,因为CPU使其瘫痪拇指等待内存总线做某事.
inline远不是一颗银弹.具有积极优化的编译器将inline完全忽略该提示,因为它们将基于启发式(例如代码大小或分支的存在)选择要内联的函数,而不管inline关键字的存在与否.
我唯一知道的是(1.)会增加耦合,这是不好的.
这是我从未听过的."耦合"是我在描述代码的高级关系时所听到的概念.这更像是代码的可维护性和通用性问题.inline是一个低级代码生成的问题.
至于模板,如果它的启发式方法显示出这样做的优势,那么积极优化的编译器将会内联.
但是,需要考虑链接级问题:您可能需要声明一个函数或模板inline(或static根据具体情况),以便在链接时消除重复的符号或限制符号可见性.当然,这不是优化.
总之,inline除非特别要求,否则不要使用关键字.
| 归档时间： |
|
| 查看次数： |
4918 次 |
| 最近记录： |