为何C++虚继承需在中间类使用virtual而非最终派生类？

首先看经典的菱形继承正确实现代码：

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

int main()
{
    D obj;
    obj.i = 0;
    return 0;
} 

你提出的替代写法虽然直觉上更灵活，但C并未采用，核心原因是这种设计违背了C的核心设计原则，具体可以从以下几点理解：

• 内存布局必须由类自身定义决定
  当类B以普通方式继承A时，B的对象会直接包含一份A的子对象；如果是虚继承，B的对象会存储指向虚基类表的指针，而非A的完整副本。这种内存结构是B的固有属性，不能由后续的派生类D来改变。如果允许D在继承时才指定virtual，会导致同一个类B的对象，在单独使用和作为D的基类时拥有完全不同的内存布局，这完全破坏了静态类型语言的可预测性。

• 成员访问的一致性要求
  假设你的替代写法可行，那么单独创建的B对象（B objB;）里有自己独立的A::i，但D对象中的B子对象却要和C子对象共享同一个A::i。这会导致B的成员函数行为出现歧义：当B的成员函数访问i时，到底是访问自己的独立副本，还是共享的那个？这种上下文依赖的行为在C++中是不被允许的，因为类的行为必须是确定且可预测的。

• 封装性与设计责任的归属
  虚继承的本质是在声明：“我（B/C）的基类A是需要被共享的，当我被多重继承时，不要重复创建A的实例”。这个决策应该由B/C的设计者做出，因为他们最清楚A的语义——比如A是否是一个具有共享语义的接口类，还是一个有独立状态的具体类。如果把这个决策权交给D的设计者，相当于允许后续类修改前置类的语义，直接破坏了类的封装性。

• 编译器实现的高效性与确定性
  C++的虚继承设计是早期为解决多重继承二义性问题演化而来的，让类在定义时就确定是否使用虚继承，能让编译器在编译B/C阶段就确定其内存布局，不需要等到编译D时再回溯调整，这大大降低了编译器实现的复杂度，同时避免了潜在的二义性和不可预测性问题。

你的替代写法看似灵活，但实际上会打破静态类型语言的核心规则，导致类的行为和结构依赖于使用场景，这在C++这种强调类型安全和可预测性的语言中是不可接受的。

内容的提问来源于stack exchange，提问作者M. Saamin Rahman