关于结构体的字节对齐是什么,就不赘述,再此附上一篇文章,介绍字节对齐:http://www.linuxsong.org/2010/09/c-byte-alignment/
这里的结构体字节对齐的数据类型都是基本数据类型,如果结构体的定义中含有结构体成员呢?
网上有很多人写博客谈到这个问题,都认为该结构体成员应该被看做一个整体,按照整体的字节数来进行字节对齐,选择首地址。但是经过测试,这种说法是不对的。
struct s1{
char c1;
char c2;
char c3;
char c4;
}; struct s2{
char a;
struct s1 s;
};
对于上述代码,显然sizeof(struct s1) = 4。如果将struct s1看做整体,来进行字节对齐的话,sizeof(struct s2)应该是等于8。但是该段代码在gcc和VS2010下测试的结果都是5。
所以,s2的内存布局如下
s2 : char | char char char char |
s的首地址并非为4,而是char类型长度的整数倍
同样,对于结构体:
struct S1
{
char a;
short b;
}; struct S2
{
char a;
struct S1 s;
};
上述代码中,sizeof(struct S1) = 4,而sizeof(struct S2) = 6。
S2的内存布局是:
S2 : char **** | char **** short short
s的首地址并非为4,而是short类型长度的整数倍,结构体S2的长度并非结构体S1长度的整数倍,而是short类型长度的整数倍
相对的,我们可以看一下结构体:
struct S
{
char a;
char b;
short c;
};
sizeof(S) = 4。
其内存布局为:
S : char char short short
对比S2和S,我们看到,S2中的s结构体成员确实是仍按它作为S1结构体的整体(占用4个字节)来布局的。
那么我们可以得出这情形下的字节对齐问题的结论:
1)结构体中的结构体成员,是按照原结构体的内存布局在新结构体中进行布局的;
2)结构体中的结构体成员,其内存首地址为该成员中最长数据类型的整数倍;
3)结构体的整体长度与其中的结构体成员无关,而是整个结构体(包括结构体成员内部)中的最长数据类型的整数倍。
得出结论后,我们回到处理器本身,来探讨一下编译器之所以这么处理的原因。
从CPU结构角度看内存对齐有一篇比较易懂的文章:
http://hi.baidu.com/maikeai/item/4976f24cc0f905d3c1a592a0
从该文章中,我们可以知道,之所以需要内存对齐,是CPU为了读取数据时减少读取存储器的次数,提高效率。
对于32位的CPU,一次最多读入双字的32位数据,而对于超过32位的数据,在32位的计算机上,就必须多次读取存储器,这与是否字节对齐无关。
我们可以看到,字节对齐,其实实质上是在拿存储器的空间,换CPU的时间。
所以,对于C语言内置的数据类型,可以很好地通过内存对齐来节省时间,同时其浪费的存储器空间也是可控的。
但是,对于结构体成员来说,因为它的长度是不可控的,所以如果强行按整体内存对齐,首先可能因为长度过长,即使内存对齐需要的存储器读取次数也很多,导致优化的时间不明显,另外,也可能导致浪费的存储器空间太大。所以,最简单的平衡空间和时间的方法,就是按照该结构体成员中最长数据类型来进行字节对齐,这样最有可能减少存储器读取次数,也使浪费的存储器空间可控。
完