目录

1、只要继承不要多态

2、加上多态

3、多重继承

4、虚拟继承

---

在C++继承模型中，一个derived class object所表现出来的东西，是其自己的members加上其base class(es) members的总和。至于derived class members和base class(es) members的排列顺序，则并未在C++ Standard中强制规定，理论上编译器可以自己安排。在大部分的编译器上，base class members 总是先出现，但是virtual base class除外（一般而言，任何一条通则一旦碰上virtual base class 就没辙了，这里也不例外）。

对于如下的代码，他们的数据布局是这个样子的。

//supporting abstract data type
class Point2d{
public:
	//constructor(s)
	//operations
	//access functions
private:
	float x,y;
};
class Point3d{
public:
	//constructor(s)
	//operations
	//access functions
private:
	float x,y,z;
};

1、只要继承不要多态

或许程序员希望，不论是2D或者3D坐标点，都能够共享同一个实例，但有希望能够继续使用“与类型性质相关”的实例。我们设计一个策略，就是从Point2d中派生出Point3d，于是Point3d将继承x和y的数据和方法。带来的影响则是可以共享“数据本身”以及“数据处理方法”，并将之局部化。

class Point2d{
public:
	Point2d(float x=0.0, float y=0.0)
		:_x(x),_y(y){};
	float x(){return _x;}
	float y(){return _y;}
	
	void x(float newX){_x = newX;}
	void y(float newY){_y = newY;}
	void operator+=(const Point2d & rhs)
	{
		_x += rhs.x();
		_y += rhs.y();
	}
	//... more members
protected:
	float _x, _y;
};
//inheritance from concrete class
class Point3d : public Point2d{
public:
	Point3d(float x=0.0, float y=0.0,float z=0.0):
		:Point2d(x,y),_z(z){};
	float z(){return _z;}
	void z(float newZ){_z = newZ;}
	
	void operator+=(const Point3d& rhs)
	{
		Point2d::operator+=(rhs);
		_z += rhs.z();
	}
	//... more members
protected:
	float _z;
};

我们看看上面的代码，这个实现明显的表现出抽象类之间的紧密关系。当这两个class独立的时候，Point2d object和Point3d object的声明和使用都不会有所改变。下图显示了Point2d和Point3d继承关系的实物布局，其间并没有声明virtual接口。

把原本独立的class凑成一对“type/subtype”，并带有继承关系，此时容易犯什么错误呢？经验不足的人可能重复设计一些相互操作的函数。以我们例子中的constructor和operator+=为例。

第二个容易犯的错误是，把一个class分解成两层或者更多层，有可能会为了“表现class 体系之抽象化”而膨胀所需的空间。C++语言保证“出现derived class 中的base class subobject有其完整原样性”，正是重点所在。我们从一个具体的class开始。

class Concrete
{
public:
	//...
private:
	int val;
	char c1;
	char c2;
	char c3;
};

在一台32位的机器中，每一个Concrete class object的大小都是8 bytes，具体表现如下：

现在我们决定把Concrete分裂成三层结构。

class Concrete1
{
public:
	//...
private:
	int val;
	char bit1;
};
class Concrete2 : public Concrete1
{
public:
	//...
private:
	char bit2;
};
class Concrete3 : public Concrete2
{
public:
	//...
private:
	char bit3;
};

那现在Concrete3 object的大小是16bytes，比原来的设计多了100%，这是由于“出现derived class 中的base class subobject有其完整原样性”。用下图进行解释。

然而，为什么要保证“出现在derived class中的base class subobject有其完整的原样性”吗？

当编译器不保证“出现在derived class中的base class subobject有其完整的原样性”，那么就会出现以下的布局

下面的代码中存在一个BUG，这个BUG可以用图解释，只不过这个BUG需要非常长的时间找到。

Concrete2 *pc2;
Concrete1 *pc1_1, *pc1_2;
pc1_1 = pc2;
//这里有个BUG:derived class subobject被覆盖掉了，于是其bit2 member现在有了一个非预期的数值
*pc1_1 = *pc1_2;

2、加上多态

如果我要处理一个坐标点，而不打算在乎它是一个Point2d或者Pointe3d实例，那么我需要在继承关系中提供一个virtual function接口。让我们看看如果这么做，情况会有什么改变。

class Point2d
{
public:
	Point2d(float x=0.0, float y=0.0)
		:_x(x), _y(y){};
	//x和y的存取函数与前一版相同
	//由于对不同维度的点，这些函数操作固定不变，所以不必设计为virtual
	
	//加上z的保留空间（目前什么也没做）
	virtual float z(){ return 0.0; }//译注：2d的点z为0.0是合理的
	virtual void z(float){}
	
	//设定以下的运算符是virtual
	virtual void
	operator+=(const Point2d&rhs)
	{
		_x += rhx.x();
		_y += rhx.y();
	}
	//...more members
	
protected:
	float _x,_y;
};

只有当我们企图以多态的方式（polymorphically）处理2d或3d坐标点时，在设计之中导入一个virtual接口才合理。也就是说，写下如下的代码，其中p1和p2可能是2d，也可能是3d坐标点。

void foo(Point2d &p1, Point2d &p2)
{
	p1 += p2;
	//...
}

这并不是之前的任何设计支持的，这种弹性正是面向对象设计的重要部分。为了支持这种弹性，势必会对我们的Point2d class带来空间和存取时间上的额外负担：

• 导入一个和Point2d有关的virtual table，用来存放它所声明的每一个virtual functions的地址。这个table的元素个数一般而言是被声明的virtual functions的个数，再加上一个或者两个slots（用以支持runtime type identification）。
• 在每一个class object 中导入一个vptr，提供执行期的链接，使得每个object能够找到相应的virtual table。
• 加强constructor，使它能够为vptr设定初值，让它指向class所对应的virtual table。这可能意味着在derived class和每一个base class的constructor中，重新设定vptr值。其情况视编译器优化的积极性而定。
• 加强destructor，使它能够抹除“指向class之相关的virtual table”的vptr，要知道vptr很可能已经在derived class destructor中被设定为derived class的virtual table地址。

目前，C++编译器领域有一个主要的讨论主题：把vptr放置在class object的哪里会更好？最初在cfront中，它被放在了class object的尾部，用以暴漏base class C struct的对象布局。

但是到了C++2.0，开始支持虚拟继承和抽象基类，并且由于面向对象的范式（OO paradigm）的兴起，某些编译器开始把vptr放在class object的起头处。如图所示：

把vptr放在class object的前端，对于“在多重继承下，通过指向class members的指针调用virtual function”，会带来一些帮助。否则，不仅“从class object起始点开始量起”的offset必须执行期间备妥，甚至与class vptr之间的offset也必须备妥。当然，vptr放在前端，代价是丧失C预言兼容性。这种丧失有多少意义？有多少程序能从一个C struct派生一个具有多态性质的class呢？

3、多重继承

过于复杂且不实用，不考虑。

4、虚拟继承

多重继承的一个语意上的副作用是，它必须支持某种形式的“shared subobject继承”。典型的一个例子是最早的iostream library：

//pre-standard iostream implementation
class ios {...};
class istream : public ios {...};
class ostream : public ios {...};
class iostream ：
	public istream, public ostream {...};

下图表现的是iostream的继承关系。左边是多重继承，右边是虚拟继承。

不论是istream还是ostream都含有一个ios subobject。然而在iostream的对象布局中，我们只需要单一一份ios subobject就好。语言层面的解决办法是导入所谓的虚拟继承。

//pre-standard iostream implementation
class ios {...};
class istream : public virtual ios {...};
class ostream : public virtual ios {...};
class iostream ：
	public istream, public ostream {...};

正如其语意所呈现的复杂度，要在编译器中支持虚拟继承，实在难度颇高。在上述的iostream中，实现技术的难度在于，要找到一个足够有效的方式，将istream和iostream各自维护的ios subobject，折叠成一个由iostream维护的单一ios subobject，并且还可以保存base class和derived class的指针（以及reference）之间的多态指定操作（polymorphism assignments）。

一般的实现方法如下所述。Class如果内含一个或者多个virtual base class subobject，像istream那个样子，将被分割成两部分：一个不变区域和一个共享区域。不变区域的数据，不管后继如何衍化，总是拥有固定的offset（从object的开头算起），所以这一部分数据可以被直接存取。至于共享区域，所表现的就是virtual base class subobject。这一部分的数据，其位置会因为每次派生操作而变化，所以他们只能被间接存取。以下面的例子进行说明。

class Point2d{
public:
	...
protected:
	float _x,_y;
};
class Vertex : public virtual Point2d{
public:
	...
protected:
	Vertex *next;
};
class Point3d : public virtual Point2d{
public:
	...
protected:
	float _z;
};
class Vertex3d :
	public Vertex, public Point3d
{
public:
	...
protected:
	float mumble;
};

下图可以表示上图的关系：

如果我们有以下的Point3d运算符，那么内部的转换方式可能是这样子的。

void Point3d::operator+=(const Point3d &rhs)
{
	_x += rhs.x;
	_y += rhs.y;
	_y += rhs.y;
};
在cfront策略下，这个运算符会被内部转换成：
//虚拟的C++ 代码
__vbcPoint2d->_x += rhs.__vbcPoint2d->_x; //译注：vbc是virtual base class
__vbcPoint2d->_y += rhs.__vbcPoint2d->_y;
_z += rhs._z;

而一个derived class和一个base class的实例相互转换，像这样子：

Point2d *p2d = pv3d;
在cfront实现模型中，下面是虚拟的C++代码
Point2d *p2d = pv3d ? pv3d->__vbcPoint2d : 0;

更加详细的描述见下面的图，cfront实现方式。

上图实现的方式存在两个主要的缺点：

• 每一个对象必须针对其每一个virtual base class 背负一个额外的指针。然而，理想的情况是我们希望class object 有固定的负担，不会因为其virtual base classes的个数而有所变化。这如何解决？
•  由于虚拟集成串链的加长，导致间接存取层次的增加。如果我有三层虚拟派生，我就需要三次间接存取（经过三个virtual base class指针）。然而理想上我们却希望有固定的存取时间，不会应为虚拟派生的深度而改变。

第一个问题，Bjarne比较喜欢的方法是在virtual function table 中放置virtual base class的offset（而不是地址）。下图中显示了这种base class offset实现模型。我在Foundation项目中实现出该方法，将virtual base class offset 和virtual function entries混杂在一起。在新近的Sun编译器中，virtual function table可经由正值或者负值来索引。如果是正值，很显然就索引到virtual functions；如果是负值，则索引到virtual base class offsets。在这样的策略下，Point3d的operator+=运算符必须被转换成以下的形式：

//虚拟C++代码
(this + __vptr__Point3d[-1])->_x +=
	(&rhs + rhs.__vptr__Point3d[-1])_x;
(this + __vptr__Point3d[-1])->_y +=
	(&rhs + rhs.__vptr__Point3d[-1])_y;
_z += rhs.z;

Derived class实例和base class 实例之间的转换操作，像这样子：

Point2d *p2d = pv3d;
在cfront实现模型中，下面是虚拟的C++代码
Point2d *p2d = pv3d ? pv3d + pv3d->__vptr__Point3d[-1] : 0;