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   | 
|   |   | 
+---------------------------+ 
1   Byte   4   byte   


因为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 
当数组首地址是4字节对齐时，array[1].a也是4字节对齐，可是array[2].a呢？array[3].a   ....呢？可见这种方案在定义结构体数组时无法让数组中所有元素的字段都满足对齐规定，必须修改成如下形式: 
___________________________________ 
|   |   |\\\\\\\\\\\| 
|   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、操作系统、编译器及编译时的对齐选项，而你的程序可能需要运行在多种平台上，你的源代码可能要被不同的人用不同的编译器编译(试想你为别人提供一个开放源码的库)，那么除非绝对必需，否则你的程序永远也不要依赖这些诡异的内存布局。顺便说一下，如果一个程序中的两个模块是用不同的对齐选项分别编译的，那么它很可能会产生一些非常微妙的错误。如果你的程序确实有很难理解的行为，不防仔细检查一下各个模块的编译选项。

#pragma   pack(4) 
　　class   TestB 
　　{ 
　　public: 
　　　　int   aa; 
　　　　char   a; 
　　　　short   b; 
　　　　char   c; 
　　}; 
　　int   nSize   =   sizeof(TestB); 
　　这里nSize结果为12，在预料之中。 
    现在去掉第一个成员变量为如下代码： 
　　#pragma   pack(4) 
　　class   TestC 
　　{ 
　　public: 
　　　　char   a; 
　　　　short   b; 
　　　　char   c; 
　　}; 
　　int   nSize   =   sizeof(TestC); 
　　按照正常的填充方式nSize的结果应该是8，为什么结果显示nSize为6呢？ 

事实上，很多人对#pragma   pack的理解是错误的。 
#pragma   pack规定的对齐长度，实际使用的规则是： 
结构，联合，或者类的数据成员，第一个放在偏移为0的地方，以后每个数据成员的对齐，按照#pragma   pack指定的数值和这个数据成员自身长度中，比较小的那个进行。 
也就是说，当#pragma   pack的值等于或超过所有数据成员长度的时候，这个值的大小将不产生任何效果。而结构整体的对齐，则按照结构体中最大的数据成员   和   #pragma   pack指定值   之间，较小的那个进行。 

具体解释 
#pragma   pack(4) 
　　class   TestB 
　　{ 
　　public: 
　　　　int   aa;   //第一个成员，放在[0,3]偏移的位置， 
　　　　char   a;   //第二个成员，自身长为1，#pragma   pack(4),取小值，也就是1，所以这个成员按一字节对齐，放在偏移[4]的位置。 
　　　　short   b;   //第三个成员，自身长2，#pragma   pack(4)，取2，按2字节对齐，所以放在偏移[6,7]的位置。 
　　　　char   c;   //第四个，自身长为1，放在[8]的位置。 
　　}; 
这个类实际占据的内存空间是9字节 
类之间的对齐，是按照类内部最大的成员的长度，和#pragma   pack规定的值之中较小的一个对齐的。 
所以这个例子中，类之间对齐的长度是min(sizeof(int),4)，也就是4。 
9按照4字节圆整的结果是12，所以sizeof(TestB)是12。 
如果#pragma   pack(2) 
        class   TestB 
　　{ 
　　public: 
　　　　int   aa;   //第一个成员，放在[0,3]偏移的位置， 
　　　　char   a;   //第二个成员，自身长为1，#pragma   pack(4),取小值，也就是1，所以这个成员按一字节对齐，放在偏移[4]的位置。 
　　　　short   b;   //第三个成员，自身长2，#pragma   pack(4)，取2，按2字节对齐，所以放在偏移[6,7]的位置。 
　　　　char   c;   //第四个，自身长为1，放在[8]的位置。 
　　}; 
//可以看出，上面的位置完全没有变化，只是类之间改为按2字节对齐，9按2圆整的结果是10。 
//所以   sizeof(TestB)是10。 
最后看原贴： 
现在去掉第一个成员变量为如下代码： 
　　#pragma   pack(4) 
　　class   TestC 
　　{ 
　　public: 
　　　　char   a;//第一个成员，放在[0]偏移的位置， 
　　　　short   b;//第二个成员，自身长2，#pragma   pack(4)，取2，按2字节对齐，所以放在偏移[2,3]的位置。
　　　　char   c;//第三个，自身长为1，放在[4]的位置。 
　　}; 
//整个类的大小是5字节，按照min(sizeof(short),4)字节对齐，也就是2字节对齐，结果是6 
//所以sizeof(TestC)是6。 

感谢   Michael   提出疑问，在此补充: 
当数据定义中出现__declspec(   align()   )时，指定类型的对齐长度还要用自身长度和这里指定的数值比较，然后取其中较大的。最终类/结构的对齐长度也需要和这个数值比较，然后取其中较大的。 
可以这样理解，   __declspec(   align()   )   和   #pragma   pack是一对兄弟，前者规定了对齐的最小值，后者规定了对齐的最大值，两者同时出现时，前者拥有更高的优先级。 
__declspec(   align()   )的一个特点是，它仅仅规定了数据对齐的位置，而没有规定数据实际占用的内存长度，当指定的数据被放置在确定的位置之后，其后的数据填充仍然是按照#pragma   pack规定的方式填充的，这时候类/结构的实际大小和内存格局的规则是这样的： 
在__declspec(   align()   )之前，数据按照#pragma   pack规定的方式填充，如前所述。当遇到__declspec(   align()   )的时候，首先寻找距离当前偏移向后最近的对齐点（满足对齐长度为max(数据自身长度,指定值)   ），然后把被指定的数据类型从这个点开始填充，其后的数据类型从它的后面开始，仍然按照#pragma   pack填充，直到遇到下一个__declspec(   align()   )。 
当所有数据填充完毕，把结构的整体对齐数值和__declspec(   align()   )规定的值做比较，取其中较大的作为整个结构的对齐长度。 
特别的，当__declspec(   align()   )指定的数值比对应类型长度小的时候，这个指定不起作用。