阅读一个旧答案关于何时应该为函数/方法编写关键字“inline”?,其中说:
据说内联提示编译器您认为该函数应内联。这在1998年可能是正确的,但十年后编译器不需要这样的提示。更不用说人类在优化代码方面通常是错的,所以大多数编译器直接忽略了这个“提示”。
这个答案是2009年发布的,所以我想最终弄清楚:
- 现代的与c++11兼容的编译器是否始终忽略用户指定的
inline
提示并自动执行此操作? inline
提示是否仅保留提供向后兼容性?- 如果
1.
不是那么这个答案是不正确的吗?
阅读一个旧答案关于何时应该为函数/方法编写关键字“inline”?,其中说:
据说内联提示编译器您认为该函数应内联。这在1998年可能是正确的,但十年后编译器不需要这样的提示。更不用说人类在优化代码方面通常是错的,所以大多数编译器直接忽略了这个“提示”。
这个答案是2009年发布的,所以我想最终弄清楚:
inline
提示并自动执行此操作?inline
提示是否仅保留提供向后兼容性?1.
不是那么这个答案是不正确的吗?inline
关键字的存在进行选择,GCC 5.1.0在决定时也会考虑inline
关键字)。inline
关键字。inline
关键字确实有意义,但并非您可能期望的意义。它并不意味着编译器必须/应该/可以将函数内联展开,编译器可以根据自己的判断决定是否这样做,而不管您是否使用inline
关键字。
它的意思是,您应该并且可以在每个编译单元中重复函数定义,而不会导致链接错误-这与static
关键字非常相似。
例如,GCC 4.7.2(可能不是最先进的编译器,但仍然是相当现代的编译器)似乎不比标准规定更多地解释inline
。如果禁用优化,则不会内联函数;如果启用优化,则似乎会按照自己的意愿内联。唯一的区别在于编译器如何处理不同情况下的“轮廓”函数,在使用inline
时,它会简单地丢弃它或以避免链接时出现重复符号的方式处理它。
inline
是一个提示,他想知道现代编译器是否仍将其视为提示,还是通常会忽略它。 - TartanLlamainline
关键字选择内联,而有些编译器可能会根据此进行选择。 - skykinginline
的某些部分理解不够。 - Victor Polevoystatic
,因为它们是不同的解决方案,具有不同的结果,并不是inline
函数的即插即用替代品。它们解决了不同的问题(如果它们没有被内联,由于链接器需要保留所有定义,可能会导致显著的代码大小增加)。 - Jonathan Wakelyinline
,代码将无法链接。 - Jonathan Wakelyinline
关键字。将头文件包含在两个不同的文件中。将这些文件链接在一起。 - Jonathan Wakelyinline
不是内联提示。提示看起来更像__attribute__((always_inline))
。
inline
关键字(或应用于模板等的隐式内联状态)表示函数在头文件中定义,因此链接器在合并翻译单元(.cpp
文件)时应该期望看到多个副本。它被命名为这个原因是定义必须可用才能内联一个函数,这意味着库中的函数需要inline
才能实现内联。
clang
不会忽略提示,这使得当前答案是错误的,因为现在至少clang
仍然在寻找inline
关键字并做出一些决策。 - Victor Polevoyinline
只是一个被忽略的提示,它说inline
改变了语言语义,使得函数可以在多个翻译单元中定义。这不仅仅是为了向后兼容,而且是C++语言和链接模型的重要属性。因此,你的整个问题似乎基于错误的前提。inline
不是“只是一个提示”,它改变了代码编译和链接的方式,以便编译器可以进行内联(无需LTO)。 - Jonathan Wakelynamespace{}
也可以实现这一点而无需使用LTO,并且不太可能引起ODR违规。(但是,如果您要内联非LTO函数中的static
局部变量,则仍然需要它!) - Yakk - Adam Nevraumont