AFAIK，虚拟继承解决了菱形问题，但是如果我使用虚拟来简单地从基类继承呢？在这里使用有什么区别virtual？

给定代码：

我们可以让第二个断言失败吗？

换句话说，当我们有一个双菱形继承图并希望在派生最多的对象中为两个菱形的顶部有单独的子对象时，就是这种情况。

标准 (2003, 10.1.4) 的措辞似乎禁止这样做，如果确实如此，那么后续问题是：我们是否没有提供精确的虚拟多乘包含子对象结构操作的方法，为什么？

有这个代码：

我已经读过，当某个类被虚拟继承时，会为 Derived 类创建空 vtable，因此内存布局如下：

它是 12 个字节。问题是 -如果没有任何虚拟方法，这个空vtable 的用途是什么？它是如何使用的？

让我们从代码片段开始：

使用 GCC 4.5.1 和 4.6.1 编译 Derived 类的构造函数之间的唯一区别是第一个明确说明应该调用哪个 Base1 构造函数。我希望 main() 中的两个 cout 都打印 8。不幸的是，第一个打印 0！。

为什么？

如果我启用 Base1 构造函数的显式定义，它可以解决问题。如果我在派生类定义（派生类：public A1，public A2）中删除虚拟继承，它也可以工作。这是预期的行为吗？

在 GCC 3.4.4 或 Microsoft 编译器 (VS) 下无法观察到该问题

我想记录用户所做的操作。在大多数 OO 语言中，我会通过一个LoggedAction类来实现这一点，它有几个子类，例如LoginAction和LogoutAction. 然后我可以遍历一个 LoggedActions 列表并通过虚拟继承获得特定的子行为。但是，这不适用于 Django 模型。

示例models.py：

然后我想做[unicode(l) for l in LoggedAction.objects.all()]一个消息列表，例如u'2012-02-18 18:47:09.105840: knatten logged in'.

正如预期的那样，这不起作用，因为我从中得到的是具有成员或成员all()的对象列表。（输出是一个消息列表，如，没有提及操作。）LoggedActionloginactionlogoutactionu'2012-02-18 18:47:09.105840: knatten

有没有一种理智的方法来获得我所追求的行为，或者我是否试图在这里应用错误的范例？（我想我是，我应该只是作为成员的具体行动LoggedAction）

我有以下结构

请解释为什么以下代码打印 100: (10+0)

我认为它应该打印 1111: first A() : i = 0 then B1() : i = 1 and prints B1::f()- 11 then B2() : prints prints B1::f()- 11

我哪里错了？

谢谢

我已经提到了这个问题（我改变了它的标题）。我知道与virtualness 相关的代码生成是特定于实现的。但是，较早的问题表明virtual，在调用非虚拟基方法时，会产生与继承相关的额外成本。

我编写了以下测试代码并在 g++ 中检查了它的程序集（使用-O4）：

公共部分

现在不同的部分在这里：

代码 1（正常继承）

代码 2（虚拟继承）

代码3（多重虚拟继承）

整体代码在这里。

当我检查它的组装时，所有 3 个版本之间没有区别。以下是汇编代码：

这是否意味着virtual继承没有任何额外的成本，当某些优化是 ON 时？我是否需要执行任何更复杂的测试代码来评估它？请注意，如果不进行优化，这些程序集之间存在差异。

我有以下课程：

以及以下代码：

输出：

这是为什么？Med1构造函数在构造函数之后调用Base。我猜它是设置Med1::x，而不是Base::x，但为什么和不Der::x一样。为什么没有歧义？Base::xMed1::x

我正在编辑这个问题，使其更具可读性和不那么做作。我已经设法用下面的一小段代码复制了我的问题。那么，问题是：为什么在 ~A() 中的“删除 p”行上的 _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) 断言失败时会崩溃？

我经常使用纯虚拟类（接口）来减少当前项目中不同类的实现之间的依赖关系。我什至有层次结构，其中我有纯虚拟和非纯虚拟类扩展其他纯虚拟类，这对我来说并不罕见。下面是这种情况的一个例子：

两者兼而有之RunnableEngine，使钻石问题不受影响。RenderingEngineEngineSimpleOpenGLRenderingEngine

我想对钻石问题采取预防性立场，而不是在它成为问题时处理它，特别是因为我喜欢编写尽可能容易让其他人使用的代码，我不希望他们不得不修改我的类，以便他们可以创建特定的类层次结构，例如，如果 Bob 想这样做：

如果我没有进行虚拟SimpleOpenGLRenderingEngine扩展，这是不可能的。我知道 Bob 想要这样做的可能性可能非常低。RenderingEngine

所以，我已经开始使用总是虚拟地扩展纯虚拟类的约定，这样它们的多重继承就不会导致菱形问题。也许这是因为我来自 Java 并且倾向于只对非纯虚拟类使用单继承。我敢肯定在某些情况下这可能是矫枉过正，但使用这种约定有什么缺点吗？这会导致性能/功能等问题吗？如果不是，我看不出有理由不使用该约定，即使最终可能通常不需要它。