当调用非虚拟基方法时，C++ 中的虚拟继承是否有任何惩罚/成本？

Question

当我们从基类调用常规函数成员时，在 C++ 中使用虚拟继承是否会在编译代码中产生运行时损失？示例代码：

class A {
    public:
        void foo(void) {}
};
class B : virtual public A {};
class C : virtual public A {};
class D : public B, public C {};

// ...

D bar;
bar.foo ();

Answer 1

是的，如果您通过指针或引用调用成员函数，并且编译器无法绝对确定该指针或引用指向或引用的对象类型，则可能会出现这种情况。例如，考虑一下：

void f(B* p) { p->foo(); }

void g()
{
    D bar;
    f(&bar);
}

假设对 f 的调用不是内联的，编译器需要生成代码来查找 A 虚拟基类子对象的位置，以便调用 <代码>foo。通常此查找涉及检查 vptr/vtable。

如果编译器知道您调用函数的对象的类型（如您的示例中的情况），则应该没有开销，因为可以静态分派函数调用（在编译时）。在您的示例中， bar 的动态类型已知为 D （它不能是其他任何值），因此虚拟基类子对象 的偏移量A 可以在编译时计算。

Answer 2

是的，虚拟继承有运行时性能开销。这是因为，对于任何指向对象的指针/引用，编译器在编译时无法找到它的子对象。相反，对于单继承，每个子对象都位于原始对象的静态偏移处。考虑一下：

class A { ... };
class B : public A { ... }

B 的内存布局看起来有点像这样：

| B's stuff | A's stuff |

在这种情况下，编译器知道 A 在哪里。然而，现在考虑 MVI 的情况。

class A { ... };
class B : public virtual A { ... };
class C : public virtual A { ... };
class D : public C, public B { ... };

B 的内存布局：

| B's stuff | A's stuff |

C 的内存布局：

| C's stuff | A's stuff |

但是等等！当 D 被实例化时，它看起来不是这样的。

| D's stuff | B's stuff | C's stuff | A's stuff |

现在，如果你有一个 B*，如果它确实指向 B，那么 A 就在 B- 旁边，但如果它指向 D，那么为了获得 A*，你真的需要跳过 C 子-object，并且由于任何给定的 B* 都可以在运行时动态指向 B 或 D，因此您需要动态更改指针。这至少意味着您必须生成代码以通过某种方式查找该值，而不是在编译时嵌入该值（这是单继承所发生的情况）。

Answer 3

至少在典型的实现中，虚拟继承对（至少是某些）数据成员的访问带来（小！）惩罚。特别是，您通常会得到额外的间接级别来访问您虚拟派生的对象的数据成员。出现这种情况是因为（至少在正常情况下）两个或多个单独的派生类不仅具有相同的基类，而且具有相同的基类对象。为了实现这一点，两个派生类都具有指向最远派生对象中相同偏移量的指针，并通过该指针访问这些数据成员。

尽管从技术上来说这不是由于虚拟继承造成的，但可能值得注意的是，一般来说，多重继承有一个单独的（同样，很小的）惩罚。在单继承的典型实现中，您在对象中的某个固定偏移处（通常是最开始的位置）有一个虚函数表指针。在多重继承的情况下，显然不能在相同的偏移量处有两个 vtable 指针，因此最终会得到许多 vtable 指针，每个指针在对象中都有单独的偏移量。

IOW，具有单继承的 vtable 指针通常只是 static_cast(object_address)，但具有多重继承时，您会得到 static_cast(object_address+offset)。

从技术上讲，两者是完全独立的——但是当然，虚拟继承几乎唯一的用途是与多重继承结合使用，所以无论如何它都是半相关的。

Answer 4

具体来说，在 Microsoft Visual C++ 中，指向成员的指针大小存在实际差异。
请参阅#pragmapointers_to_members。正如您在该清单中所看到的 - 最通用的方法是“虚拟继承”，它不同于多重继承，而多重继承又不同于单继承。

这意味着在存在虚拟继承的情况下，需要更多信息来解析指向成员的指针，并且如果仅通过 CPU 缓存中占用的数据量，就会对性能产生影响 - 尽管也可能在成员查找的长度或所需的跳转次数。

Answer 5

我认为，虚拟继承没有运行时惩罚。 不要将虚拟继承与虚拟函数混淆。两者是不同的东西。

虚拟继承可确保 D 实例中只有一个子对象 A。所以我不认为它会单独产生运行时损失。

但是，可能会出现在编译时无法知道该子对象的情况，因此在这种情况下，虚拟继承会产生运行时损失。 詹姆斯在他的回答中描述了一个这样的案例。

Answer 6

您的问题主要集中在调用虚拟基类的常规函数，而不是虚拟基类的虚拟函数（示例中的A类）更有趣的情况）——但是，是的，可能会有成本。当然，一切都依赖于编译器。

当编译器编译 A::foo 时，它假定“this”指向 A 的数据成员在内存中驻留的开始位置。此时，编译器可能不知道类 A 将是任何其他类的虚拟基类。但它很乐意生成代码。

现在，当编译器编译 B 时，不会真正发生变化，因为虽然 A 是虚拟基类，但它仍然是单继承，并且在典型情况下，编译器将通过紧随其后放置类 A 的数据成员来布局类 B通过类 B 的数据成员 - 因此 B * 可以立即转换为 A * 而无需任何值更改，因此无需进行任何调整。编译器可以使用相同的“this”指针（即使它是 B * 类型）调用 A::foo 并且没有任何害处。

同样的情况也适用于类 C——它仍然是单一继承，并且典型的编译器将把 A 的数据成员紧跟在 C 的数据成员后面，这样 C * 就可以立即转换为 A * 而无需任何值更改。因此，编译器可以简单地使用相同的“this”指针调用 A::foo（即使它是 C* 类型），并且没有任何害处。

然而，类 D 的情况完全不同。类 D 的布局通常是类 A 的数据成员，然后是类 B 的数据成员，然后是类 C 的数据成员，然后是类 D 的数据成员。

使用典型的布局，D * 可以立即转换为 A *，因此 A::foo 不会受到任何影响——编译器可以调用为 A::foo 生成的相同例程，而无需对“this”进行任何更改一切都很好。

但是，如果编译器需要调用成员函数（例如 C::other_member_func），即使 C::other_member_func 是非虚拟的，情况也会发生变化。原因是，当编译器为 C::other_member_func 编写代码时，它假设“this”指针引用的数据布局是 A 的数据成员，紧接着是 C 的数据成员。但对于 D 的实例而言，情况并非如此。编译器可能需要重写并创建一个（非虚拟）D::other_member_func，只是为了处理类实例内存布局差异。

请注意，在使用多重继承时，这是一种不同但相似的情况，但在没有虚拟基的多重继承中，编译器可以通过简单地向“this”指针添加位移或修复来处理所有事情，以说明基类的位置“嵌入”派生类的实例中。但对于虚拟基，有时需要重写函数。这完全取决于所调用的（甚至非虚拟）成员函数访问哪些数据成员。

，编译器可能需要编写：

1. 例如，如果类 C 定义了一个非虚拟成员函数 C::some_member_func，则当从 C（而不是 D）的实际实例调用时 C::some_member_func，这是在编译时确定的（因为some_member_func 不是虚函数）
2. C::some_member_func 当从类 D 的实际实例调用相同的成员函数时（在编译时确定）。 （从技术上讲，这个例程是 D::some_member_func。尽管这个成员函数的定义是隐式的并且与 C::some_member_func 的源代码相同，但生成的目标代码可能略有不同。）

如果 C::some_member_func 的代码恰好使用了 A 类和 C 类中定义的成员变量。

Answer 7

好吧，在许多好的答案解释之后，虽然查找虚拟基类在内存中的确切位置会导致性能损失，但还有一个后续问题：“这个损失可以减少吗？”幸运的是，有一个以（尚未提及）final 关键字形式存在的部分解决方案。特别是，从原始示例的类 D 到最内层基 A 的调用通常（几乎）不会受到惩罚，但仅在一般情况下，如果您最终化D。

为什么这是必要的，让我们看一下多级类层次结构：

class Base {};

class ExtA : public virtual Base {};
class ExtB : public virtual Base {};
class ExtC : public virtual Base {};

class App1 : public Base {};
class App2 : public ExtA {};
class App3 : public ExtB, public ExtC {};

class SuperApp : public App2, public App3 {};

因为我们的 App 应用类可以使用基类的各种 Ext ension 类，所以这些都不是 code>Extension 类可以在编译时知道 Base 子对象将位于调用它们的对象内的位置。相反，他们必须在运行时查阅虚拟表才能找到答案。这是因为各种 Ext 和 App 类都可以在不同的翻译单元中定义。

但是 Application 类也存在同样的问题：因为 App2 和 App3 通过 App2 继承了虚拟化的 Base code>Extension 类，它们在编译时不知道 Base 子对象位于它们自己的对象中的位置。因此，App2 或 App3 的每个方法都必须查阅虚拟表，以找到 Base 子对象在其本地对象中的位置。这是因为以后进一步组合这些 App 类在语法上是合法的，如上面层次结构中的 SuperApp 类所示。

另请注意，如果Base 类调用Extension 或App应用级别上定义的任何虚拟方法，则会产生进一步的惩罚。这是因为将使用指向 Base 对象的 this 来调用虚拟方法，但他们必须通过再次查询虚拟表来将 this 调整为自己对象的开头。如果Extension或Application层（虚拟或非虚拟）方法调用在Base类上定义的虚拟方法，则惩罚为发生两次：第一次是查找 Base 子对象，然后再次查找与 Base 子对象相对的真实对象。

但是，如果我们知道不会创建组合多个 App 的 SuperApp，我们可以通过声明 App 来改进很多事情类final：

class App1 final : public Base {};
class App2 final : public ExtA {};
class App3 final : public ExtB, public ExtC {};

// class SuperApp : public App2, public App3 {};   // illegal now!

由于final使布局不可变，因此Application类的方法不需要通过虚拟表来查找Base 不再是子对象了。当调用任何Base方法时，他们只是将已知的常量偏移量添加到this指针。应用层的虚拟回调可以通过减去一个已知的常量偏移量来轻松修复 this 指针（或者甚至根本不修复它并引用来自的各个字段）而是对象的中间）。 Base 类的方法本身也不会产生任何惩罚，因为在该类中，一切正常。因此，在最外层具有最终化类的三级场景中，如果需要引用字段，则只有扩展级别上的方法的执行速度会较慢或 Base 类的方法，或者它们实际上是从 Base 调用的。

final 关键字的缺点是它不允许所有扩展。您无法再从 App2 派生 App2a，即使它不需要任何这些 Ext 扩展也是如此。并声明一个非final App2Base，然后从中声明final App2a 和 App2b ，将再次对 App2Base 中引用原始 Base 的所有方法造成惩罚。不幸的是，C++ 诸神并没有给我们一种方法来仅取消基类的虚拟化，而让非虚拟扩展成为可能。他们也没有为我们提供一种方法来声明“主”Extension 类，该类的布局保持固定，即使其他 Extension 具有相同的虚拟 还添加了 Base 类（在这种情况下，所有非主 Ext 对象都将引用主 Ext 中的 Base 子对象代码> ension）。

像这样的虚拟继承的替代方法通常是将所有扩展内容添加到 Base 类中。根据应用程序，这可能需要大量额外且经常未使用的字段和/或大量额外的虚拟方法调用和/或大量dynamic_cast，这些都会带来性能损失，也。

另请注意，在现代 CPU 中，错误预测的虚拟函数调用后的惩罚远高于错误预测的 this 指针修复后的惩罚。第一个需要丢弃在错误执行路径上获得的所有结果，并在正确的路径上重新启动。后者仍然需要重复直接或间接依赖于 this 的所有操作码，但不需要再次加载和解码指令。顺便说一句：未知指针修复的推测执行是 CPU 容易遭受 Spectre/Meltdown 类型数据泄漏的原因之一。

Answer 8

虚拟继承必然有成本。

证据是，实际上继承的类所占的份额大于各个部分的总和。

典型案例：(

struct A{double a;};

struct B1 : virtual A{double b1;};
struct B2 : virtual A{double b2;};

struct C : virtual B1, virtual B2{double c;}; // I think these virtuals are not strictly necessary

static_assert( sizeof(A) == sizeof(double) ); // as expected

static_assert( sizeof(B1) > sizeof(A) + sizeof(double) ); // the equality holds for non-virtual inheritance
static_assert( sizeof(B2) > sizeof(A) + sizeof(double) );  // the equality holds for non-virtual inheritance

static_assert( sizeof(C) > sizeof(A) + sizeof(double) + sizeof(double) + sizeof(double) );
static_assert( sizeof(C) > sizeof(A) + sizeof(double) + sizeof(double) + sizeof(double) + sizeof(double));

https://godbolt.org/z/zTcfoY)

额外存储了什么？我不太明白。
我认为它类似于虚拟表，但用于访问单个成员。

Answer 9

额外的内存是有成本的。例如，x86-64 上的 GCC 7 给出以下结果：

#include <iostream>

class A { int a; };
class B: public A { int b; };
class C: public A { int c; };
class D: public B, public C { int d; };
class BV: virtual public A { int b; };
class CV: virtual public A { int c; };
class DV: public BV, public CV { int d; };


int main()
{
    std::cout << sizeof(A) << std::endl;
    std::cout << sizeof(B) << std::endl;
    std::cout << sizeof(C) << std::endl;
    std::cout << sizeof(D) << std::endl;
    std::cout << sizeof(BV) << std::endl;
    std::cout << sizeof(CV) << std::endl;
    std::cout << sizeof(DV) << std::endl;
    return 0;
}

打印结果：

4
8
8
20
16
16
40

如您所见，使用虚拟继承时添加了一些额外的字节。