C++ - 避免在类定义中定义的函数的隐式内联答案

【问题标题】：C++ - avoiding the implicit inlining of a function defined in the class definitionC++ - 避免在类定义中定义的函数的隐式内联
【发布时间】：2012-06-01 23:15:22
【问题描述】：

在我的实现文件（.cc 文件）中，我经常发现在类定义中定义成员函数（例如 Pimpl 类的函数）很方便。例如：

struct X::Impl {
    void DoSomething() {
        ...
    }
};

而不是

struct X::Impl {
    void DoSomething();
};

void X::Impl::DoSomething() {
    ...
}

我认为这比在类定义之外实现函数更可取，原因有几个。它增强了可读性并促进了保持方法小（通过使其易于添加）的实践。代码也更易于维护，因为您无需更新方法声明。

我看到的唯一缺点是类声明中定义的方法是隐式内联的，由于目标代码的大小增加，这通常是不可取的。

我的问题是：

我有这个权利吗？我还缺少这种做法的其他缺点吗？
隐式内联是否值得担心？编译器是否足够聪明，可以拒绝我对不应内联的内联方法的隐式请求？
是否可以（通过编译器扩展或其他方式）声明类定义中定义的方法不被内联？

【问题讨论】：

它的可读性并不高，函数应该很小的想法来自教授，而不是现实世界。这是一个虚假的规则。
GCC 有 -fno-inline 但我认为关闭它会很愚蠢，我相信 gcc 会做出比我更明智的决定。
@JohnDibling：同意。重要的是要注意函数的 C++ 代码应该小以提高可读性，但生成的代码不必如此。让编译器做它最擅长的事情。
另外，如果你把 pimpl 定义放在标题中，它就不是真的 pimpl 了吗？
也许我们可以为 C++27 提出一个新的 'outline' 关键字

标签： c++

【解决方案1】：

简单的答案是您不应该在意。类定义中定义的成员函数隐含为inline，但这并不意味着它们是内联（即代码不需要在调用处内联）。

编译器实现者已经投入了大量时间和资源来提出启发式方法，根据函数的大小、复杂性以及是否可以内联来确定是否应该进行实际内联（不能内联递归函数^[*]）。与我们大多数人相比，编译器拥有更多关于生成代码及其运行架构的信息。相信它，那么如果您觉得可能存在问题，配置文件，并且如果配置文件表明您应该更改代码，请执行此操作，但事后做出明智的决定。

如果你想验证函数是否真的被内联，你可以查看程序集并检查是否有对函数的调用或代码是否真的被内联。

^[*] 如果编译器可以将递归转换为迭代，就像尾递归的情况一样，那么理论上可以内联转换后的函数。但是，带有循环的函数无论如何被内联的可能性较小......

【讨论】：

没错，你通常也可以指定递归深度，例如 boost::xpressive 就大量使用了它。事实上，我通常在单个 .h 文件中编写新类，当我发现该类有用时，我会创建一个随附的 .cpp 文件。
虽然您不应该关心函数是否被内联，但您可能应该关心标头中的函数定义是否具有 inline 关键字，因为如果包含多个翻译单元中的头文件。 inline 关键字说：“嘿，链接器！这个函数定义可能包含在 2、3 或 42 个翻译单元中。确保对所有这些单元只使用一个定义。”

【解决方案2】：

我不知道防止内联的可移植方式，但是使用 GCC，您可以使用属性。例如：

struct X::Impl {
    void DoSomething() __attribute__((noinline)) {
        ...
    }
};

【讨论】：

【解决方案3】：

将您的内联选择所节省的所有 CPU 时间加起来。在他们身上花的钱比你自己的少。线性路径长度担忧适用于现在每天处理数万亿次执行的路径。在 L1 中，40 亿已经足够接近一秒了。 250 次不是五分钟。如果没有人抱怨性能，那么您和您的编译器的选择至少在正确的联盟中发挥作用。

关于可读性的意见差异很大。重要的是你的听众的意见。

【讨论】：

【解决方案4】：

一般情况下，编译器会随心所欲地内联，不会过多关注程序员给出的任何inline关键字。 inline 通常被视为与static 大致相同。

例如，递归函数通常不能完全内联（您要内联的函数体将再次包含应该内联的调用）。要测试您的特定编译器的行为，您可以例如定义一个这样的类：

class Fib {
public:      
   int calc(int i);
};

int Fib::calc(int i) {
  if (i > 1)
     return calc(i-1) + calc(i-2);
  return 1;
}

使用此定义，如果编译器觉得有义务内联所有对calc 的调用，则以下示例程序将无法在合理的时间或大小内编译：

#include "tst.hpp"
#include <iostream>                
int main() {
   Fib f;
   std::cout << f.calc(1000) << std::endl;
};

所以你可以通过编译这个程序来测试你的编译器行为。如果编译成功，编译器不会内联所有对Fib::calc 的调用。

【讨论】：