EBC英文全称为“Empty Base Class”，中文全称“空基类”。那什么是空基类呢？简单的
说就是没有任何数据成员的类就称之为空基类。也就是EBC的类定义中不包含任何数据成员，
那么这样一来可能大家会认为一个EBC的尺寸（sizeof）因该是0，确实按照定义而言因该是
这样的，但是我们知道即使是一个EBC也可以定义一个对象，而对象是一个运行时的内存实
体，也就是说对象是必须要能够通过内存地址进行区分的，那么即使是一个EBC类的对象也
必须占有内存空间，这样一来一般情况下编译器会将EBC的尺寸看作1字节，也就是让其对象
占用一个字节的空间，这样一来既可以达到对象的地址鉴别，同时也是一个比较节约内存的
分配策略。例如：
#include <cassert>
struct CEmptyClass {};
int main( int argc, char *argv[] )
{
CEmptyClass emptyObject;
assert( sizeof( CEmptyClass ) == 1 );
assert( sizeof( emptyObject ) == 1 );
return 0;
}
通过上面的讨论已经知道什么是空基类了，那么下面这些的类属于空基类么？
struct CEmptyClass1 { CEmptyClass1() {}; ~CEmptyClass1() {} };
struct CEmptyClass2 { void print() {} };
struct CEmptyClass3 { virtual ~CEmptyClass3() {} };
struct CEmptyClass4 : public CEmptyClass1 {};
struct CEmptyClass5 : public CEmptyClass3 {};
struct CEmptyClass6 { uint32_t v; };
struct CEmptyClass7 : public CEmptyClass6 {};
struct CEmptyClass10 : virtual public CEmptyClass1 {};
struct CEmptyClass11 : virtual public CEmptyClass1 {};
struct CEmptyClass12 : public CEmptyClass10, public CEmptyClass11 {};
根据上面的定义“没有任何数据成员”，这里的数据成员不仅仅包括类的成员变量，同
时还包括编译器为了某种目的引入的数据成员，比如：为了支持多态而引入的虚指针vptr、
为了支持虚继承而引入的必要的虚基类指针等，而且还包括从基类继承直接或间接继承而
来的上述的数据成员。那么这样一来，上面的问题就很清楚了，CEmptyClass3、
CEmptyClass5、CEmptyClass6、CEmptyClass7、CEmptyClass10、CEmptyClass11、
CEmptyClass12就不是EBC了，而CEmptyClass1、CEmptyClass2、CEmptyClass4仍然是EBC。
那么可能有些人会看出来如果这样的一个类，他的尺寸是多少呢？
struct CEmptyClass20 : public CEmptyClass1, public CEmptyClass2 {};
struct CEmptyClass21 : public CEmptyClass1 { uint32_t v; };
struct CEmptyClass22 : public CEmptyClass1, public CEmptyClass2 { uint32_t v; };
struct CEmptyClass23 : public CEmptyClass1, public CEmptyClass6 {};
在VC++8和g++3.4.x（g++4以上版本编译上述代码出现编译错误）版本时所出现的结果
会比较出人意料：
sizeof( CEmptyClass20 ) == 1
sizeof( CEmptyClass21 ) == 4
sizeof( CEmptyClass22 ) == 8
sizeof( CEmptyClass23 ) == 4
为什么会出现上述的结果呢？这个主要是因为编译器实施EBO所致的。那什么是EBO呢？
EBO英文全称“Empty Base Class Optimize”，中文全称“空基类优化”。其实就是在EBC类被
继承的是时候由于空基类没有任何数据成员所以可以让其在子类的对象布局中优化掉EBC所
占用的那一个字节，用子类对象的首地址作为EBC的子对象的首地址（也就是this指针）。
需要注意的是并不是每一次EBO优化都回被成功的实施，有时候由于继承关系和对象布局
问题会导致无法实施EBO优化，从而导致EBC的子对象必然会在子类的对象中占用一定的空
间（一般会大于1个字节，主要是因为内存对齐的需要）。
我们来分析上面的的4个继承类的尺寸现象问题：
1. sizeof( CEmptyClass20 ) == 1；CEmptyClass20类继承于两个EBC类，同时自己也
是一个EBC类，所以编译器会自动地优化掉两个基类的子对象的内存空间，所以尺寸
仍然是1字节；
2. sizeof( CEmptyClass21 ) == 4；CEmptyClass21类继承于一个EBC类，同时自己也
包含一个4字节的成员变量，此时可以成功的实施EBO优化将EBC的内存空间优化掉；
3. sizeof( CEmptyClass22 ) == 8；CEmptyClass22类继承于两个EBC类，同时自己也
包含一个4字节的成员变量，按一般常理而言此时编译器应该可以优化掉两个EBC所
需要的内存空间，从而使得其尺寸仅仅只有4个字节，可是为什么会有8个字节呢？
也就是说此时编译器并没有实施EBO优化，使得每一个EBC子对象都回占用1个字节的
内存，从而占用2字节内存，再加上32位系统下的对齐需要填充2个字节已形成4字节
对齐，所以会导致其成为8个字节；
4. sizeof( CEmptyClass23 ) == 4；CEmptyClass23类继承于一个EBC类和一个非EBC类，
而CEmptyClass6因为含有一个vptr所以具有4字节尺寸，而CEmtpyClass23内本身不
包含任何数据成员，通过EBO优化掉第一个EBC的内存，所以其尺寸就是4字节。
通过上面的分析可以看出来，一般情况下如果子类的基类列表中只有一个EBC时时一定
可以成功实施EBO优化的，而如果出现多继承于多个EBC时会根据子类是否包含数据成员而
确定能够实施EBO优化，同时会和编译器的优化策略具有较大的关系。
在boost库中有非常多的机制依赖于EBO优化，比如：nocopyable等，充分的理解EBC/EBO
并利用其所具有的内存优化特征，会在类继承体系中引入行为/策略的同时不导致对象的膨胀。
本文转帖，原文地址：http://blog.csdn.net/zhangjinjing/archive/2009/05/14/4183207.aspx