(转)字节对齐和C/C++函数调用方式学习总结

前言：
《***软件编程规范》中提到：“在定义结构数据类型时，为了提高系统效率，要注意4字节对齐原则……”。本文解释x86上字节对齐的机制，其他架构读者可自行试验。同时，本文对C/C++的函数调用方式进行了讨论。

BTW想了几天要在休息时间写个总结但是直到今天18日才动手。写出来应该对自己还是有帮助的。也许还有一点点参考价值吧。由于本人水平所限，有不正确之处，欢迎大家提出。

感谢几位同事。以及carrot。呵呵……
下面言归正传。

1．
先看下面的例子：
struct A{
  char c1;
  int i;
  short s;
  int j;
}a;

struct B{
  int i;
  int j;  
  short s;
  char c1;
}b;

结构A没有遵守字节对齐原则（为了区分，我将它叫做对齐声明原则），结构B遵守了。我们来看看在x86上会出现什么结果。先打印出a和b的各个成员的地址。会看到a中，各个成员间的间距是4个字节。b中，i和j，j和s都间距4个字节，但是s和c1间距2个字节。所以：
sizeof(a) = 16
sizeof(b) = 12
为 什么会有这样的结果呢？这就是x86上字节对齐的作用。为了加快程序执行的速度，一些体系结构以对齐的方式设计，通常以字长作为对齐边界。对于一些结构体变量，整个结构要对齐在内部成员变量最大的对齐边界，如B，整个结构以4为对齐边界，所以sizeof(b)为12，而不是11。
对于A来讲，虽 然声明的时候没有对齐，但是根据打印出的地址来看，编译器已经自动为其对齐了，所以每个成员的间距是4。在x86下，声明A与B唯一的差别，仅在于A多浪 费了4个字节内存。（是不是某些特定情况下，B比A执行更快，这个还需要讨论。比如紧挨的两条分别取s和c1的指令）
如果体系结构是不对齐的，A中的成员将会一个挨一个存储，从而sizeof(a)为11。显然对齐更浪费了空间。那么为什么要使用对齐呢？
体 系结构的对齐和不对齐，是在时间和空间上的一个权衡。对齐节省了时间。假设一个体系结构的字长为w，那么它同时就假设了在这种体系结构上对宽度为w的数据 的处理最频繁也是最重要的。它的设计也是从优先提高对w位数据操作的效率来考虑的。比如说读写时，大多数情况下需要读写w位数据，那么数据通道就会是w 位。如果所有的数据访问都以w位对齐，那么访问还可以进一步加快，因为需要传输的地址位减少，寻址可以加快。大多数体系结构都是按照字长来对齐访问数据 的。不对齐的时候，有的会出错，比如MIPS上会产生bus error，而x86则会进行多次访问来拼接得到的结果，从而降低执行效率。

有些体系结构是必须要求对齐的，如sparc，MIPS。它们在硬件的设计上就强制性的要求对齐。不是因为它们作不到对齐的访问，而是它们认为这样没有意义。它们追求的是速度。

上面讲了体系结构的对齐。在IA-32上面，sizeof(a)为16，就是对齐的结果。下面我们来看，为什么变量声明的时候也要尽量对齐。
我 们看到，结构A的声明并不对齐，但是它的成员地址仍是以4为边界对齐的（成员间距为4）。这是编译器的功劳。因为我所用的编译器gcc，默认是对齐的。而 x86可以处理不对齐的数据访问，所以这样声明程序并不会出错。但是对于其他结构，只能访问对齐的数据，而编译器又不小心设置了不对齐的选项，则代码就不能执行了。如果按照B的方式声明，则不管编译器是否设置了对齐选项，都能够正确的访问数据。

目前的开发普遍比较重视性能，所以对齐的问题，有三种不同的处理方法：
1）    采用B的方式声明
2）    对于逻辑上相关的成员变量希望放在靠近的位置，就写成A的方式。有一种做法是显式的插入reserved成员：
         struct A{
           char c1;
           char reserved1[3];
           int i;
           short s;
           char reserved2[2];
           int j;
}a;
3）    随便怎么写，一切交给编译器自动对齐。

代码中关于对齐的隐患，很多是隐式的。比如在强制类型转换的时候。下面举个例子：
unsigned int ui_1=0x12345678;
unsigned char *p=NULL;
unsigned short *us_1=NULL;

p=&ui_1;
*p=0x00;
us_1=(unsigned short *)(p+1);
*us_1=0x0000;
最后两句代码，从奇数边界去访问unsigned short型变量，显然不符合对齐的规定。在x86上，类似的操作只会影响效率，但是在MIPS或者sparc上，可能就是一个bus error（我没有试）。
有 些人喜欢通过移动指针来操作结构中的成员（比如在linux操作struct sk_buff的成员），但是我们看到，A中(&c1+1) 决不等于&i。不过B中(&s+2)就是 &c1了。所以，我们清楚了结构中成员的存放位置，才能编写无错的代码。同时切记，不管对于结构，数组，或者普通的变量，在作强制类型转换时一定要多看看：）不过为了不那么累，还是遵守声明对齐原则吧！（这个原则是说变量尽量声明在它的对齐边界上，而且在节省空间的基础上）

2．C/C++函数调用方式
我们当然早就知道，C/C++中的函数调用，都是以值传递的方式，而不是参数传递。那么，值传递是如何实现的呢？
函数调用前的典型汇编码如下：
push   %eax
call   0x401394 <test__Fc>
add    <# WebPartBody #>x10,%esp
首先，入栈的是实参的地址。由于被调函数都是对地址进行操作，所以就能够理解值传递的原理和参数是引用时的情况了。
Call ***， 是要调用函数了，后面的地址，就是函数的入口地址。Call指令等价于：
   PUSH IP
   JMP ***
首先把当前的执行地址IP压栈，然后跳转到函数执行。
执行完后，被调函数要返回，就要执行RET指令。RET等价于POP IP，恢复CALL之前的执行地址。所以一旦使用CALL指令，堆栈指针SP就会自动减2，因为IP的值进栈了。

函数的参数进栈的顺序是从右到左，这是C与其它语言如pascal的不同之处。函数调用都以以下语句开始：
push   %ebp
mov    %esp,%ebp
首先保存BP的值，然后将当前的堆栈指针传递给BP。那么现在BP+2就是IP的值（16位register的情况），BP+4放第一个参数的值，BP+6放第二个参数……。函数在结束前，要执行POP BP。
    
C/C++语言默认的函数调用方式，都是由主调用函数进行参数压栈并且恢复堆栈，实参的压栈顺序是从右到左，最后由主调函数进行堆栈恢复。由于主调用函数管理堆栈，所以可以实现变参函数。
对于WINAPI和CALLBACK函数，在主调用函数中负责压栈，在被调用函数中负责弹出堆栈中的参数，并且负责恢复堆栈。因此不能实现变参函数。
（哪位对编译原理和编译器比较了解的，可以将这个部分写完善，谢谢。可以加入编译时的处理。不然只有等偶继续学习了）

 

 

http://blog.programfan.com/article.asp?id=12008

结构体的大小是一个令人迷惑不解的问题，不信，我出一题让你算算看：

 

enum DataType{IntData,CharData,VcharData};

 

struct Item   

 

{

 

     char ItemNAme[30];

 

       DataType ItemType;

 

       char ItemDecr[50];

 

       int ItemLength;

 

};

 

在你使用sizeof之前你能知道它的大小吗？我想即使你用sizeof得出结果后，结果还是会让你大吃一惊的：怎么是这个？

 

 

 

一．为什么要对齐？

 

《Windows 核心编程》里这样说：当CPU访问正确对齐的数据时，它的运行效率最高，当数据大小的数据模数的内存地址是0时，数据是对齐的。例如：WORD值应该是总 是从被2除尽的地址开始，而DWORD值应该总是从被4除尽的地址开始，数据对齐不是内存结构的一部分，而是CPU结构的一部分。当CPU试图读取的数值 没有正确的对齐时，CPU可以执行两种操作之一：产生一个异常条件；执行多次对齐的内存访问，以便读取完整的未对齐数据，若多次执行内存访问，应用程序的运行速度就会慢。在最好的情况下，是两倍的时间，有时更长。

 

 

 

二．成员变量对齐的原理

 

我花了一个上午，看了一些资料，总算把这个问题搞明白了。下面我以一些例子说明结构体成员变量的对齐问题。

 

对于

struct s1

{

 

char a;

 

long int d;

double c;

};

 

这 个结构体的大小是16。编译器默认的一般是8字节对齐。a的大小是1，它就按1字节对齐（因为比指定的8小），存诸在0偏移的地方；b大小为4，它就按4 字节对齐（因为比指定的8小），存在偏移4——7的位置，c大小为8，存在8——15的位置。这样3个成员共占用了16个字节。由于该结构最大成员c大小 为8，所以结构按8字节对齐，16按8园整还是16，因此sizeof s1 = 16.

 

而对于

 

struct s2

 

{

 

char a;

 

long int d;

 

 

 

double c;

 

char e;

 

};

 

这个结构体的大小是24。前3个成员和上面一样存诸，d在4——7位置，c在8——15位置，但e按1字节对齐，存在偏移位置16，这样4个成员占用了17个字节。由于该结构的最大的数据成员c的大小是8个字节，所以17对8园整得24。

 

 

 

当然你可以使用#pragma指令指定编译器按4字节对齐。即

 

#pragma pack(4)      // 这里也可以是#pragma pack(push,4)

 

 

 

struct s1

 

{

 

char a;

 

long int d;

 

double c;

 

};

 

 

 

struct s2

 

{

 

char a;

 

long int d;

 

double c;

 

char e;

 

};

 

 

 

这 时s1的大小还是16，而s2的大小变为20。我们来分析一下，对s1来说，按4字节对齐和按8字节对齐个数据成员的存诸位置是一样的，只不过是最后一部 园整时，16对4园整还是16。对s2就不一样了，a的大小为1（比指定的4字节对齐要小），按1字节对齐，存诸在0位置，d的大小是4（大于等于指定的 4字节），按4字节对齐，存诸在4——7位置，c的大小是8（大于指定的4字节），按4字节对齐，这样存诸在8——15，e的大小是1，存储在位置16， 这样整个结构体的长度是17，17对4园整，得20。你也看到并不是指定编译器按4字节对齐就按4字节对齐的。比如下面的结构体：

 

#pragma pack(4)

 

struct TestStruct2

 

{

 

   char m1[11];

 

   short m2;

 

};

 

 你知道它的大小吗？是14。因为m1按1字节对齐，存诸在0——11位置，m2按2字节对齐，存诸在12——13位置。结构体占用13个字节，因为结构体 内最大的成员的数据类型是short，大小为2，比指定的对齐字节4小，所以13对2园整，得14。综的说来就是结构体成员的对齐是用成员本身的大小和 #pragma pack(push,n)中的n中较小的数对齐，例如如果成员大小为2，而你指定的对齐方式是4，则该成员按2对齐；结构本身的对其是用结构中最大成员的大小和#pragma pack(push,n)中的n较小的数对齐，即最后的园整，例如如果结构中最大成员大小8，而你指定对齐是16，则结构本身按8对齐。

 

 

 

开头题目的大小是92。你算到了吗？下面这个结构体的大小又是多少呢？

 

enum DataType{IntData,CharData,VcharData};

 

#pragma pack(2)

 

struct Item   

 

{

 

       char ItemNAme[30];

 

   DataType ItemType;

 

   char ItemDecr[50];

 

   int ItemLength;

 

};

 

内存对齐与 struct型数据的内存布局

---

已提供该文章的PDF版，请在贴子末尾处下载。


当在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、操作系统、编译器及编译时的对齐选项，而你的程序可能需要运行在多种平台上，你的源代码可能要被不同的人用不同的编译器编译(试想你为别人提供一个开放源码的库)，那么除非绝对必需，否则你的程序永远也不要依赖这些诡异的内存布局。顺便说一下，如果一个程序中的两个模块是用不同的对齐选项分别编译的，那么它很可能会产生一些非常微妙的错误。如果你的程序确实有很难理解的行为，不防仔细检查一下各个模块的编译选项。
思考题:请分析下面几种结构体在你的平台上的内存布局，并试着寻找一种合理安排字段声明顺序的方法以尽量节省内存空间。
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]; };