找回密码
 用户注册

QQ登录

只需一步,快速开始

查看: 3732|回复: 0

C语言 内存中结构体字节对齐 |haiwil

[复制链接]
发表于 2011-12-15 13:59:34 | 显示全部楼层 |阅读模式
一、字节对齐作用和原因:
对齐的作用和原因:各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。比如有些架构的CPU在访问一个没有进行对齐的变量的时候会发生错误,那么在这种架构下编程必须保证字节对齐,其他平台可能没有这种情况,但是最常见的是如果不按照适合其平台要求对数据存放进行对齐,会在存取效率上带来损失。比如有些平台每次读都是从偶地址开始,如果一个int型(假设为32位系统)如果存放在偶地址开始的地方,那么一个读周期就可以读出这32bit,而如果存放在奇地址开始的地方,就需要2个读周期,并对两次读出的结果的高低字节进行拼凑才能得到该32bit数据,显然在读取效率上下降很多。
二、字节对齐规则:
四个重要的概念:
  1.数据类型自身的对齐值:对于char型的数据,其自身对齐值为1,对于short型为2,对于int,float,double类型,其自身对齐值为4个字节。
  2.结构体或者类的自身对齐值:其成员中自身对齐值最大的那个值。
  3.指定对齐值:#pragma pack (value)时指定的对齐value。
  4.数据成员、结构体和类的有效对齐值:自身对齐值和指定对齐值中小的那个值。
补充:
1).每个成员分别按自己的方式对齐,并能最小化长度。
2).复杂类型(如结构)的默认对齐方式是它最长的成员的对齐方式,这样在成员是复杂类型时,可以最小化长度。
3).对齐后的长度必须是成员中最大的对齐参数的整数倍,这样在处理数组时可以保证每一项都边界对齐。
  1. #pragma pack(1)
  2. struct test
  3. {
  4. static int a; //static var
  5. double m4;
  6. char m1;
  7. int m3;
  8. }
  9. #pragma pack()
  10. //sizeof(test)=13;
  11. Class test1{ };
  12. //sizeof(test1)=1;
复制代码
/* 注明:1、结构或者类中的静态成员不对结构或者类的大小产生影响,因为静态变量的存储位置与结构或者类的实例地址无关;2、没有成员变量的结构或类的大小为1,因为必须保证结构或类的每一个实例在内存中都有唯一的地址。*/
#pragma pack(1) struct test { static int a; //static var double m4; char m1; int m3; } #pragma pack() //sizeof(test)=13; Class test1{ }; //sizeof(test1)=1; /* 注明: 1、结构或者类中的静态成员不对结构或者类的大小产生影响,因为静态变量的存储位置与结构或者类的实例地址无关; 2、没有成员变量的结构或类的大小为1,因为必须保证结构或类的每一个实例在内存中都有唯一的地址。*/

示例://分析下面的例子C://
  1. #pragma pack (2)     /*指定按2字节对齐*/
  2. struct C
  3. {
  4.   char b;
  5.   int a;
  6.   short c;
  7. };
复制代码
#pragma pack () //恢复对齐状态/*第一个变量b的自身对齐值为1,指定对齐值为2,所以,其有效对齐值为1,假设C从0x0000开始,那么b存放在0x0000,符合0x0000%1 = 0;第二个变量,自身对齐值为4,指定对齐值为2,所以有效对齐值为2,所以顺序存放在0x0002、0x0003、0x0004、0x0005四个连续的字节空间中,符合0x0002%2=0。第三个变量c的自身对齐值为2,所以有效对齐值为2,顺序在0x0006、0x0007中,符合0x0006%2=0。所以从0x0000到0x0007共八字节存放的是struct C的变量。又struct C的自身对齐值为4,所以struct C的有效对齐值为2。又8%2=0,struct C只占用0x0000到0x0007的八个字节。所以sizeof(struct C)=8。如果把上面的#pragma pack(2)改为#pragma pack(4),那么我们可以得到结构的大小为12。*/

//再看下面这个例子//
  1. #pragma pack(8)
  2. struct S1
  3. {
  4.   char a;
  5.   long b;
  6. };
  7. struct S2 {
  8.   char c;
  9.   struct S1 d;
  10.   long long e;
  11. };
  12. #pragma pack()
复制代码
sizeof(S2)结果为24./*S1中:成员a是1字节默认按1字节对齐,指定对齐参数为8,这两个值中取1,a按1字节对齐;成员b是4个字节,默认是按4字节对齐,这时就按4字节对齐,所以sizeof(S1)应该为8;S2 中:c和S1中的a一样,按1字节对齐,d 是个结构,它是8个字节,它按什么对齐呢?对于结构来说,它的默认对齐方式就是它的所有成员使用的对齐参数中最大的一个,S1的就是4.所以,成员d就是按4字节对齐.成员e是8个字节,它是默认按8字节对齐,和指定的一样,所以它对到8字节的边界上,这时,已经使用了12个字节了,所以又添加了4个字节的空,从第16个字节开始放置成员e;长度为24,已经可以被8(成员e按8字节对齐)整除.一共使用了24个字节.a bS1的内存布局:11**,1111,c S1.a S1.b dS2的内存布局:1***,11**,1111,****11111111*/
//再看下面这个例子 // #pragma pack(8) struct S1 { char a; long b; }; struct S2 { char c; struct S1 d; long long e; }; #pragma pack() sizeof(S2)结果为24. /* S1中: 成员a是1字节默认按1字节对齐,指定对齐参数为8,这两个值中取1,a按1字节对齐; 成员b是4个字节,默认是按4字节对齐,这时就按4字节对齐,所以sizeof(S1)应该为8; S2 中: c和S1中的a一样,按1字节对齐, d 是个结构,它是8个字节,它按什么对齐呢?对于结构来说,它的默认对齐方式就是它的所有成员使用的对齐参数中最大的一个,S1的就是4.所以,成员d就是按4字节对齐. 成员e是8个字节,它是默认按8字节对齐,和指定的一样,所以它对到8字节的边界上,这时,已经使用了12个字节了,所以又添加了4个字节的空,从第16个字节开始放置成员e;长度为24,已经可以被8(成员e按8字节对齐)整除.一共使用了24个字节. a b S1的内存布局:11**,1111, c S1.a S1.b d S2的内存布局:1***,11**,1111,****11111111 */
三、针对字节对齐,我们在编程中如何考虑?
  如果在编程的时候要考虑节约空间的话,那么我们只需要假定结构的首地址是0, 然后各个变量按照上面的原则进行排列即可,基本的原则就是把结构中的变量按照类型大小从小到大声明,尽量减少中间的填补空间。还有一种就是为了以空间换取时间的效率,我们显示的进行填补空间进行对齐,比如:有一种使用空间换时间做法是显式的插入reserved成员:
  1. struct
  2. A
  3. {
  4.   char a;
  5.   char reserved[3];    //使用空间换时间
  6.   int
  7. b;
  8. };
复制代码
reserved成员对我们的程序没有什么意义,它只是起到填补空间以达到字节对齐的目的,当然即使不加这个成员通常编译器也会给我们自动填补对齐,我们自己加上它只是起到显示的提醒作用。
四、字节对齐可能带来的隐患
  代码中关于对齐的隐患,很多是隐式的。比如在强制类型转换的时候。例如:
  1.   unsigned
  2. int i = 0x12345678;
  3.   unsigned char *p = NULL;
  4.   unsigned short *p1 =
  5. NULL;
  6.   p=&i;
  7.   *p=0x00;
  8.   p1=(unsigned
  9. short*)(p+1);
  10.   *p1=0x0000;
复制代码
  最后两行代码,从奇数边界去访问unsigned short型变量,显然不符合对齐的规定。在X86上,类似的操作只会影响效率,但是在MIPS或者sparc上,可能就是一个error,因为它们要求字节必须对齐。
五、如何查找与字节对齐方面的问题
  如果出现对齐或者赋值问题首先查看
  1.编译器设置的对齐值
  2.看这种体系本身是否支持非对齐访问
  3.如果支持看设置了对齐与否,如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。
作者:haiwil 发表于2011-12-14 15:22:58 原文链接
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

Archiver|手机版|小黑屋|ACE Developer ( 京ICP备06055248号 )

GMT+8, 2024-5-2 19:10 , Processed in 0.023569 second(s), 7 queries , Redis On.

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表