内存对齐与ANSI C中struct型数据的内存布局(转贴) - C&C - 中国代码...

内存对齐与ANSI C中struct型数据的内存布局(转贴)
当在C中定义了一个结构类型时，它的大小是否等于各字段(field)大小之和？编译器将如何在内存中放置这些字段？ANSI C对结构体的内存布局有什么要求？而我们的程序又能否依赖这种布局？这些问题或许对不少朋友来说还有点模糊，那么本文就试着探究它们背后的秘密。
首先，至少有一点可以肯定，那就是ANSI C保证结构体中各字段在内存中出现的位置是随它们的声明顺序依次递增的，并且第一个字段的首地址等于整个结构体实例的首地址。比如有这样一个结构体：
struct vector{int x,y,z;} s;
int *p,*q,*r;
struct vector *ps;
p = &s.x;
q = &s.y;
r = &s.z;
ps = &s;
assert(p < q);
assert(p < r);
assert(q < r);
assert((int*)ps == p);
// 上述断言一定不会失败
这时，有朋友可能会问:"标准是否规定相邻字段在内存中也相邻?"。 唔，对不起，ANSI C没有做出保证，你的程序在任何时候都不应该依赖这个假设。那这是否意味着我们永远无法勾勒出一幅更清晰更精确的结构体内存布局图？哦，当然不是。不过先让我们从这个问题中暂时抽身，关注一下另一个重要问题————内存对齐。
许多实际的计算机系统对基本类型数据在内存中存放的位置有限制，它们会要求这些数据的首地址的值是某个数k(通常它为4或8)的倍数，这就是所谓的内存对齐，而这个k则被称为该数据类型的对齐模数(alignment modulus)。当一种类型S的对齐模数与另一种类型T的对齐模数的比值是大于1的整数，我们就称类型S的对齐要求比T强(严格)，而称T比S弱(宽松)。这种强制的要求一来简化了处理器与内存之间传输系统的设计，二来可以提升读取数据的速度。比如这么一种处理器，它每次读写内存的时候都从某个8倍数的地址开始，一次读出或写入8个字节的数据，假如软件能保证double类型的数据都从8倍数地址开始，那么读或写一个double类型数据就只需要一次内存操作。否则，我们就可能需要两次内存操作才能完成这个动作，因为数据或许恰好横跨在两个符合对齐要求的8字节内存块上。某些处理器在数据不满足对齐要求的情况下可能会出错，但是Intel的IA32架构的处理器则不管数据是否对齐都能正确工作。不过Intel奉劝大家，如果想提升性能，那么所有的程序数据都应该尽可能地对齐。Win32平台下的微软C编译器(cl.exe for 80x86)在默认情况下采用如下的对齐规则: 任何基本数据类型T的对齐模数就是T的大小，即sizeof(T)。比如对于double类型(8字节)，就要求该类型数据的地址总是8的倍数，而char类型数据(1字节)则可以从任何一个地址开始。Linux下的GCC奉行的是另外一套规则(在资料中查得，并未验证，如错误请指正):任何2字节大小(包括单字节吗?)的数据类型(比如short)的对齐模数是2，而其它所有超过2字节的数据类型(比如long,double)都以4为对齐模数。
现在回到我们关心的struct上来。ANSI C规定一种结构类型的大小是它所有字段的大小以及字段之间或字段尾部的填充区大小之和。嗯？填充区？对，这就是为了使结构体字段满足内存对齐要求而额外分配给结构体的空间。那么结构体本身有什么对齐要求吗？有的，ANSI C标准规定结构体类型的对齐要求不能比它所有字段中要求最严格的那个宽松，可以更严格(但此非强制要求，VC7.1就仅仅是让它们一样严格)。我们来看一个例子(以下所有试验的环境是Intel Celeron 2.4G + WIN2000 PRO + vc7.1，内存对齐编译选项是"默认"，即不指定/Zp与/pack选项):
typedef struct ms1
{
char a;
int b;
} MS1;
假设MS1按如下方式内存布局(本文所有示意图中的内存地址从左至右递增):
_____________________________
|       |                   |
|   a   |        b          |
|       |                   |
+---------------------------+
Bytes:    1             4
因为MS1中有最强对齐要求的是b字段(int)，所以根据编译器的对齐规则以及ANSI C标准，MS1对象的首地址一定是4(int类型的对齐模数)的倍数。那么上述内存布局中的b字段能满足int类型的对齐要求吗？嗯，当然不能。如果你是编译器，你会如何巧妙安排来满足CPU的癖好呢？呵呵，经过1毫秒的艰苦思考，你一定得出了如下的方案：
_______________________________________
|       |\\\\\\\\\\\|                 |
|   a   |\\padding\\|       b         |
|       |\\\\\\\\\\\|                 |
+-------------------------------------+
Bytes:    1         3             4
这个方案在a与b之间多分配了3个填充(padding)字节，这样当整个struct对象首地址满足4字节的对齐要求时，b字段也一定能满足int型的4字节对齐规定。那么sizeof(MS1)显然就应该是8，而b字段相对于结构体首地址的偏移就是4。非常好理解，对吗？现在我们把MS1中的字段交换一下顺序:
typedef struct ms2
{
int a;
char b;
} MS2;
或许你认为MS2比MS1的情况要简单，它的布局应该就是
_______________________
|             |       |
|     a       |   b   |
|             |       |
+---------------------+
Bytes:      4           1
因为MS2对象同样要满足4字节对齐规定，而此时a的地址与结构体的首地址相等，所以它一定也是4字节对齐。嗯，分析得有道理，可是却不全面。让我们来考虑一下定义一个MS2类型的数组会出现什么问题。C标准保证，任何类型(包括自定义结构类型)的数组所占空间的大小一定等于一个单独的该类型数据的大小乘以数组元素的个数。换句话说，数组各元素之间不会有空隙。按照上面的方案，一个MS2数组array的布局就是:
|<-    array[1]     ->|<-    array[2]     ->|<- array[3] .....
__________________________________________________________
|             |       |              |      |
|     a       |   b   |      a       |   b  |.............
|             |       |              |      |
+----------------------------------------------------------
Bytes:  4         1          4           1
___________________________________
|             |       |\\\\\\\\\\\|
|     a       |   b   |\\padding\\|
|             |       |\\\\\\\\\\\|
+---------------------------------+
Bytes:      4           1         3
现在无论是定义一个单独的MS2变量还是MS2数组，均能保证所有元素的所有字段都满足对齐规定。那么sizeof(MS2)仍然是8，而a的偏移为0，b的偏移是4。
好的，现在你已经掌握了结构体内存布局的基本准则，尝试分析一个稍微复杂点的类型吧。
typedef struct ms3
{
char a;
short b;
double c;
} MS3;
我想你一定能得出如下正确的布局图:
padding
|
_____v_________________________________
|   |\|     |\\\\\\\\\|               |
| a |\|  b  |\padding\|       c       |
|   |\|     |\\\\\\\\\|               |
+-------------------------------------+
Bytes:  1  1   2       4            8
sizeof(short)等于2，b字段应从偶数地址开始，所以a的后面填充一个字节，而sizeof(double)等于8，c字段要从8倍数地址开始，前面的a、b字段加上填充字节已经有4 bytes，所以b后面再填充4个字节就可以保证c字段的对齐要求了。sizeof(MS3)等于16，b的偏移是2，c的偏移是8。接着看看结构体中字段还是结构类型的情况:
typedef struct ms4
{
char a;
MS3 b;
} MS4;
MS3中内存要求最严格的字段是c，那么MS3类型数据的对齐模数就与double的一致(为8)，a字段后面应填充7个字节，因此MS4的布局应该是:
_______________________________________
|       |\\\\\\\\\\\|                 |
|   a   |\\padding\\|       b         |
|       |\\\\\\\\\\\|                 |
+-------------------------------------+
Bytes:    1         7             16
显然，sizeof(MS4)等于24，b的偏移等于8。
在实际开发中，我们可以通过指定/Zp编译选项来更改编译器的对齐规则。比如指定/Zpn(VC7.1中n可以是1、2、4、8、16)就是告诉编译器最大对齐模数是n。在这种情况下，所有小于等于n字节的基本数据类型的对齐规则与默认的一样，但是大于n个字节的数据类型的对齐模数被限制为n。事实上，VC7.1的默认对齐选项就相当于/Zp8。仔细看看MSDN对这个选项的描述，会发现它郑重告诫了程序员不要在MIPS和Alpha平台上用/Zp1和/Zp2选项，也不要在16位平台上指定/Zp4和/Zp8(想想为什么？)。改变编译器的对齐选项，对照程序运行结果重新分析上面4种结构体的内存布局将是一个很好的复习。
到了这里，我们可以回答本文提出的最后一个问题了。结构体的内存布局依赖于CPU、操作系统、编译器及编译时的对齐选项，而你的程序可能需要运行在多种平台上，你的源代码可能要被不同的人用不同的编译器编译(试想你为别人提供一个开放源码的库)，那么除非绝对必需，否则你的程序永远也不要依赖这些诡异的内存布局。顺便说一下，如果一个程序中的两个模块是用不同的对齐选项分别编译的，那么它很可能会产生一些非常微妙的错误。如果你的程序确实有很难理解的行为，不防仔细检查一下各个模块的编译选项。
思考题:请分析下面几种结构体在你的平台上的内存布局，并试着寻找一种合理安排字段声明顺序的方法以尽量节省内存空间。
A. struct P1 { int a; char b; int c; char d; };
B. struct P2 { int a; char b; char c; int d; };
C. struct P3 { short a[3]; char b[3]; };
D. struct P4 { short a[3]; char *b[3]; };
E. struct P5 { struct P2 *a; char b; struct P1 a[2];  };
参考资料:
【1】《深入理解计算机系统(修订版)》，
(著)Randal E.Bryant; David O‘Hallaron，
(译)龚奕利 雷迎春，
中国电力出版社，2004
【2】《C: A Reference Manual》(影印版)，
(著)Samuel P.Harbison; Guy L.Steele，
人民邮电出版社，2003
==================================================================
另一帖
【答疑】字长对齐带来的效率提升
作　　者：  goodluckyxl (被人遗忘的狗)
经常看到有人问起对齐有什么作用之类问题
因为今天和同事谈到了ARM平台下数据总线宽度及对齐方式对程序效率的影响问题
在定义结构数据类型时，为了提高系统效率，要注意字长对齐原则。
正好有点感触给大家谈谈 本人水平有限的很有什么问题请朋友指正:
本文主要给大家解释下所谓的对齐到底是什么?怎么对齐?为什么会对齐或者说对齐带来什么样的效率差异?
1．
先看下面的例子：
#include
#pragma pack(4)
struct A
{
char a;
int  b;
};
#pragma pack()
#pragma pack(1)
struct B
{
char a;
int  b;
};
#pragma pack()
int main()
{
A a;
cout<B b;
cout<}
默认的vc我记得是4字节对齐ADS下是一字节对齐
因为是c/c++社区大家对PC比较熟悉 我就谈PC下的对齐
PC下设计放的太长时间的有错误就别客气直接说
大家可以看到在ms的vc下按4字节对齐和1字节对齐的结果是截然不同的分别为8和5
为什么会有这样的结果呢？这就是x86上字节对齐的作用。为了加快程序执行的速度，
一些体系结构以对齐的方式设计，通常以字长作为对齐边界。对于一些结构体变量，
整个结构要对齐在内部成员变量最大的对齐边界，如A，整个结构以4为对齐边界，所以sizeof(a)为8，而不是5。
如果是原始我们概念下的的A中的成员将会一个挨一个存储 应该只有char+int只有5个字节
这个差异就是由于对齐导致的
显然我们可以看到 A的对齐要比B浪费3个字节的存储空间
那为什么还要采取对齐呢？
那是因为体系结构的对齐和不对齐，是在时间和空间上的一个权衡。
字节对齐节省了时间。应该是设计者考虑用空间换取时间。
为什么说对齐会提高效率呢节省时间？我想大家要理解的重点之重点就在这里了
在我们常用的PC下总线宽度是32位
1.如果是总线宽度对齐的话
那么所有读写操作都是获取一个<=32位数据可以一次保证在数据总线传输完毕
没有任何的额外消耗
|1|2|3|4|5|6|7|8|
从1开始这里是a的起始位置,5起始为b的位置 访问的时候
如果访问a一次在总线传输8位其他24位无效的
访问b时则一次在总线上传输32完成
读写均是一次完整
插叙一下 读操作先要将读地址放到地址总线上然后下个时钟周期再从外部
存储器接口上读回数据通过数据总线返回需要两个周期
而写操作一次将地址及数据写入相应总线就完成了
读操作要比写操作慢一半
2.我们看访问数据时如果不对齐地址的情况
|1|2|3|4|5|6|7|8|
此时a的地址没变还在1而因为是不对齐则b的位置就在2处
这时访问就带来效率上问题 访问a时没问题还是读会一个字节
但是2处地址因为不是总线宽度对齐一般的CPU在此地址操作将产生error
如sparc，MIPS。它们在硬件的设计上就强制性的要求对齐。在不对齐的地址上肯定发生错误
但是x86是支持非对齐访问的
它通过多次访问来拼接得到的结果,具体做法就是从1地址处先读回后三字节234 暂存起来
然后再由5地址处读回一个字节5 与234进行拼接组成一个完整的int也就是b返回
大家看看如此的操作带来的消耗多了不止三倍很明显在字长对齐时效率要高许多
淡然这种效率仅仅是访问多字节带来的 如果还是进行的byte操作那效率差不了多少
目前的开发普遍比较重视性能，所以对齐的问题，有2种不同的处理方法：
1）    有一种使用空间换时间做法是显式的插入reserved成员：
struct A{
char a;
char reserved1[3];//使用空间换时间
int b;
}a;
2）    随便怎么写，一切交给编译器自动对齐。
还有一种将逻辑相关的数据放在一起定义
代码中关于对齐的隐患，很多是隐式的。比如在强制类型转换的时候。下面举个例子：
unsigned int i = 0x12345678;
unsigned char *p=NULL;
unsigned short *p1=NULL;
p=&i;
*p=0x00;
p1=(unsigned short *)(p+1);
*p1=0x0000;
最后两句代码，从奇数边界去访问unsignedshort型变量，显然不符合对齐的规定。
在x86上，类似的操作只会影响效率，但是在MIPS或者sparc上，可能就是一个error