c++ - 编译器是否更有可能使用指定的 inline 关键字在类声明中内联函数？

Question

我最近在查看一位同事的代码，注意到他在类声明中定义的一堆 Getter 函数前面放置了“inline”关键字。

例如

class Foo
{
public:
    inline bool GetBar() const { return m_Bar; }
private:
    bool m_Bar;
};

我在代码审查中建议他删除内联关键字，正如我在许多不同的地方读到的那样，在类声明中定义函数是由编译器解释的(在这种情况下为 MSVC，但显然是 C++ 标准的一部分) 作为作者想要内联函数的指示。我的感觉是，如果额外的文本没有任何作用，那只是不必要的困惑，应该删除。

他的回应如下:

inline 关键字让与此代码交互的其他程序员清楚地知道这些函数是/应该是内联的。

在这种情况下，许多编译器仍将 inline 关键字考虑在内，并使用它来影响(读取:增加)某种权重，该权重用于决定所述函数实际上是否会被内联。

有 inline 关键字意味着如果所述函数由于任何原因未内联，则将触发“如果未内联则警告”警告(如果启用)。

就我个人而言，我完全不同意第一个原因。对我来说，在类声明中定义函数就足以表明意图。

我对后两个原因持怀疑态度。我找不到任何确认或否认有关影响某种权重的内联关键字的观点的信息。我也无法为类声明中定义的函数触发“如果未内联则警告”警告。

如果您已经读到这里，我想知道您是否对上述任何一点有任何见解？此外，如果您能指点我任何相关的文章/文档，我将不胜感激。

谢谢!

Answer 1

编辑 1:添加了 LLVM(即“clang”)内联代码

编辑 2:添加有关如何“解决”此问题的说明。

实际正确

第 1 点当然是不言自明的。

第 2 点是无稽之谈 - 所有现代编译器(至少 MS、GCC 和 Clang [aka XCode])完全忽略 inline关键字并纯粹根据频率/大小标准决定(根据大小 * 次数确定“代码膨胀因子”，因此小函数或仅调用几次的函数更有可能被内联 - 当然，getter 将是一个完美的选择始终由编译器内联的选择，因为它只有两到三个指令，并且很可能比加载 this 短，然后调用 getter 函数。
inline关键字根本没有任何区别[并且 C++ 标准指出类中的定义是 inline反正]。

第 3 点是另一种可能的情况，但我会认为它的定义隐式内联的事实应该给出相同的结果。有关于inline的讨论前阵子在 Clang 邮件列表上的关键字及其含义，得出的结论是“编译器通常最了解”。

使用 inline 通常也完全没用。与虚函数一起使用，因为它们几乎总是通过 vtable 条目调用，并且不能内联。

编辑1:

取自 LLVM 的“InlineCost.cpp”的代码:

InlineCost InlineCostAnalysis::getInlineCost(CallSite CS, Function *Callee,
                                             int Threshold) {
  // Cannot inline indirect calls.
  if (!Callee)
    return llvm::InlineCost::getNever();

  // Calls to functions with always-inline attributes should be inlined
  // whenever possible.
  if (CS.hasFnAttr(Attribute::AlwaysInline)) {
    if (isInlineViable(*Callee))
      return llvm::InlineCost::getAlways();
    return llvm::InlineCost::getNever();
  }

  // Never inline functions with conflicting attributes (unless callee has
  // always-inline attribute).
  if (!functionsHaveCompatibleAttributes(CS.getCaller(), Callee,
                                         TTIWP->getTTI(*Callee)))
    return llvm::InlineCost::getNever();

  // Don't inline this call if the caller has the optnone attribute.
  if (CS.getCaller()->hasFnAttribute(Attribute::OptimizeNone))
    return llvm::InlineCost::getNever();

  // Don't inline functions which can be redefined at link-time to mean
  // something else.  Don't inline functions marked noinline or call sites
  // marked noinline.
  if (Callee->mayBeOverridden() ||
      Callee->hasFnAttribute(Attribute::NoInline) || CS.isNoInline())
    return llvm::InlineCost::getNever();

  DEBUG(llvm::dbgs() << "      Analyzing call of " << Callee->getName()
        << "...\n");

  CallAnalyzer CA(TTIWP->getTTI(*Callee), ACT, *Callee, Threshold, CS);
  bool ShouldInline = CA.analyzeCall(CS);

  DEBUG(CA.dump());

  // Check if there was a reason to force inlining or no inlining.
  if (!ShouldInline && CA.getCost() < CA.getThreshold())
    return InlineCost::getNever();
  if (ShouldInline && CA.getCost() >= CA.getThreshold())
    return InlineCost::getAlways();

  return llvm::InlineCost::get(CA.getCost(), CA.getThreshold());
}

可以看出(在代码的其余部分进行了一些挖掘)，只检查“always”和“never”内联选项。内联关键字本身没有。

[请注意，这是 clang 和 clang++ 的内联代码——clang 本身在生成代码时并没有做任何特别聪明的事情，它“只是”(让数百名在该项目上花费数百年的程序员感到不安!)C 的解析器和转换为 LLVM IR 的 C++，所有好的、聪明的东西都是在 LLVM 层完成的——这确实是提供“多语言”编译器框架的好方法。我编写了一个 Pascal 编译器，尽管我是编译器工作的完全新手，但我的编译器(使用 LLVM 生成实际机器代码)在(生成的代码的)基准测试中比 Free Pascal 更好——这一切都归功于 LLVM，几乎没有这是我的工作 - 除了一些代码在一个特定的基准测试中内联一些常用的函数]

我没有 MS 编译器的访问源(doh!)，我也懒得下载 gcc 来检查这个。我知道，根据经验，所有三个都将内联函数而没有 inline 关键字，而 gcc 将积极内联它可以确定只有一个调用者的函数(例如大型 static 辅助函数)

编辑2:

解决这类问题的正确方法是制定一个编码标准，清楚地说明何时何地 inline [和在类中定义的函数] 应该使用，以及何时不应该使用。如果当前，其他类中的其他小 getter 函数都没有 inline在他们身上，那么这个功能会很奇怪而且很突出。如果除了一些之外的所有人都有 inline ，这可能也应该修复。

另一个轶事:我个人喜欢将 if 语句写为

if (some stuff goes here)

(如果和括号之间有空格，但不在里面的东西周围)
但工作中的编码标准说:

if( some stuff goes here )

(if 和括号之间没有空格，但是里面的东西周围有空格)

我不小心得到了这样的东西:

if ( some stuff goes here )

在一些需要审查的代码中。我修复了该行，但决定还修复其他 175 个 if 语句，并在 if 后面留一个空格- 该文件中总共有不到 350 个 if 语句，所以其中一半以上是不正确的......