什么时候虚拟继承是一个好的设计？

Question

EDIT3：请务必在回答之前清楚地了解我要问的内容（有 EDIT2 和很多评论）。有（或曾经）有很多答案清楚地表明了对问题的误解（我知道这也是我的错，对此感到抱歉）

嗨，我已经查看了有关虚拟继承的问题（class B: public virtual A { ...}）在 C++ 中，但没有找到我的问题的答案。

我知道虚拟继承存在一些问题，但我想知道在什么情况下虚拟继承会被认为是一个好的设计。

我看到人们提到了诸如 IUnknown 或 ISerialized 之类的接口，而且 iostream 设计是基于虚拟继承的。这些是很好地使用虚拟继承的好例子吗？这只是因为没有更好的选择，还是因为虚拟继承在这种情况下是正确的设计？谢谢。

编辑：为了澄清，我问的是现实生活中的例子，请不要给出抽象的例子。我知道什么是虚拟继承以及哪种继承模式需要它，我想知道什么时候它是做事的好方法，而不仅仅是复杂继承的结果。

EDIT2：换句话说，我想知道什么时候菱形层次结构（这是虚拟继承的原因）是一个好的设计

Answer 1

如果您有接口层次结构和相应的实现层次结构，则有必要将接口基类设为虚拟基类。

例如，

struct IBasicInterface
{
    virtual ~IBasicInterface() {}
    virtual void f() = 0;
};

struct IExtendedInterface : virtual IBasicInterface
{
    virtual ~IExtendedInterface() {}
    virtual void g() = 0;
};

// One possible implementation strategy
struct CBasicImpl : virtual IBasicInterface
{
    virtual ~CBasicImpl() {}
    virtual void f();
};

struct CExtendedImpl : virtual IExtendedInterface, CBasicImpl
{
    virtual ~CExtendedImpl() {}
    virtual void g();
};

通常只有当您有多个扩展基本接口的接口并且在不同情况下需要多个实现策略时，这才有意义。这样，您就有了清晰的接口层次结构，并且您的实现层次结构可以使用继承来避免公共实现的重复。不过，如果您使用 Visual Studio，您会收到很多警告 C4250。

为了防止意外切片，通常最好的做法是 CBasicImpl 和 CExtendedImpl 类不可实例化，而是具有更高级别的继承，不提供额外的功能（除了构造函数）。

Answer 2

当类 A 扩展另一个类 B，但 B 除了可能的析构函数之外没有虚拟成员函数时，虚拟继承是一个很好的设计选择。您可以将 B 这样的类视为 mixins，其中类型层次结构只需要一个mixin 类型的基类以便从中受益。

一个很好的例子是 STL 的 libstdc++ 实现中与某些 iostream 模板一起使用的虚拟继承。例如，libstdc++ 声明模板 basic_istream 时使用：

template<typename _CharT, typename _Traits>
class basic_istream : virtual public basic_ios<_CharT, _Traits>

它使用虚拟继承来扩展 basic_ios<_CharT, _Traits> 因为 istream 应该只有一个输入 Streambuf，并且 istream 的许多操作应始终具有相同的功能（特别是用于获取唯一输入流缓冲区的 rdbuf 成员函数）。

现在想象一下，您编写了一个类 (baz_reader)，它使用成员函数扩展 std::istream 来读取 baz 类型的对象，并且另一个类 (bat_reader)，它使用成员函数扩展 std::istream 来读取 bat 类型的对象。您可以拥有一个同时扩展 baz_reader 和 bat_reader 的类。如果不使用虚拟继承，则 baz_reader 和 bat_reader 基将各自拥有自己的输入流缓冲区 - 可能不是意图。您可能希望 baz_reader 和 bat_reader 基都从同一个流缓冲区读取。如果没有 std::istream 中的虚拟继承来扩展 std::basic_ios，您可以通过设置 baz_reader 的成员 readbufs 来实现此目的> 和 bat_reader 基于同一个streambuf对象，但是当一个就足够时，您将拥有指向streambuf的指针的两个副本。

Answer 3

Grrr .. 虚拟继承必须用于抽象子类型。如果要遵守面向对象的设计原则，就完全别无选择。如果不这样做，就会阻止其他程序员派生其他子类型。

首先是一个抽象示例：您有一些基本抽象 A。您想要创建一个子类型 B。请注意子类型必然意味着另一个抽象。如果它不是抽象的，那么它就是一个实现而不是类型。

现在，另一个程序员出现了，他想要创建 A.Cool 的子类型 C。

最后，又一位程序员出现了，他想要既是 B 又是 C 的东西。当然，它也是 A。在这些场景中，虚拟继承是强制的。

这是一个真实世界的示例：来自编译器的数据类型建模：

struct function { ..
struct int_to_float_type : virtual function { ..

struct cloneable : virtual function { .. 

struct cloneable_int_to_float_type : 
  virtual function, 
  virtual int_to_float_type 
  virtual cloneable 
{ ..

struct function_f : cloneable_int_to_float_type { 

这里，function 表示函数，int_to_float_type 表示子类型
由从 int 到 float 的函数组成。 Cloneable 是一个特殊属性
该函数可以被克隆。 function_f 是一个具体的（非抽象的）
功能。

请注意，如果我最初没有将 function 设为 int_to_float_type 的虚拟基，我就无法混合 cloneable （反之亦然）。

一般来说，如果遵循“严格”的 OOP 风格，则始终定义抽象网格，然后为它们派生实现。您可以严格区分仅适用于抽象的子类型和实现。

在 Java 中，这是强制执行的（接口不是类）。在 C++ 中，它不是强制的，您不必遵循该模式，但您应该意识到这一点，并且您正在合作的团队或您正在从事的项目越大，理由就越充分你需要离开它。

Mixin 类型需要 C++ 中的大量内务处理。在 Ocaml 中，类和类类型是独立的，并通过结构（是否拥有方法）匹配，因此继承总是很方便。这实际上比名义上的打字更容易使用。 Mixins 提供了一种在只有名义类型的语言中模拟结构类型的方法。

Answer 4

虚拟继承并不是一件好事或坏事——它是一个实现细节，就像任何其他细节一样，它的存在是为了实现出现相同抽象的代码。当代码必须是超级运行时时，这通常是正确的做法，例如，在 COM 中，一些 COM 对象必须在进程之间共享，更不用说编译器之类的了，需要使用 IUnknown，而普通 C++ 库只需使用shared_ptr。因此，在我看来，正常的C++代码应该依赖于模板和类似的东西，不应该需要虚拟继承，但在某些特殊情况下这是完全必要的。

Answer 5

既然您要求提供具体示例，我建议使用侵入式引用计数。在这种情况下，虚拟继承并不是一个好的设计，但虚拟继承是使该工作正常工作的正确工具。

在 90 年代初期，我使用了一个类库，该类库有一个 ReferenceCounted 类，其他类将从该类派生来为其提供引用计数和一些用于管理引用计数的方法。继承必须是虚拟的，否则如果您有多个基，每个基都非虚拟地从 ReferenceCounted 派生，那么您最终会得到多个引用计数。虚拟继承确保您的对象拥有单个引用计数。

使用 shared_ptr 和其他方法的非侵入式引用计数现在似乎更流行，但是当类将 this 传递给其他方法时，侵入式引用计数仍然有用。在这种情况下，外部引用计数会丢失。我还喜欢侵入式引用计数，它讲述了一个类如何管理该类的对象的生命周期。

[我想我是在捍卫侵入式引用计数，因为我现在很少看到它，但我喜欢它。]

Answer 6

当您被迫使用多重继承时，就需要虚拟继承。有些问题无法通过避免多重继承来干净/轻松地解决。在这些情况下（这种情况很少见），您将需要考虑虚拟继承。 95% 的情况下，您可以（并且应该）避免多重继承，以避免为您自己（以及在您之后查看代码的人）带来许多麻烦。

附带说明一下，COM 并不强制您使用多重继承。创建一个从 IUnknown（直接或间接）派生​​并具有线性继承树的 COM 对象是可能的（而且很常见）。

Answer 7

这些常见问题解答回答了与虚拟继承相关的所有可能的问题。甚至是您问题的答案（如果我正确识别您的问题；））：常见问题解答项 25.5