C++ 做c++；11兼容的编译器总是忽略内联提示吗？

读到一篇文章，上面写着：

据说，内联提示编译器您认为函数应该内联。1998年可能是这样，但十年后编译器不需要这样的提示。更不用说人类在优化代码时通常是错误的，所以大多数编译器完全忽略了“提示”

这个答案是在2009年发布的，所以我想最终弄清楚：

现代的c++11兼容编译器是否总是忽略用户指定的

inline

提示，而只自动执行此操作

inline

提示是否仅用于提供向后兼容性

如果不是

1.

那么这个答案是不正确的

不，他们只是按照标准的要求来解释，但有些编译器可能只做这些（根据MSVC基于

inline

关键字选择的文档，GCC 5.1.0在决定时也会考虑

inline

关键字）

不，链接时也需要内联以避免重复符号

inline

关键字确实有意义，但不是您可能期望的意义。这并不意味着编译器必须/应该/可能内联扩展函数，也不意味着编译器可以决定做它认为合适的事情，不管您是否使用

inline

它的真正含义是，您应该并且可以在使用函数的每个编译单元中重复函数定义，而不会导致链接错误，这与

static

关键字非常相似

---

例如，GCC4.7.2（它可能不是最先进的，但仍然是一个相当现代的编译器）对

inline

的解释似乎不超过标准规定。如果禁用了优化，并且启用了优化，则它似乎不会内联函数，不管怎样，它都会按照自己喜欢的方式内联。唯一的区别是编译器在不同情况下如何处理“概述”函数，内联函数只是丢弃它，或者以一种避免链接时重复符号的方式处理它。

C++11编译器遵循的内联提示与C++03或该语言的任何版本完全相同

但是，请注意，

inline

关键字不是内联提示。提示看起来更像是

\uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

inline
关键字（或应用于模板等的隐式inline状态）表示函数是在头中定义的，因此链接器在组合翻译单元（
.cpp
文件）时应该看到它的多个副本。之所以这样命名，是因为定义必须可用才能内联函数，这意味着库中的函数实际上需要内联

现代的c++11兼容编译器是否总是忽略用户指定的内联提示，而只自动执行此操作
C++11与此无关，C++11标准没有改变
inline
的语义，编译器优化在很大程度上独立于正在编译的语言版本

内联提示是否仅用于提供向后兼容性
不，
inline
不是一个提示，编译器不会“忽略”
inline
，因为如果它这样做，您会得到多个定义错误。编译器赋予
inline
关键字的含义与您似乎理解的含义不同。这不是暗示

如果编译器看不到函数定义，它就不能内联函数定义（链接时间优化改变了这一点，但LTO的使用还不是很普遍，大多数库都没有提供支持LTO的二进制文件，允许链接时间内联）

您应该将
inline
理解为“此函数定义在此文件中以内联方式显示”，而不是“此函数的调用应以内联方式显示”

因此，
inline
关键字对于允许编译器查看多个文件中的函数定义非常有用，这意味着它可以通过内联调用来优化调用。这并不一定使它比同一翻译单元中定义的任何其他函数更容易内联

对于从多个翻译单元调用的函数，在头中定义函数并使其内联是编译器内联它们的必要条件，但这是不够的（因为编译器的内联决策基于其他条件）

这与向后兼容性无关，今天的情况和2009年一样。我想Victor明白，
inline
是一个提示，他问现代编译器是否仍将其视为一种暗示，或者他们是否普遍忽略了它。这已经在问题中发布的链接中的选定答案中进行了解释。如果我今天编写编译器，我可能会使用inline关键字在性能大致相同的两个选项（inline或not）之间进行选择，因此，如果编译器无法确定该走哪条路，请遵循提示！“但那只是我。”维克多波列维我不知道你想要什么样的答案。有些编译器不会根据
inline
关键字来选择内联，有些编译器可能会根据这个关键字来选择。@Yakk是的，这很糟糕，但我现在不知道答案中应该如何提及内联。@iammilind So，对您的问题的回答表明，
clang
不要忽略导致错误的提示，因为现在至少
clang
仍在搜索
inline
关键字并做出一些决定。是的。具有讽刺意味的是，与2014年11月给出的答案相比，2009年11月给出的答案更加现代。我希望前者是真的，而这正是我提出这个问题时的假设。很有可能，2014年11月给出的答案可能是克朗利米塔的一个孤立场景