C++ 对象模型

先交代最基本的原则。

程序的内存分配:

一个由C/C++编译的程序占用的内存分为以下几个部分:
1、栈区(stack)— 由编译器自动分配释放,存放函数的参数值,局部变量的值等。其操作方式类似于数据结构中的栈。
2、堆区(heap) — 一般由程序员分配释放,若程序员不释放,程序结束时可能由OS(操作系统)回收。注意它与数据结构中的堆是两回事,分配方式倒是类似于链表。
3、全局区(静态区)(static)—,全局变量和静态变量的存储是放在一块的,初始化的全局变量和静态变量在一块区域,未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。程序结束后由系统释放。
4、文字常量区 —常量字符串就是放在这里的。程序结束后由系统释放。
5、程序代码区—存放函数体的二进制代码。

对齐和包裹

简单的内存布局原则:成员变量按其被声明的顺序排列,按具体实现所规定的对齐原则在内存地址上对齐。

1
2
3
4
5
6
7
8
struct InefficientPacking{
U32 mU1; //32
F32 mF2; //32
U8 mB3; //8
I32 mI4; //32
bool mB5; //8
char* mP6; //32
}

此时结构的大小是24字节。

混合数据成员大小,导致低效的struct包裹。

为什么会留下空隙?事实上每种数据类型有其天然的对齐方式,供CPU高效的从内存读/写,对齐是指,其内存地址是否为对齐字节大小的倍数(通常是2的幂)。

对齐是重要的,现在许多处理器实际上只能正常的读/写已对齐的数据块,例如,程序要求从0x6A341174地址读取32位整数,内存控制器便可愉快的载入数据,因为该地址是4字节对齐的。
如果要从0x6A341173载入32位整数,内存控制器需要读入两个4字节块,一块是0x6A341170,一块是0x6A341174。之后通过掩码和移位操作取得32位整数的两部分,再用逻辑OR操作把两部分合并。

一些微处理器甚至不做这些处理。若读/写非对齐数据,读出来或者写进去的可能只是随机数,甚至可能程序直接崩溃(比如PS2)。

作为一个良好的经验法则,数据类型应该需要其字节大小对齐,比如32位值通常需要4字节对齐,16位值通常需要2字节对齐,8位值通常可以存于任何地址(1字节对齐)。

在支持SIMD矢量数学的CPU中,每个SIMD寄存器含32个4字节浮点数,共128位(16字节),即16字节对齐。

所以,对于上述的InefficientPacking结构,可以进行重新排列

1
2
3
4
5
6
7
8
struct InefficientPacking{
U32 mU1; //32 (4字节对齐)
F32 mF2; //32 (4字节对齐)
char* mP6; //32 (4字节对齐)
I32 mI4; //32(4字节对齐)
bool mB5; //8 (1字节对齐)
U8 mB3; //8 (1字节对齐)
}

此时总大小为20字节大小,并不是18,因为末端有2个字节的填充。

可以在结构末端填充两个字节,使整个结构的浪费的空间更为清晰。

1
2
3
4
5
6
7
8
9
struct InefficientPacking{
U32 mU1; //32 (4字节对齐)
F32 mF2; //32 (4字节对齐)
char* mP6; //32 (4字节对齐)
I32 mI4; //32(4字节对齐)
bool mB5; //8 (1字节对齐)
U8 mB3; //8 (1字节对齐)
U8 _pad[2] ; // 明确的填充
}

还有一点,关于大小,抛开虚函数和虚继承,C++类实例的大小完全取决于一个类及其基类的成员变量!成员函数基本上不影响类实例的大小。

1
2
3
4
5
6
7
8
9
10
11
12
13
struct B {
public :
int bm1;
protected :
int bm2;
private :
int bm3;
static int bsm; //存在静态区
void bf();
static void bsf();
typedef void * bpv;
struct N { };
};

在单继承上的分布

基类

1
2
3
4
struct C {
int c1;
void cf();
};

派生类

1
2
3
4
struct D : C {
int d1;
void df();
};

或者这么看
在VS类->属性->C/C++ –> 命令行–> 其他选项

  • /d1 reportAllClassLayout 查看所有类
  • /d1 reportSingleClassLayoutXXX(XXX为类名)
1
2
3
4
5
6
7
class D size(8):
+---
0 | +--- (base class C)
0 | | c1
| +---
4 | d1
+---

派生类要保留基类的所有属性和行为,自然地,每个派生类的实例都包含了一份完整的基类实例数据。
几乎所有C++厂商默认在单继承类层次下,每一个新的派生类都简单地把自己的成员变量添加到基类的成员变量之后,这样只要有了派生类D的指针,不需要去计算偏移量了。

比如:

1
2
3
D* pd;
pd->c1; // *(pd + dDC + dCc1); // *(pd + dCc1);
pd->d1; // *(pd + dDd1);

  • 当访问基类成员c1时,计算步骤本来应该为“pd+dDC+dCc1”,即为先计算D对象和C对象之间的偏移,C对象指针与成员变量c1之间的偏移量。由于dDC恒定为0,所以直接表达为pd+dCc1。
  • 当访问派生类成员d1时,直接计算偏移量。

多重继承上的分布

定义一个结构E

1
2
3
4
5
struct E
{
int e1 = 5;
void ee();
};

再定义一个结构F,让他继承C、E

1
2
3
4
5
struct F :C, E
{
int f1 = 6;
void ff();
};

此时看一下内存布局

1
2
3
4
5
6
7
8
9
10
class F size(12):
+---
0 | +--- (base class C)
0 | | c1
| +---
4 | +--- (base class E)
4 | | e1
| +---
8 | f1
+---

多继承的成员变量地址计算:

1
2
3
4
F* pf;
pf->c1; // *(pf + dFC + dCc1); // *(pf + dFc1);
pf->e1; // *(pf + dFE + dEe1); // *(pf + dFe1);
pf->f1; // *(pf + dFf1);

与单继承相同的是,F实例拷贝了每个基类的所有数据。 与单继承不同的是,在多重继承下,内嵌的两个基类C,E,他们的对象指针不可能全都与派生类对象指针相同:

输出一看:

1
2
3
4
5
6
7
8
9
10
11
int main()
{
F f;
std::stringstream ss;
ss << "F实例地址:" << &f << "\n" //0073FBB4
<< "转到基类C:" << (void*)(C*)&f << "\n" //0073FBB4
<< "转到基类E:" << (void*)(E*)&f; //0073FBB8
std::cout << ss.str() << std::endl;
system("pause");
return 0;
}

具体的编译器实现可以自由地选择内嵌基类和派生类的布局。 VC++ 按照基类的声明顺序 先排列基类实例数据,最后才排列派生类数据。 当然,派生类数据本身也是按照声明顺序布局的(本规则并非一成不变 ,我们会看到,当一些基类有虚函数而另一些基类没有时,内存布局并非如此)。

虚继承上的分布

虚继承的作用:

如果经理类和工人类都继承自“雇员类”,将会发生什么?

1
2
3
4
struct Employee { ... };
struct Manager : Employee { ... };
struct Worker : Employee { ... };
struct MiddleManager : Manager, Worker { ... };

如果经理类和工人类都继承自雇员类,很自然地,它们每个类都会从雇员类获得一份数据拷贝。

  • 成员变量名的二义性,Manager继承至Employee,有工资属性,Worker继承至Employee,也有工资属性,那么MiddleManager实例的工资属性指向的是哪个?
  • 两个实例,如果不作特殊处理,一线经理类的实例将含有两个雇员类实例,它们分别来自两个雇员基类 。
  • 空间浪费,如果雇员类成员变量不多,问题不严重;如果成员变量众多,则那份多余的拷贝将造成实例生成时的严重开销。
  • 数据不安全,这两份不同的雇员实例可能分别被修改,比如一线经理类强转成Worker类,此时修改的工资属性,造成数据的不一致。

可以打开VS写个示例看看:

1
2
3
4
5
6
7
8
9
struct C{ int c1 =0;}
struct D : C{...}
struct DD : C{...}
struct FF : D,DD{...}
int main(){
FF ff;
DD* dd = (DD*)&ff;
dd->c1 = 999;
}

输出:

依然是上面的实例,稍微改一改

1
2
3
4
5
6
7
8
9
struct C{ int c1 =0;}
struct D : virtual C{...}
struct DD : virtual C{...}
struct FF : D,DD{...}
int main(){
FF ff;
DD* dd = (DD*)&ff;
dd->c1 = 999;
}

这样,操作的其实就是同一份内存了。

虚继承的内存分布:

在单继承和多重继承的情况下,内嵌的基类实例地址比起派生类实例地址来,要么地址相同(单继承,以及多重继承的最靠左基类) ,要么地址相差一个固定偏移量(多重继承的非最靠左基类) 。

然而,当虚继承时,一般说来,派生类地址和其虚基类地址之间的偏移量是不固定的,因为如果这个派生类又被进一步继承的话,最终派生类会把共享的虚基类实例数据放到一个与上一层派生类不同的偏移量处。

定义G虚继承于C

1
2
3
4
5
struct G :virtual C
{
int g1 =9;
void gg();
};

1
2
3
4
5
6
7
8
9
10
11
class G size(12):
+---
0 | {vbptr}
4 | g1
+---
+--- (virtual base C)
8 | c1
+---
G::$vbtable@:
0 | 0
1 | 8 (Gd(G+0)C)

GdGvbptrG 是指在G对象中,G对象指针与G虚基类表的指针偏移量,自然为0;
GdGvbptrC 是指在G对象中,G对象指针与C虚基类表的指针偏移量,为8

同理,如果让H虚继承于C,也会得到类似的结果。

1
2
3
4
struct H : virtual C{
int h1 = 10;
void hh();
}


1
2
3
4
5
6
7
8
9
10
11
class H size(12):
+---
0 | {vbptr}
4 | h1
+---
+--- (virtual base C)
8 | c1
+---
H::$vbtable@:
0 | 0
1 | 8 (Hd(H+0)C)

此时再定义一个I

1
2
3
4
struct I : G, H {
int i1;
void _if();
};

或者直接看你下面的内存布局

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class I size(24):
+---
0 | +--- (base class G)
0 | | {vbptr}
4 | | g1
| +---
8 | +--- (base class H)
8 | | {vbptr}
12 | | h1
| +---
16 | i1
+---
+--- (virtual base C)
20 | c1
+---
I::$vbtable@G@:
0 | 0
1 | 20 (Id(G+0)C) //G ~ I 为0 G ~ C 为20
I::$vbtable@H@:
0 | 0
1 | 12 (Id(H+0)C) //H ~ H 为0 H ~ C 为12

看内存布局图,就很容易计算虚继承中成员变量的地址:

1
2
3
4
5
6
7
I* pi; //I实例地址
pi->c1; // *(pi + (I~G) + (G~C) + dCc1);
pi->g1; // *(pi + dIG + dGg1); // *(pi + dIg1);
pi->h1; // *(pi + dIH + dHh1); // *(pi + dIh1);
pi->i1; // *(pi + dIi1);
I i;
i.c1; // *(&i + IdIC + dCc1); // *(&i + IdIc1); //当声明了一个对象实例,用点“.”操作符访问虚基类成员c1时,由于编译时就完全知道对象的布局情况,所以可以直接计算偏移量。

从上述例子中可以发现:

  • 在VC++ 中,对每个继承自虚基类的类实例,将增加一个隐藏的“虚基类表指针”(vbptr) 成员变量,从而达到间接计算虚基类位置的目的。该变量指向一个全类共享的偏移量表,表中项目记录了对于该类而言,“虚基类表指针”与虚基类之间的偏移量。

总结下继承和虚继承:

  • 1、首先排列非虚继承的基类实例;
  • 2、有虚基类时,为每个虚基类增加一个隐藏的vbptr,除非已经从非虚继承的类那里继承了一个vbptr;
  • 3、排列派生类的新数据成员;
  • 4、在实例最后,排列每个虚基类的一个实例。

该布局安排使得虚基类的位置随着派生类的不同而“浮动不定”,但是,非虚基类因此也就凑在一起,彼此的偏移量固定不变。

强制转换

非虚继承

如果没有虚基类的问题,将一个指针强制转化为另一个类型的指针代价并不高昂。如果在要求转化的两个指针之间有“基类-派生类”关系,编译器只需要简单地在两者之间加上或者减去一个偏移量即可(并且该量还往往为0)。

用上面定义的几个类说明:

1
2
3
F* pf;
(C*)pf; // (C*)(pf ? pf + dFC : 0); // (C*)pf;
(E*)pf; // (E*)(pf ? pf + dFE : 0);

虚继承

当继承关系中存在虚基类时,强制转化的开销会比较大。具体说来,和访问虚基类成员变量的开销相当。

1
2
3
4
I* pi;
(G*)pi; // (G*)pi;
(H*)pi; // (H*)(pi ? pi + dIH : 0);
(C*)pi; // (C*)(pi ? (pi+dIGvbptr + (*(pi+dIGvbptr))[1]) : 0); //dIGvbptr[1] 虚基类表的第二个,这里是指在I实例中,G到C的偏移量

一般说来,当从派生类中访问虚基类成员时,应该先强制转化派生类指针为虚基类指针,然后一直使用虚基类指针来访问虚基类成员变量。这样做,可以避免每次都要计算虚基类地址的开销。 见下例。

1
2
/* before: */ … pi->c1 … pi->c1 …
/* faster: */ C* pc = pi; … pc->c1 … pc->c1 … //先抓出来

成员函数

如代码

1
2
3
4
5
struct P {
int p1;
void pf(); // new
virtual void pvf(); // new
};

P有一个非虚成员函数pf(),以及一个虚成员函数pvf()。

很明显,虚成员 函数造成对象实例占用更多内存空间,因为虚成员函数需要虚函数表指针。这里要特别指出的是,声明非虚成员函数不会造成任何对象实例的内存开销。

1
2
3
void P::pf() { // void P::pf([P *const this])
++p1; // ++(this->p1); 隐式的调用了this
}

注意成员变量访问也许比看起来要代价高昂一些,因为成员变量访问通过this指针进行,在有的继承层次下,this指针需要调整,所以访问的开销可能会比较大。然而,从另一方面来说,编译器通常会把this指针缓存到寄存器中,所以,成员变量访问的代价不会比访问局部变量的效率更差。

覆盖成员函数

和成员变量一样,成员函数也会被继承。与成员变量不同的是,通过在派生类中重新定义基类函数,一个派生类可以覆盖,或者说替换掉基类的函数定义。覆盖是静态 (根据成员函数的静态类型在编译时决定)还是动态(通过对象指针在运行时动态决定),依赖于成员函数是否被声明为“虚函数”。

1
2
3
4
5
6
7
struct Q : P {
int q1;
void pf(); // overrides P::pf
void qf(); // new
void pvf(); // overrides P::pvf 重写了P::pvf()
virtual void qvf(); // new
};

P::vfptr此时的对应的是虚函数表,指向的是Q::pvf Q::qvf 这两个虚函数

非虚函数调用

1
2
3
4
5
P p; P* pp = &p; Q q; P* ppq = &q; Q* pq = &q;
pp->pf(); // pp->P::pf(); // P::pf(pp);
ppq->pf(); // ppq->P::pf(); // P::pf(ppq); 不是调用的Q::pf()
pq->pf(); // pq->Q::pf(); // Q::pf((Q*)pq); (错误!)
pq->qf(); // pq->Q::qf(); // Q::qf(pq);

对于非虚的成员函数来说,调用哪个成员函数是在编译时,根据“->”操作符左边指针表达式的类型静态决定的(编译时就决定了的)。特别地,即使ppq指向Q的实例,ppq->pf()仍然调用的是P::pf(),因为ppq被声明为“P*”。(注意,“->”操作符左边的指针类型决定隐藏的this参数的类型。)

虚函数的调用

对于虚函数 调用来说,调用哪个成员函数在运行时决定。不管“->”操作符左边的指针表达式的类型如何,调用的虚函数都是由指针实际指向的实例类型所决定 。比如,尽管ppq的类型是P*,当ppq指向Q的实例时,调用的仍然是Q::pvf()。

1
2
3
pp->pvf(); // pp->P::pvf(); // P::pvf(pp);
ppq->pvf(); // ppq->Q::pvf(); // Q::pvf((Q*)ppq);
pq->pvf(); // pq->Q::pvf(); // Q::pvf((P*)pq); (错误!)

为什么有虚函数表

为了实现这种动态的机制,引入了隐藏的vfptr 成员变量。 一个vfptr被加入到类中(如果类中没有的话),该vfptr指向类的虚函数表(vftable)。类中每个虚函数在该类的虚函数表中都占据一项。每项保存一个对于该类适用的虚函数的地址。因此,调用虚函数的过程如下:取得实例的vfptr,通过vfptr得到虚函数表的一项;通过虚函数表该项的函数地址间接调用虚函数。 也就是说,在普通函数调用的参数传递、调用、返回指令开销外,虚函数调用还需要额外的开销

多重继承的虚函数

VC++的实现方式是,保证任何有虚函数的类的第一项永远是vfptr。在多重继承时,虽然在右边,然而有vfptr的基类放到左边没有vfptr的基类的前面

1
2
3
4
5
struct R {
int r1;
virtual void pvf(); // new
virtual void rvf(); // new
};

1
2
3
4
5
6
struct S : P, R {
int s1;
void pvf(); // overrides P::pvf and R::pvf
void rvf(); // overrides R::rvf
void svf(); // new
};

从左至右,虚函数表排第一。

在多重继承下,靠右的基类R,其实例的地址和P与S不同。 S::pvf覆盖了P::pvf()和R::pvf(),S::rvf()覆盖了R::rvf()。

实际代码中对虚函数的调用过程如下:

1
2
3
4
S s; S* ps = &s;
((P*)ps)->pvf(); // (*(P*)ps)->P::vfptr[0])((S*)(P*)ps)
((R*)ps)->pvf(); // (*(R*)ps)->R::vfptr[0])((S*)(R*)ps)
ps->pvf(); // one of the above; calls S::pvf()

1、因为S::pvf()覆盖了P::pvf()和R::pvf(),在S的虚函数 表中,相应的项也应该被覆盖。

2、但是,不光可以用P,还可以用R来调用pvf()。

3、问题出现了:R的地址与P和S的地址不同。表达式 (R)ps与表达式(P)ps指向类布局中不同的位置。

4、因为函数S::pvf希望获得一个S作为隐藏的this指针参数,虚函数必须把R 转化为 S*。

5、因此,在S对R虚函数表的拷贝中,pvf函数对应的项,指向的是一个调整块的地址,该调整块使用必要的计算,把R转换为需要的S

  • 这就是“thunk1: this-= sdPR; goto S::pvf”干的事。先根据P和R在S中的偏移,调整this为P,也就是S,然后跳转到相应的虚函数处执行。

虚继承下的虚函数

如下,T虚继承P,覆盖P的虚成员函数,声明了新的虚函数。

1
2
3
4
5
struct T : virtual P {
int t1;
void pvf(); // overrides P::pvf
virtual void tvf(); // new
};

实现T::pvf()

1
2
3
4
5
void T::pvf()
{
++p1; // ((P*)this)->p1++; // vbtable lookup!
++t1; // this->t1++;
}

内存分布如下:

在VS调试下:

如果采用在基类虚函数表末尾添加新项的方式,则访问虚函数总要求访问虚基类。

在VC++中,为了避免获取虚函数表时,转换到虚基类P的高昂代价,T中的新虚函数通过一个新的虚函数表获取 ,从而带来了一个新的虚函数表指针。该指针放在T实例的顶端。

即使是在虚函数中,访问虚基类的成员变量也要通过获取虚基类表的偏移,实行计算来进行。这样做之所以必要,是因为虚函数可能被进一步继承的类所覆盖,而进一步继承的类的布局中,虚基类的位置变化了。比如:

1
2
3
struct U : T {
int u1;
};

内存分布如下:

在VS调试下:

在U增加了一个成员变量,从而改变了P的偏移。

由于P是虚基类,T中有一个P,P自己也有一份,当然他们的地址是相同的。

因为VC++实现中,T::pvf()接受的是嵌套在T中的P的指针,所以,需要提供一个调整块,把this指针调整到T::t1之后(该处即是P在T中的位置)。

简单的说,就是存在通过强转导致的U::pvf(),T::pvf()这种情况,导致不知道具体调用那个函数,需要调整块。

构造函数和析构函数

最坏的情况下,构造函数:

  • 如果是“最终派生类”,初始化vbptr成员变量,调用虚基类的构造函数;
  • 调用非虚基类的构造函数
  • 调用成员变量的构造函数
  • 初始化虚函数表成员变量
  • 执行构造函数体中,程序所定义的其他初始化代码

析构函数:

  • 合成并初始化虚函数表成员变量
  • 执行析构函数体中,程序定义的其他析构代码
  • 调用成员变量的析构函数(按照相反的顺序,沿子类到基类)
  • 调用直接非虚基类的析构函数(按照相反的顺序)
  • 如果是“最终派生类”,调用虚基类的析构函数(按照相反顺序)

虚析构函数的作用

假如A是B的父类,

A* p = new B();

如果析构函数不是虚拟的,那么,你后面就必须这样才能安全的删除这个指针:

delete (B*)p;

但如果析构函数是虚拟的,就可以在运行时动态绑定到B类的析构函数,直接:

delete p;

就可以了。这就是虚析构函数的作用。

虚析构函数和普通的虚函数内存分布机制相同。

虚析构函数的特别之处在于:当类实例被销毁时,虚析构函数被隐含地调用。调用地(delete发生的地方)虽然不知道销毁的动态类型,然而,要保证调用对该类型合适的delete操作符。

1
2
3
struct V {
virtual ~V();
};
1
2
3
struct W : V {
operator delete ();
};
1
2
3
4
5
6
V* pv = new V;
delete pv; // pv->~V::V(); // use ::operator delete() V没有定义delete操作符,使用函数库的delete
pv = new W;
delete pv; // pv->~W::W(); // use W::operator delete() 动态绑定到 W的析构函数,W默认的析构函数调用{delete this;} 指向的是W实例,调用的也是W的delete
pv = new W;
::delete pv; // pv->~W::W(); // use ::operator delete() 使用全局范围标识符,显示调用函数库delete

数组

堆上分配空间的数组使虚析构函数进一步复杂化。问题变复杂的原因有两个:

  • 堆上分配空间的数组,由于数组可大可小,所以,数组大小值应该和数组一起保存。因此,堆上分配空间的数组会分配额外的空间来存储数组元素的个数;

  • 当数组被删除时,数组中每个元素都要被正确地释放,即使当数组大小不确定时也必须成功完成该操作。然而,派生类可能比基类占用更多的内存空间,从而使正确释放比较困难。

1
2
3
4
5
struct WW : W { int w1; };
pv = new W[m];
delete [] pv; // delete m W's (sizeof(W) == sizeof(V))
pv = new WW[n];
delete [] pv; // delete n WW's (sizeof(WW) > sizeof(V))

WW从W继承,增加了一个成员变量,因此,WW占用的内存空间比W大。然而,不管指针pv指向W的数组还是WW的数组,delete[]都必须正确地释放WW或W对象占用的内存空间。

在MSC++中,delete[]是用另一个编译器生成的虚析构帮助函数来完成。该函数被称为“向量delete析构函数”(因其针对特定的类定制,比如WW,所以,它能够遍历数组的每个元素,调用对每个元素适用的析构函数)。

参考:
http://blog.jobbole.com/108457/
http://lib.csdn.net/article/cplusplus/63247