数据成员的存取与布局
已知下面一组数据成员：
class Point3d{
public:
//…
private:
float x;
static List<Point3d*> *freeList;
float y;
static const int chunkSize = 250;
float z;
} 数据成员的存取与布局 收藏
数据成员的布局
已知下面一组数据成员：
class Point3d{
public:
//…
private:
float x;
static List<Point3d*> *freeList;
float y;
static const int chunkSize = 250;
float z;
}
非静态数据成员在class object中的排列顺序将和其被声明的顺序一样，任何中间介入的静态数据成员如freeList和chunkSize都不会被放进对象布局中。在上述例子中，每一个Point3d对象由三个float组成，次序是x、y、z。静态数据成员存放在程序的data segment中，和个别的class object无关。
C++标准要求，在同一个access section（也就是private、public、protected等区段）中，members的排列只须符合“较晚出现的members在class object中有较高的地址”这一条即可。也就是说，各个members并不一定得连续排列。什么东西可能会介于被声明的members之间呢？比如说members的边界调整时需要填充的一些字节等等。
同时，编译器还可能会合成一些内部使用的data members，以支持整个对象模型。vptr就是这样的东西，当前所有的编译器都把它安插在每一个“内含virtual function的class”的object内。vptr会被放在什么位置呢？传统上它被放在所有明确声明的members的最后，不过如今也有一些编译器把vptr放在class object的最前端。C++ standard允许编译器把这些内部产生出来的members自由放在任何位置上。
C++标准也允许编译器将多个access sections之中的data members自由排列，不必在乎它们出现在class声明中的次序。也就是说，下面这样的声明中：
class Point3d{
public:
//…
private:
float x;
static List<Point3d*> *freeList;
private:
float y;
static const int chunkSize = 250;
private:
float z;
}
其class object的大小和组成和我们先前声明的那个相同，但是members的排列次序则视编译器而定。编译器可以随意把y或z或其它什么东西放在第一个，不过大部分的编译器都没有这样做。当前各家编译器都是把一个以上的access sections连锁在一起，依照声明次序，成为一个连续的区块。access sections的多少，不会招来额外的负担。例如，在一个section中声明8个members，或是在8个sections中总共声明8个members，得到的object大小是一样的。
静态数据成员的存取
Static data members，按照其字面意思，被编译器提出到class之外，并被视为一个global变量（但只在class生命范围之内可见）。每一个member的存取许可（private或protected或public），以及与class的关联，并不会导致任何空间上或执行时间上的额外负担。
每一个static data member只有一个实体，存放在程序的data segment之中。每次程序取用static data member，就会被内部转化为对该唯一的extern实体的直接操作：
//origin.chunkSize = 250;
Point3d::chunkSize = 250;
//pt->chunkSize = 250;
Point3d::chunkSize = 250;
从指令执行的观点来看，这是C++语言中“通过一个指针和通过一个对象来存取member，结论完全相同”的唯一一种情况。这是因为“经由member selection operators对一个static data member进行存取操作“只是语法上都一种便宜行事而已。member其实不在class object之中，因此存取static members并不需要通过class object。
如果chunkSize是从一个复杂继承关系中继承而来都member，又当如何呢？或许它是一个“virtual base class的virtual base class“（或其它同等复杂的继承结构）的member也说不定。即使这样的情况，也是无关紧要的，程序之中对于static members还是只有唯一的一个实体，而其存取路径依然是那么直接。
若取一个静态数据成员的地址，会得到一个指向其数据类型的指针，而不是一个指向其class member的指针，因为static member并不内含在一个class object之中。例如：
&Point3d：：chunkSize；
会获得类型如下都内存地址：
const int*
如果有两个classes，每一个都声明了一个static member freeList，那么当它们都被放在程序的data segment时，就会导致名称冲突。编译器的解决办法是暗中对每一个static data member编码（这种手法被称为：name-mangling），以获得一个独一无二的程序识别代码。
非静态数据成员的存取
非静态数据成员直接存放在每一个class object之中。除非经由明确的（explicit）或暗喻的（implicit）class object，没有办法直接存取它们。只要程序员在一个member function中直接处理一个nonstatic data member，所谓“implicit class object”就会发生。例如下面这段代码：
Point3d Point3d::translate( const Point3d &pt ){
x += pt.x;
y += pt.y;
z += pt.z;
}
表面上所看到的对于x、y、z的直接存取，事实上是经由一个“implicit class object“（由this指针表达）来完成，事实上这个函数的参数为：
//member function的内部转化
Point3d Point3d::translate( Point3d * const this， const Point3d &pt ){
this->x += pt.x;
this->y += pt.y;
this->z += pt.z;
}
欲对一个非静态数据成员进行存取操作，编译器需要把class object的起始地址加上data member的偏移量。比如：
origin._y = 0.0;
地址&origin._y将等于：
&origin + （&Point3d::_y - 1）；
要注意这里都有减1的操作。指向数据成员的指针，其offset值总是被加上1，这样可以使编译系统区分出“没有指向任何数据成员的指针”和“指向第一个数据成员的指针”这两种情况。
每一个非静态数据成员的偏移量（offset）在编译时期即可获知，甚至如果member属于一个base class subobject也是一样，因此，存取一个非静态数据成员，其效率和存取一个C struct member或一个nonderived class的member也是一样的。
现在我们看看虚拟继承。虚拟继承将为“经由base class subobject“存取class members导入一层新的间接性，譬如：
Point3d *pt3d；
Pt3d->_x = 0.0;
其执行效率在_x是一个struct member、一个class member、单一继承、多重继承的情况下都完全相同。但如果_x是一个virtual base class的member，存取速度会慢一些。
“继承“与数据成员
只要继承不要多态（Inheritance without Polymorphism）
假设有如下三个类及其继承关系：
class Concreate1{
public:
//...
private:
int val;
char bit1;
};
class Concreate2 : public Concrete1{
public:
//...
private:
char bit2;
}
class Concreate3 : public Concrete2{
public:
//...
private:
char bit3;
}
Concreate1、Concreate2、Concreate3的对象布局情况：
C++语言保证”出现在派生类中的base class subobject有其完整原样性“。Concrete1内含两个members：val和bit1，加起来5bytes。而一个Concreate1 object实际上用掉8bytes，包括填充用的3bytes，以使object能够符合一部机器的word边界。一般而言，边界调整(alignment)是由处理器来决定的。
然而，Concreate2的bit2实际上却是被放在填补空间所用的3bytes之后，于是其大小变成12bytes，而不是8bytes，其中6bytes浪费在填补空间上。相同的道理使得Concreate3 object的大小是16bytes，其中9bytes用于填补空间。
加上多态（adding Polymorphism）
假设我们要处理一个坐标点，而不打算在乎它是一个Point2d或Point3d实例，那么我们需要在继承关系中提供一个virtual function接口：
class Point2d{
public:
Point2d(float x=0.0, float y=0.0) : _x(x),_y(y){};
virtual float z(){return 0.0;}
virtual void z(float){}
operate+=(const Point2d &rhs){
_x += rhs.x();
_y += rhs.y();
}
protected:
float _x;
float _y;
}
class Point3d : public Point2d{
public:
Point3d(float x=0.0, float y=0.0, float z=0.0) : Point2d(x,y),_z(z){};
virtual float z(){ return _z; }
virtual void z(float newZ){ _z = newZ; }
operate+=(const Point2d &rhs){
Point2d::operator+=(rhs);
_z += rhs.z();
}
protected:
float _z;
}
只有当我们以多态的方式来处理2d或3d坐标点时，在设计之中导入一个virtual接口才显得合理。也就是说，写下这样的代码：
void foo( Point2d &p1, Point2d &p2 ){
//…
P1 += p2;
//…
}
其中p1和p2可能是2d也可能是3d坐标点，这并不是以前任何设计所能支持的。这样的弹性，当然正是面向对象程序设计的中心。同时，支持这样的弹性，也给我们的Point2d class带来空间和存取时间的额外负担：
n 导入一个和Point2d有关的virtual table，用来存放它所声明的每一个virtual functions的地址。
n 在每一个class object中导入一个vptr，提供执行期的链接，使每一个object能够找到相应的virtual table。
n 加强constructor，使它能够为vptr设定初值，让它指向class所对应的virtual table。这可能意味着在derived class和每一个base class的constructor中，重新设定vptr的值。其情况视编译器的优化的积极性而定。
n 加强destructor，使它能够抹消“指向class之相关virtual table“的vptr。要知道，vptr很可能已经在derived class destructor中被设定为derived class的virtual table地址。记住，desturctor的调用次序是反向的：从derived class到base class。
下图显示了Point2d和Point3d加上了virtual function之后的继承布局。此图把vptr放在base class的尾端：
多重继承（Multiple Inheritance）
多重继承不像单一继承，不容易模塑出其模型。多重继承的复杂度在于derived class和其上一个base class乃至于上上一个base class…之间的“非自然“关系。例如，考虑下面这个多重继承所获得的class Vertex3d：
class Point2d{
public:
//...
protected:
float _x;
float _y;
}
class Point3d : public Point2d{
public:
//...
ptotected:
float _z;
}
class Vertex{
public:
//...
protected:
Vertex *next;
}
class Vertex3d : public Point3d, public Vertex{
public:
//...
protected:
float mumble;
}
至此，Point2d、Point3d、Vertex、Vertex3d的继承关系如下图所示：
虚拟继承（Virtual Inheritance）
下图是Point2d、Point3d、Vertex、Vertex3d的继承体系：
一般而言，虚基类最有效的一种运用形式就是：一个抽象的虚基类，其中没有任何数据成员。
参考资料：
《深度探索C++对象模型》