关于C语言中结构体中的结构体成员导致的字节对齐问题

时间:2023-03-09 01:16:26
关于C语言中结构体中的结构体成员导致的字节对齐问题

关于结构体的字节对齐是什么,就不赘述,再此附上一篇文章,介绍字节对齐: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语言内置的数据类型,可以很好地通过内存对齐来节省时间,同时其浪费的存储器空间也是可控的。

但是,对于结构体成员来说,因为它的长度是不可控的,所以如果强行按整体内存对齐,首先可能因为长度过长,即使内存对齐需要的存储器读取次数也很多,导致优化的时间不明显,另外,也可能导致浪费的存储器空间太大。所以,最简单的平衡空间和时间的方法,就是按照该结构体成员中最长数据类型来进行字节对齐,这样最有可能减少存储器读取次数,也使浪费的存储器空间可控。