C++ Tricks 2.5 I386平台的边界对齐(Align)

farseerfc.wordpress.com 导入

2.5 I386平台的边界对齐(Align)

首先提问,既然I386上sizeof(int)==4、sizeof(char)==1,那么如下结构(struct)A的sizeof是多少?

struct A{int i;char c;};

答案是sizeof(A)==8……1+5=8?

呵呵,这就是I386上的边界对齐问题。我们知道,I386上有整整4GB的地址空间,不过并不是每一个字节上都可以放置任何东西的。由于内存总线带宽等等的技术原因,很多体系结构都要求内存中的变量被放置于某一个边界的地址上。如果违反这个要求,重则导致停机出错,轻则减慢运行速度。对于I386平台而言,类型为T的变量必须放置在sizeof(T)的整数倍的地址上,char可以随便放置,short必须放在2的整数倍的地址上,int必须放在4的整数倍的地址上,double必须放在8的整数倍的地址上。如果违反边界对齐要求,从内存中读取数据必须进行两次,然后将独到的两半数据拼接起来,这会严重影响效率。

由于边界对齐问题的要求,在计算struct的sizeof的时候,编译器必须算入额外的字节填充,以保证每一个变量都能自然对齐。比如如下声明的struct:

struct WASTE

{

char c1;

int i;

char c2;

}

实际上相当于声明了这样一个结构:

struct WASTE

{

char c1;

char _filling1 [3];//三个字节填充,保证下一个int的对齐

int i;

char c2;

char _filling2 [3];//又三个字节填充

}

值得注意的是尾部的3个字节填充,这是为了可以在一个数组中声明WASTE变量,并且每一个都自然对齐。因为有了这些填充,所以sizeof(WASTE)==12。这是一种浪费,因为只要我们重新安排变量的声明,就可以减少sizeof:

struct WASTE

{

int i;

char c1,c2;

}

像这样的安排,sizeof就减少到8,只有2个字节的额外填充。为了与汇编代码相兼容,C语言语法规定,编译器无权擅自安排结构体内变量的布局顺序,必须从左向右逐一排列。所以,妥当安排成员顺序以避免内存空间的浪费,就成了我们程序员的责任之一。一般的,总是将结构体的成员按照其sizeof从大到小排列,double在最前,char在最后,这样总可以将结构的字节填充降至最小。

C++继承了C语言关于结构体布局的规定,所以以上的布局准则也适用于C++的class的成员变量。C++进一步扩展了布局规定,同一访问区段(private、public、protected)中的变量,编译器无权重新排列,不过编译器有权排列访问区段的前后顺序。基于这个规则,C++中有的程序员建议给每一个成员变量放在单独区段,在每一个成员声明之前都加上private:、public:、protected:标志,这可以最大限度的利用编译器的决策优势。

在栈中按顺序分配的变量,其边界也受到对齐要求的限制。与在结构中不同的是,栈中的变量还必须保证其后续变量无论是何种类型都可以自由对齐,所以在栈中的变量通常都有平台相关的对齐最小值。在MSVC编译器上,这个最小值可以由宏_INTSIZEOF(T)查询:

#define _INTSIZEOF(T) ( (sizeof(T) + sizeof(int) - 1) & ~(sizeof(int) - 1) )

_INTSIZEOF(T)会将sizeof(T)进位到sizeof(int)的整数倍。

由于在栈中分配变量使用_INTSIZEOF而不是sizeof,在栈上连续分配多个小变量(sizeof小于int的变量)会造成内存浪费,不如使用结构(struct)或数组。也就是说:

char c1,c2,c3,c4;//使用16字节

char c[4];//使用4字节

当然,使用数组的方法在访问数组变量(比如c[1])时有一次额外的指针运算和提领(dereference)操作,这会有执行效率的损失。这又是一种空间(内存占用)vs时间(执行效率)的折中,需要程序员自己根据情况权衡利弊。

sizeof的大小可能比我们预期的大,也可能比我们预期的小。对于空类:

class Empty {};

在通常情况下,sizeof(Empty)至少为1。这是因为C++语法规定,对于任何实体类型的两个变量,都必须具有不同的地址。为了符合语法要求,编译器会给Empty加入1字节的填充。所以sizeof()的值不可能出现0的情况。可是对于以下的类声明:

class A:public Empty{vitual ~A(){}};

sizeof(A)有可能是6,也有可能是5,也有可能是4!必不可少的四个字节是一个指向虚函数表的指针。一个可能有的字节是Empty的大小,这是是因为编译器在特定情况下会将Empty视作一个“空基类”,从而实施“空基类优化”,省掉那毫无作用的一字节填充。另一个字节是A的一字节填充,因为从语法上讲,A没有成员声明,理应有1字节填充,而从语义上讲,编译器给A的声明加入了一个指向虚函数表的指针,从而A就不再是一个“空类”,是否实施这个优化,要看编译器作者对语法措词的理解。也就是说,sizeof也会出现4+1+1=4的情况。具体要看编译器有没有实施“空基类优化”和“含虚函数表的空类优化”。

结构和类的空间中可能有填充的字节,这意味着填充字节中可能有数值,虽然这数值并不影响结构的逻辑状态,但是它也可能不知不觉中影响到你。比如说,你手头正好有一组依赖于底层硬件(比如多处理器)的函数,他们在操纵连续字节时比手动编码要快很多,而你想充分利用这种硬件优势:

bool BitCompare(void* begin,void* end,void* another);

这个函数将区间[begin,end)之间的字节与another开始的字节相比较,如果有一位不同就返回false,否则返回true。

比如你想将这个函数用于你自己的类的operator==中,这样可以利用硬件加快速度。不过你在动手前要充分考虑,你的class是否真的要比较每一位。如果在类的成员中存在编译器填充的字节数,那么应用以上的函数就是不正确的,因为填充的字节中可以有不同的值。为了保证你可以用Bitwise Compare,你必须确保填充的字节中的值也是相同的。这不仅要求你在类的构造函数中初始化类的每一bit而不是每一个成员,也要求你在复制初始化和复制赋值函数中也同时保证bitwise copy语义,而不是编译器默认产生的memberwise语义。当然,你可能通过与BitCompare一同提供的BitCopy来完成这个艰巨的任务。

请用你的 GitHub 账户登录并在这篇文章的 Issue 页下留言
comments powered by Disqus