灯火互联
管理员
管理员
  • 注册日期2011-07-27
  • 发帖数41778
  • QQ
  • 火币41290枚
  • 粉丝1086
  • 关注100
  • 终身成就奖
  • 最爱沙发
  • 忠实会员
  • 灌水天才奖
  • 贴图大师奖
  • 原创先锋奖
  • 特殊贡献奖
  • 宣传大使奖
  • 优秀斑竹奖
  • 社区明星
阅读:8067回复:0

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

楼主#
更多 发布于:2014-04-10 09:59
关于结构体的字节对齐是什么,就不赘述,再此附上一篇文章,介绍字节对齐:http://www.linuxsong.org/2010/09/c-byte-alignment/
 
这里的结构体字节对齐的数据类型都是基本数据类型,如果结构体的定义中含有结构体成员呢?
 
网上有很多人写博客谈到这个问题,都认为该结构体成员应该被看做一个整体,按照整体的字节数来进行字节对齐,选择首地址。但是经过测试,这种说法是不对的。
 
复制代码
1 struct s1{
2 char c1;
3 char c2;
4 char c3;
5 char c4;
6 };
7
8 struct s2{
9 char a;
10 struct s1 s;
11 };
复制代码
对于上述代码,显然sizeof(struct s1) = 4。如果将struct s1看做整体,来进行字节对齐的话,sizeof(struct s2)应该是等于8。但是该段代码在gcc和VS2010下测试的结果都是5。
 
所以,s2的内存布局如下
 
s2 : char | char char char char |
 
s的首地址并非为4,而是char类型长度的整数倍
 
同样,对于结构体:
 
复制代码
1 struct S1
2 {
3 char a;
4 short b;
5 };
6
7 struct S2
8 {
9 char a;
10 struct S1 s;
11 };
复制代码
上述代码中,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语言内置的数据类型,可以很好地通过内存对齐来节省时间,同时其浪费的存储器空间也是可控的。
 
但是,对于结构体成员来说,因为它的长度是不可控的,所以如果强行按整体内存对齐,首先可能因为长度过长,即使内存对齐需要的存储器读取次数也很多,导致优化的时间不明显,另外,也可能导致浪费的存储器空间太大。所以,最简单的平衡空间和时间的方法,就是按照该结构体成员中最长数据类型来进行字节对齐,这样最有可能减少存储器读取次数,也使浪费的存储器空间可控。

喜欢0 评分0
游客

返回顶部