这篇文章将为大家详细讲解有关C++中菱形继承和虚继承的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
继承：
1. 单继承–一个子类只有一个直接父类时称这个继承关系为单继承
2. 多继承–一个子类有两个或以上直接父类时称这个继承关系为多继承
例如下面这两个例子：
例一（单继承）：
重庆分公司
重庆分公司
class A
{
public:
int _a;
};
class B : public A // B是 子类/派生类， 公有 继承父类/基类 A
{
public:
int _b;
};
class C : public B //C是 子类/派生类， 公有继承 父类/基类 B
{
public:
int _c;
};例二（多继承）：
class A
{
public:
int _a;
};
class B
{
public:
int _b;
};
class C : public A , public B // 子类C同时公有继承父类A和父类B
{
public:
int _c;
};用图很形象的表示一下：
但是在使用过程中，很容易出现一种继承关系叫菱形继承。就好比下面这种继承方式。
class A
{
public:
int _a;
};
class B : public A
{
public:
int _b;
};
class C : public A
{
public:
int _c;
};
class D : public B, public C
{
public:
int _d;
};
继承的方式简单画出来就是下面这样：
我们在使用过程中会发现以下缺点：
1、 当我们用D类创建出对象d时，可以访问到_a，但是一旦编译就会出现错误。错误说明为： C2385: 对“_a”的访问不明确。从图中也可以看出，如果用d访问_a时，可能在B类里，也同时可能存在于c类中。这就是所谓的“二义性”；
2、虽然B类和C类都公有继承A，但是在D类公有继承B，C时，存放了两份A类，造成了数据的冗余。
C++针对这种缺陷提出了另外一种继承方式叫做虚继承。
虚继承
C++使用虚拟继承（Virtual Inheritance），解决从不同途径继承来的同名的数据成员在内存中有不同的拷贝造成数据不一致问题，将共同基类设置为虚基类。这时从不同的路径继承过来的同名数据成员在内存中就只有一个拷贝，同一个函数名也只有一个映射。
◇语法：
class 派生类: virtual 基类1，virtual 基类2，…，virtual 基类n
{
…//派生类成员声明
};在有了虚继承的概念后，我们就可以规避上面的缺点了。
class A
{
public:
int _a;
};
class B : virtual public A
{
public:
int _b;
};
class C : virtual public A
{
public:
int _c;
};
class D : public B, public C
{
public:
int _d;
};当我们使用了虚继承时，继承模型就改变为下面这样：
由于我所使用的是vs2015，在此编译器下对应的处理方式就是这样。将class B 和 class C设置为虚继承后，编译器将class A存放在了最下端，并在B和C类的前四个字节中存放了一个地址，当我们访问过去向下再多看四个字节时就会发现这其中存放了一个数字。而这个数字就类似于“偏移量”，记录了该类的首地址距父类首地址之间的字节差距。比如class B中，我们找到对应数字为14，但是这个数字是16进制，转为10进制为20，在class B的首地址加上20个字节就恰好是class A的首地址，同理class C。
因此在class D访问_a时，就不会产生二义性，_a数据也只存放了一份，解决了之前菱形继承所带来的问题。
但是还存在一个问题：当我们求没有使用虚继承之前的class D的大小，结果是20，但是在使用了虚继承后大小变为24。所以虽然使用虚继承解决数据冗余问题也带来了性能上的损耗。（关于如何计算内存大小，可以参考此链接。）
关于“C++中菱形继承和虚继承的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
另外有需要云服务器可以了解下创新互联建站www.cdcxhl.com，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
