什么是字节对齐,为什么要对齐?_char型要对齐什么意思-优快云博客

一.什么是字节对齐,为什么要对齐?
    现代计算机中内存空间都是按照byte划分的，从理论上讲似乎对任何类型的变量的访问可以从任何地址开始，但实际情况是在访问特定类型变量的时候经常在特定的内存地址访问，这就需要各种类型数据按照一定的规则在空间上排列，而不是顺序的一个接一个的排放，这就是对齐。
    对齐的作用和原因：各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。比如有些架构的CPU在访问一个没有进行对齐的变量的时候会发生错误,那么在这种架构下编程必须保证字节对齐.其他平台可能没有这种情况，但是最常见的是如果不按照适合其平台要求对数据存放进行对齐，会在存取效率上带来损失。比如有些平台每次读都是从偶地址开始，如果一个int型（假设为32位系统）如果存放在偶地址开始的地方，那么一个读周期就可以读出这32bit，而如果存放在奇地址开始的地方，就需要2个读周期，并对两次读出的结果的高低字节进行拼凑才能得到该32bit数据。显然在读取效率上下降很多。
二.字节对齐对程序的影响:

http://blog.youkuaiyun.com/qq413785523/article/details/43147285

long:4(有符号无符号同)
float:4    double:8
那么上面两个结构大小如何呢?
结果是:
sizeof(strcut A)值为8
sizeof(struct B)的值却是12
结构体A中包含了4字节长度的int一个，1字节长度的char一个和2字节长度的short型数据一个,B也一样;按理说A,B大小应该都是7字节。
之所以出现上面的结果是因为编译器要对数据成员在空间上进行对齐。上面是按照编译器的默认设置进行对齐的结果,那么我们是不是可以改变编译器的这种默认对齐设置呢,当然可以.例如:
#pragma pack (2) /*指定按2字节对齐*/
struct C
{
    char b;
    int a;
    short c;
};
#pragma pack () /*取消指定对齐，恢复缺省对齐*/
sizeof(struct C)值是8。
修改对齐值为1：
#pragma pack (1) /*指定按1字节对齐*/
struct D
{
    char b;
    int a;
    short c;
};
#pragma pack () /*取消指定对齐，恢复缺省对齐*/
sizeof(struct D)值为7。
后面我们再讲解#pragma pack()的作用.
三.编译器是按照什么样的原则进行对齐的?
先让我们看四个重要的基本概念：
1.数据类型自身的对齐值：
对于char型数据，其自身对齐值为1，对于short型为2，对于int,float,double类型，其自身对齐值为4，单位字节。
2.结构体或者类的自身对齐值：其成员中自身对齐值最大的那个值。
3.指定对齐值：#pragma pack (value)时的指定对齐值value。
4.数据成员、结构体和类的有效对齐值：自身对齐值和指定对齐值中小的那个值。
有了这些值，我们就可以很方便的来讨论具体数据结构的成员和其自身的对齐方式。有效对齐值N是最终用来决定数据存放地址方式的值，最重要。有效对齐N，就是表示“对齐在N上”，也就是说该数据的"存放起始地址%N=0".而数据结构中的数据变量都是按定义的先后顺序来排放的。第一个数据变量的起始地址就是数据结构的起始地址。结构体的成员变量要对齐排放，结构体本身也要根据自身的有效对齐值圆整(就是结构体成员变量占用总长度需要是对结构体有效对齐值的整数倍，结合下面例子理解)。这样就不能理解上面的几个例子的值了。
例子分析：
分析例子B；
struct B
{
    char b;
    int a;
    short c;
};
假设B从地址空间0x0000开始排放。该例子中没有定义指定对齐值，在笔者环境下，该值默认为4。第一个成员变量b的自身对齐值是1，比指定或者默认指定对齐值4小，所以其有效对齐值为1，所以其存放地址0x0000符合0x0000%1=0.第二个成员变量a，其自身对齐值为4，所以有效对齐值也为4，所以只能存放在起始地址为0x0004到0x0007这四个连续的字节空间中，复核0x0004%4=0,且紧靠第一个变量。第三个变量c,自身对齐值为 2，所以有效对齐值也是2，可以存放在0x0008到0x0009这两个字节空间中，符合0x0008%2=0。所以从0x0000到0x0009存放的都是B内容。再看数据结构B的自身对齐值为其变量中最大对齐值(这里是b）所以就是4，所以结构体的有效对齐值也是4。根据结构体圆整的要求， 0x0009到0x0000=10字节，（10＋2）％4＝0。所以0x0000A到0x000B也为结构体B所占用。故B从0x0000到0x000B 共有12个字节,sizeof(struct B)=12;其实如果就这一个来说它已经满足字节对齐了, 因为它的起始地址是0,因此肯定是对齐的,之所以在后面补充2个字节,是因为编译器为了实现结构数组的存取效率,试想如果我们定义了一个结构B的数组,那么第一个结构起始地址是0没有问题,但是第二个结构呢?按照数组的定义,数组中所有元素都是紧挨着的,如果我们不把结构的大小补充为4的整数倍,那么下一个结构的起始地址将是0x0000A,这显然不能满足结构的地址对齐了,因此我们要把结构补充成有效对齐大小的整数倍.其实诸如:对于char型数据，其自身对齐值为1，对于short型为2，对于int,float,double类型，其自身对齐值为4，这些已有类型的自身对齐值也是基于数组考虑的,只是因为这些类型的长度已知了,所以他们的自身对齐值也就已知了.
同理,分析上面例子C：
#pragma pack (2) /*指定按2字节对齐*/
struct C
{
    char b;
    int a;
    short c;
};
#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到0x00007共八字节存放的是C的变量。又C的自身对齐值为4，所以C的有效对齐值为2。又8%2=0,C 只占用0x0000到0x0007的八个字节。所以sizeof(struct C)=8.
四.如何修改编译器的默认对齐值?
1.在VC IDE中，可以这样修改：[Project]|[Settings],c/c++选项卡Category的Code Generation选项的Struct Member Alignment中修改，默认是8字节。
2.在编码时，可以这样动态修改：#pragma pack .注意:是pragma而不是progma.
五.针对字节对齐,我们在编程中如何考虑?
    如果在编程的时候要考虑节约空间的话,那么我们只需要假定结构的首地址是0,然后各个变量按照上面的原则进行排列即可,基本的原则就是把结构中的变量按照类型大小从小到大声明,尽量减少中间的填补空间.还有一种就是为了以空间换取时间的效率,我们显示的进行填补空间进行对齐,比如:有一种使用空间换时间做法是显式的插入reserved成员：
         struct A{
           char a;
           char reserved[3];//使用空间换时间
           int b;
}
reserved成员对我们的程序没有什么意义,它只是起到填补空间以达到字节对齐的目的,当然即使不加这个成员通常编译器也会给我们自动填补对齐,我们自己加上它只是起到显式的提醒作用.
六.字节对齐可能带来的隐患:
    代码中关于对齐的隐患，很多是隐式的。比如在强制类型转换的时候。例如：
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,因为它们要求必须字节对齐.
七.如何查找与字节对齐方面的问题:
如果出现对齐或者赋值问题首先查看
1. 编译器的big little端设置
2. 看这种体系本身是否支持非对齐访问
3. 如果支持，看设置了对齐与否,如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。
八.相关文章:转自 http://blog.youkuaiyun.com/goodluckyxl/archive/2005/10/17/506827.aspx
ARM下的对齐处理
from DUI0067D_ADS1_2_CompLib
3.13 type qulifiers
有部分摘自ARM编译器文档对齐部分
对齐的使用:
1.__align(num)
   这个用于修改最高级别对象的字节边界。在汇编中使用LDRD或者STRD时
   就要用到此命令__align(8)进行修饰限制。来保证数据对象是相应对齐。
   这个修饰对象的命令最大是8个字节限制,可以让2字节的对象进行4字节
   对齐,但是不能让4字节的对象2字节对齐。
   __align是存储类修改,他只修饰最高级类型对象不能用于结构或者函数对象。

2.__packed
__packed是进行一字节对齐
1.不能对packed的对象进行对齐
2.所有对象的读写访问都进行非对齐访问
3.float及包含float的结构联合及未用__packed的对象将不能字节对齐
4.__packed对局部整形变量无影响
5.强制由unpacked对象向packed对象转化是未定义,整形指针可以合法定
义为packed。
     __packed int* p; //__packed int 则没有意义
6.对齐或非对齐读写访问带来问题
__packed struct STRUCT_TEST
{
char a;
int b;
char c;
} ;    //定义如下结构此时b的起始地址一定是不对齐的
         //在栈中访问b可能有问题,因为栈上数据肯定是对齐访问[from CL]
//将下面变量定义成全局静态不在栈上
static char* p;
static struct STRUCT_TEST a;
void Main()
{
__packed int* q; //此时定义成__packed来修饰当前q指向为非对齐的数据地址下面的访问则可以
p = (char*)&a;
q = (int*)(p+1);

*q = 0x87654321;
/*
得到赋值的汇编指令很清楚
ldr      r5,0x20001590 ; = #0x12345678
[0xe1a00005]   mov      r0,r5
[0xeb0000b0]   bl       __rt_uwrite4 //在此处调用一个写4byte的操作函数

[0xe5c10000]   strb     r0,[r1,#0]   //函数进行4次strb操作然后返回保证了数据正确的访问
[0xe1a02420]   mov      r2,r0,lsr #8
[0xe5c12001]   strb     r2,[r1,#1]
[0xe1a02820]   mov      r2,r0,lsr #16
[0xe5c12002]   strb     r2,[r1,#2]
[0xe1a02c20]   mov      r2,r0,lsr #24
[0xe5c12003]   strb     r2,[r1,#3]
[0xe1a0f00e]   mov      pc,r14
*/
/*
如果q没有加__packed修饰则汇编出来指令是这样直接会导致奇地址处访问失败
[0xe59f2018]   ldr      r2,0x20001594 ; = #0x87654321
[0xe5812000]   str      r2,[r1,#0]
*/
//这样可以很清楚的看到非对齐访问是如何产生错误的
//以及如何消除非对齐访问带来问题
//也可以看到非对齐访问和对齐访问的指令差异导致效率问题
}

以下转自： http://blog.youkuaiyun.com/menuconfig/archive/2007/11/18/1891727.aspx
前言：
《***软件编程规范》中提到：“在定义结构数据类型时，为了提高系统效率，要注意4字节对齐原则……”。本文解释x86上字节对齐的机制，其他架构读者可自行试验。同时，本文对C/C++的函数调用方式进行了讨论。
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    $0x10,%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://www.blogbus.com/blogbus/blog/archive.php?id=1807
Alignment, Pack and Bit Field . . .

2）关于字节对齐Alignment 的问题现在写出来与大家分享与讨论欢迎指正。
1. 为什么要对齐?
       以32位的CPU为例(16 64位同它),一次可以对一个32位的数进行运算,它的数据总线的宽度是32位,它从内存中一次可以存取的最大数为32位,这个数叫CPU的字word 长。
    在进行硬件设计时将存储体组织成32位宽，如每个存储体的宽度是8位可用四块存储体与CPU的32位数据总线相连，这也是为什么以前的 386/486计算机插SIMM30内存条(8位)时必须同时插四条的原因。
    请参见下图：
1       8       16      24      32
-------- ------- ------- --------
| long1 | long1 | long1 | long1 |
-------- ------- ------- --------
|         |          |          | long2 |
-------- ------- ------- --------
| long2 | long2 | long2 |          |
-------- ------- ------- --------
| ....

      当一个long型数，(如图中long1 )在内存中的位置正好与内存的字边界对齐时,CPU存取这个数只需访问一次内存,而当一个long型数(如图中long2 ),在内存中的位置跨越字边界时,CPU存取这个数就需多次访问内存,如 i960cx访问这样的数需读内存三次一个BYTE ,一个short ,一个BYTE ,由CPU的微代码执行,对软件透明.所以在对齐方式下CPU的运行效率明显快多了这就是要对齐的原因.
      一般在编译器生成代码时,都可以根据各种CPU类型将变量进行对齐,包括结构struct 中的变量,变量与变量之间的空间叫padding.有时为了对齐在一个结构的最后也会填入padding ,通常叫tail padding .但在实际的应用中我们确实有不对齐的要求,如在编通讯程序时帧的结构就不能对齐,否则会带来错误及麻烦,所以各编译器都提供了不对齐的选项.但由于这是ANSI C中未规定的内容所以各厂家的实现都不一样.
      下面是我们常用编译器的实现:
2. 一般编译器实现对齐的方法
    由于各厂家的实现不一样,这里涉及的内容只使用于Visual C++ 4.x ,Borland C++ 5.0 3.1及pRism x86 1.8.7 (C languange) .其他厂家可能略有不同.
    每种基本数据类型都有它的自然对齐方式Natural Alignment, Align的值与该数据类型的大小相等见下表
     Data Type              sizeof         Natural Align
     (signed/unsigned)
     char                          1                     1
     short                        2                      2
     long                          4                      4
     .
     .
     .
      同时用户还可以指定一个Align值,使用编译开关或使用#pragma .
     当用户指定一个Align值 n 或编译器的缺省时,每种数据类型的实际当前Align值定义如下:
           Actual Align = min ( n, Natual Align ) //公式 1
      如当用户指定Align值为 2 时,char 的实际Align值仍为1 ,short及long的实际Align值为 2 .
        当用户指定Align值为 1 时,所有类型的实际Align值都为 1.
      复杂数据类型Complex or Aggregate type,包括 array, struct 及union 的对齐值定义如下:
      struct 结构的Align值等于该结构所有成员的 Actual Align 值中最大的一个Align 值,注意成员的Align值是它的实际Align值
      array 数组的Align值等于该数组成员的 Actual Align 值.
      union 联合的Align值等于该联合最大成员的 Actual Align 值.
      同时当用户指定一个Align值时上面的公式 1 同样起作用,只不过Natural Align应理解为当前的Actual Align.
      那么编译器是如何根据一个类型的Align值来分配存储空间主要是在结构中的空间的呢?
    有如下两个规律
       1. 一个结构成员的offset等于该成员Actual Align值的整数倍,如果凑不成整数倍就在其前加padding.
       2. 一个结构的大小等于该结构Actual Align值的整数倍,如果凑不成整数倍就在其后加padding ,tail padding
       一个结构的大小在其定义时就已确定不会因为其Actual Align值的改变而改变.
      例如有如下两个结构定义
#pragma pack(8) // 指定Align为 8
struct STest1
{
        char ch1;
        long lo1;
        char ch2;
} test1;
#pragma pack()
现在 Align of STest1 = 4 , sizeof STest1 = 12 ( 4 * 3 )
test1在内存中的排列如下 FF 为 padding
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF FF FF 01 01 01 01 01 FF FF FF
ch1 --       lo1 --         ch2
#pragma pack(2) //指定Align为 2
struct STest2
{
       char ch3;
       STest1 test;
} test2;
#pragma pack()
现在 Align of STest1 = 2, Align of STest2 = 2 ,sizeof STest2 = 14 ( 7 * 2 )
test2在内存中的排列如下
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 FF 01 FF FF FF 01 01 01 01 01 FF FF FF
ch3   ch1 --         lo1 --          ch2
从以上可以看出用户可以在任何需要的地方定义不同的align值
3. 不同编译器实现用户指定align 值的方法:
      因为是 ANSI C中未规定的内容，所以各厂家的方法都不一样。一般都提供命令行选项及使用#pragma。
    命令行选项对所有被编译的文件都起作用#pragma则是ANSI C特别为实现不同的编译器及平台特性而规定的预处理器指令Preprocessor 下面主要讲一下#pragma的实现:
       Visual C++ VC使用 #pragma pack( [n] ) ,其中 n 可以是 1, 2, 4, 8, 16, 编译器在遇到一个#pragma pack(n)后就将 n当作当前的用户指定align值直到另一个#pragma pack(n) 。当遇到一个不带 n 的 pack时就恢复以前使用的align值。
      Borland C++ BC使用 #pragma option -an ，在 BC 5.0 的Online Help中没有发现对#pragma pack的支持但发现在其系统头文件中使用的都是#pragma pack。
      pRism x86 使用 #pragma pack( [n] ) ,但奇怪的是 C 文件与 C++文件生成的代码不一样，有待进一步研究。
     gcc960 使用 #pragma pack n 及 #pragma align n 。两个开关的意义不一样，并且相互作用比较复杂。但同时使用 #pragma pack 1 及#pragma align 1 可以实现与Visual C++中 #pragma pack(1) 一样的功能。
     其他编译器的方法各不相同，可参见手册。如果要使用不同的编译器编译软件时，就要针对不同的编译器使用不同的预处理器指令。
4. 使用 #pragma pack 或其他开关需注意的问题
     1. 为了保证执行速度尽量不使用#pragma pack
    2. 不同的编译器生成的代码极有可能不同一定要查看相应手册并做实验
     3.需要加pack的地方一定要在定义结构的头文件中加，不要依赖命令行选项。因为如果很多人使用该头文件，并不是每个人都知道应该pack 。特别是为别人开发库文件时，如果一个库函数使用了struct作为其参数，当调用者与库文件开发者使用不同的pack时，就会造成错误，而且该类错误很不好查。在VC及BC提供的头文件中除了能正好对齐在四字节上的结构外都加了pack ，否则我们编的Windows程序哪一个也不会正常运行。
    4. 在 #pragma pack(n)后一定不要include其他头文件，若包含的头文件中改变了align值将产生非预期结果。
VC中提供了一种安全使用pack的方法
#pragma pack( [ push | pop ], n )
#pragma pack( push, n)
将当前的align值压入编译器的一个内部堆栈并使用，n作为当前的align值，而#pragma pack(pop)则将内部堆栈中的栈顶值作为当前的align值，这样就保证了嵌套pack时的正确。
    5.不要多人同时定义一个数据结构。在多人合作开发一个软件模块时，为了保持自己的编程风格，每个人都要对同一结构定义一份符合自己风格的数据类型，当两个人之间需要传递该数据结构时，如果两个人的 pack值不一样就会产生错误，该类错误也很难查，所以为了安全起见我们还是舍弃一些自己的风格吧。

5. 关于位域 Bit Field
      在 ANSI C 中规定位域的类型只能为 signed/unsigned int ，但各厂家都对其进行了扩展类型可以是 char, short, long等但其最大长度不能超过int的长度，即32位平台时为32位，16位平台时为16位。位域存储空间的分配也与各编译器的实现有关，而且与Little Endian(x86,i960),BigEndian(680x0,PowerPc)有关。所以在定义位域时要对不同的编译器进行不同的支持，如在VC中规定如果两个连续位域的类型不一样或位域的长度为零，编译器将进行对齐。在VC中是这样，其他编译器就可能不是这样。这属于各厂家不同的实现问题。ANSI
C 中没有进行规定所以如果涉及到位域问题一定要查看手册。

6. 附例
      以下结果均在VC++4.x ，BC++5.0,3.1 pRism x86 1.8.7(C Language)进行过验证。其中因为BC++ 3.1 是16位的所以只有pack(1),pack(2)有效。
例中定义了如下几个结构
typedef struct tagSLong
{
char chMem1;
char chMem2;
char chMem3;
unsigned short wMem4;
unsigned long dwMem5;
unsigned short wMem6;
char chMem7;
}SLong;

typedef struct tagSShort
{
char chMem1;
unsigned short wMem2;
char chMem3;
}SShort;

typedef union tagun
{
char uChar;
unsigned short uWord;
}un;

typedef struct tagComplex
{
char chItem1;
SLong struItem2;
unsigned long dwItem3;
char chItem4;
un unItem5;
}Complex;

测试时对每个结构的成员按 1 2 3 ... 依次进行赋值FF 为Padding
下面列出了每个结构的size Align的大小及其空间分配
1. Now the Align(Pack) size is 8
sizeof(SLong) = 16 Alignment of (SLong) = 4
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
sizeof(SShort) = 6 Alignment of (SShort) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF 02 00 03 FF
sizeof(Complex) = 28 Alignment of (Complex) = 4
[Notice the alignment of (SLong) = 4 and (un)=2 ]
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF FF FF 01 02 03 FF 04 00 FF FF 05 00 00 00
06 00 07 FF 08 00 00 00 09 FF 0A 00
sizeof(SLong[2]) = 32 Alignment of (SLong[2]) = 4
[Notice the alignment of (SLong) = 4 ]
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
sizeof(un) = 2 Alignment of (un) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 00
2. Now the Align(Pack) size is 4
sizeof(SLong) = 16 Alignment of (SLong) = 4
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
sizeof(SShort) = 6 Alignment of (SShort) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF 02 00 03 FF
sizeof(Complex) = 28 Alignment of (Complex) = 4
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF FF FF 01 02 03 FF 04 00 FF FF 05 00 00 00
06 00 07 FF 08 00 00 00 09 FF 0A 00
sizeof(SLong[2]) = 32 Alignment of (SLong[2]) = 4
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
01 02 03 FF 04 00 FF FF 05 00 00 00 06 00 07 FF
sizeof(un) = 2 Alignment of (un) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 00
3. Now the Align(Pack) size is 2
sizeof(SLong) = 14 Alignment of (SLong) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 05 00 00 00 06 00 07 FF
sizeof(SShort) = 6 Alignment of (SShort) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF 02 00 03 FF
sizeof(Complex) = 24 Alignment of (Complex) = 2
[Notice the alignment of (SLong) = 2 and (un) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 FF 01 02 03 FF 04 00 05 00 00 00 06 00 07 FF
08 00 00 00 09 FF 0A 00
sizeof(SLong[2]) = 28 Alignment of (SLong[2]) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 FF 04 00 05 00 00 00 06 00 07 FF 01 02
03 FF 04 00 05 00 00 00 06 00 07 FF
sizeof(un) = 2 Alignment of (un) = 2
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 00
4. Now the Align(Pack) size is 1
sizeof(SLong) = 12 Alignment of (SLong) = 1
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 04 00 05 00 00 00 06 00 07
sizeof(SShort) = 4 Alignment of (SShort) = 1
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 00 03
sizeof(Complex) = 20 Alignment of (Complex) = 1
[Notice the alignment of (SLong) = 1 and (un) = 1]
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 01 02 03 04 00 05 00 00 00 06 00 07 08 00 00
00 09 0A 00
sizeof(SLong[2]) = 24 Alignment of (SLong[2]) = 1
[Notice the alignment of (SLong) = 1 ]
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
01 02 03 04 00 05 00 00 00 06 00 07 01 02 03 04
00 05 00 00 00 06 00 07
sizeof(un) = 2 Alignment of (un) = 1
00 -- -- -- 04 -- -- -- 08 -- -- -- 12 -- -- --
02 00
关于pack 使用的几点建议及需注意的问题
0.由于各种编译器对pack的实现各不相同建议定义几个头文件(参照microsoft的做法)
poppack.h, pshpack1.h, pshpack2.h ...
其中poppack.h用于恢复编译器的缺省pack值其大略定义如下
#if _HA_WIN32 //for Visual C++
#pragma pack()
#elif _HA_GNU //for gcc960
#pragma pack
#pragma align 0
#elif ... for any more
pshpack1(n).h用于指定编译器的pack值为 n , 其大略定义如下
#if _HA_WIN32 //for Visual C++
#pragma pack(1)//n
#elif _HA_GNU //for gcc960
#pragma pack 1//n
#pragma align 1//n
#elif ... //for any more
使用时在需要pack的地方加上 #include "pshpack1.h" ,
在需要恢复pack的地方加上 #include "poppack.h" .
使用这种头文件的方式有如下几点好处:
    (1). 在需要pack的头文件中不需要再对不同的编译器做处理，使得该头文件比较整洁.
    (2). 便于维护.当需要增加对其他编译器的支持或对现有pack指令进行修改时,只需修改poppack.h等几个头文件.
1. 为了保证执行速度在没有必要的地方不要使用#pragma pack 不要只为了节省空间而使用BYTE等类型,其实数据的空间是减少了但代码的空间却变大了,如本来只需一条指令的地方可能需三四条指令,既影响了执行速度又增加了空间，得不偿失。如果必须使用BYTE等类型，尽可能将其在结构中排成自然对齐。
2.不同的编译器生成的代码极有可能不同，一定要查看相应手册并做实验。
如对于如下结构定义
struct SLanDest
{
WORD wTag;
MACADDR addr;
};
该结构在VC下是不加padding的但在pRism下就加了padding
3.需要加pack的地方一定要在定义结构的头文件中加，不要依赖命令行选项。因为如果很多人使用该头文件，并不是每个人都知道应该pack 特别是为别人开发库文件时如果一个库函数使用了struct作为其参数，当调用者与库文件开发者使用不同的pack时，就会造成错误，而且该类错误很不好查。在VC及BC提供的头文件中除了能正好对齐在四字节上的结构外都加了pack，否则我们编的Windows程序哪一个也不会正常运行。
4. 在 #include "pshpack1.h"后一定不要include其他头文件，若包含的头文件中改变了align值，如包含了#include "poppack.h" 将产生非预期结果。
5.不要多人同时定义一个数据结构，在多人合作开发一个软件模块时，为了保持自己的编程风格，每个人都要对同一结构定义一份符合自己风格的数据类型。当两个人之间需要传递该数据结构时如果两个人的 pack值不一样就会产生错误，该类错误也很难查。所以为了安全起见我们还是舍弃一些自己的风格吧。
6. 何时需要加pack?
在编写通信协议时通信协议的帧结构对于所有跨CPU的协议都应理解为通信协议。如邮箱通信主机与主机通过通信线路进行通信等编写硬件驱动程序时，寄存器的结构这两个地方都需要加pack1 即使看起来本来就自然对齐的也要加pack 以免不同的编译器生成的代码不一样。如 2.中的例子对于运行时只与一个CPU有关的结构为了提高执行速度请不要加pack。

3）VC中字节对齐问题
1、 sizeof应用在结构上的情况
   请看下面的结构：
   struct MyStruct
   {
   double dda1;
   char dda;
   int type
   };
   对结构MyStruct采用sizeof会出现什么结果呢？sizeof(MyStruct)为多少呢？也许你会这样求：
   sizeof(MyStruct)=sizeof(double)+sizeof(char)+sizeof(int)=13
   但是当在VC中测试上面结构的大小时，你会发现sizeof(MyStruct)为16。你知道为什么在VC中会得出这样一个结果吗？
   其实，这是VC对变量存储的一个特殊处理。为了提高CPU的存储速度，VC对一些变量的起始地址做了“对齐”处理。在默认情况下，VC规定各成员变量存放的起始地址相对于结构的起始地址的偏移量必须为该变量的类型所占用的字节数的倍数。下面列出常用类型的对齐方式(vc6.0,32位系统)。
   类型
   对齐方式（变量存放的起始地址相对于结构的起始地址的偏移量）
   Char
   偏移量必须为sizeof(char)即1的倍数
   int
   偏移量必须为sizeof(int)即4的倍数
   float
   偏移量必须为sizeof(float)即4的倍数
   double
   偏移量必须为sizeof(double)即8的倍数
   Short
   偏移量必须为sizeof(short)即2的倍数
   各成员变量在存放的时候根据在结构中出现的顺序依次申请空间，同时按照上面的对齐方式调整位置，空缺的字节VC会自动填充。同时VC为了确保结构的大小为结构的字节边界数（即该结构中占用最大空间的类型所占用的字节数）的倍数，所以在为最后一个成员变量申请空间后，还会根据需要自动填充空缺的字节。
   下面用前面的例子来说明VC到底怎么样来存放结构的。
   struct MyStruct
   {
   double dda1;
   char dda;
   int type
   }；
   为上面的结构分配空间的时候，VC根据成员变量出现的顺序和对齐方式，先为第一个成员dda1分配空间，其起始地址跟结构的起始地址相同（刚好偏移量0刚好为sizeof(double)的倍数），该成员变量占用sizeof(double)=8个字节；接下来为第二个成员dda分配空间，这时下一个可以分配的地址对于结构的起始地址的偏移量为8，是sizeof(char)的倍数，所以把dda存放在偏移量为8的地方满足对齐方式，该成员变量占用 sizeof(char)=1个字节；接下来为第三个成员type分配空间，这时下一个可以分配的地址对于结构的起始地址的偏移量为9，不是sizeof (int)=4的倍数，为了满足对齐方式对偏移量的约束问题，VC自动填充3个字节（这三个字节没有放什么东西），这时下一个可以分配的地址对于结构的起始地址的偏移量为12，刚好是sizeof(int)=4的倍数，所以把type存放在偏移量为12的地方，该成员变量占用sizeof(int)=4个字节；这时整个结构的成员变量已经都分配了空间，总的占用的空间大小为：8+1+3+4=16，刚好为结构的字节边界数（即结构中占用最大空间的类型所占用的字节数sizeof(double)=8）的倍数，所以没有空缺的字节需要填充。所以整个结构的大小为：sizeof(MyStruct)=8+1+ 3+4=16，其中有3个字节是VC自动填充的，没有放任何有意义的东西。
   下面再举个例子，交换一下上面的MyStruct的成员变量的位置，使它变成下面的情况：
   struct MyStruct
   {
   char dda;
   double dda1;
   int type
   }；
   这个结构占用的空间为多大呢？在VC6.0环境下，可以得到sizeof(MyStruc)为24。结合上面提到的分配空间的一些原则，分析下VC怎么样为上面的结构分配空间的。（简单说明）
   struct MyStruct
   {
   char dda;//偏移量为0，满足对齐方式，dda占用1个字节；
   double dda1;//下一个可用的地址的偏移量为1，不是sizeof(double)=8
   //的倍数，需要补足7个字节才能使偏移量变为8（满足对齐
   //方式），因此VC自动填充7个字节，dda1存放在偏移量为8
   //的地址上，它占用8个字节。
   int type；//下一个可用的地址的偏移量为16，是sizeof(int)=4的倍
   //数，满足int的对齐方式，所以不需要VC自动填充，type存
   //放在偏移量为16的地址上，它占用4个字节。
   }；//所有成员变量都分配了空间，空间总的大小为1+7+8+4=20，不是结构
   //的节边界数（即结构中占用最大空间的类型所占用的字节数sizeof
   //(double)=8）的倍数，所以需要填充4个字节，以满足结构的大小为
   //sizeof(double)=8的倍数。
   所以该结构总的大小为：sizeof(MyStruc)为1+7+8+4+4=24。其中总的有7+4=11个字节是VC自动填充的，没有放任何有意义的东西。
   VC对结构的存储的特殊处理确实提高CPU存储变量的速度，但是有时候也带来了一些麻烦，我们也屏蔽掉变量默认的对齐方式，自己可以设定变量的对齐方式。
   VC 中提供了#pragma pack(n)来设定变量以n字节对齐方式。n字节对齐就是说变量存放的起始地址的偏移量有两种情况：第一、如果n大于等于该变量所占用的字节数，那么偏移量必须满足默认的对齐方式，第二、如果n小于该变量的类型所占用的字节数，那么偏移量为n的倍数，不用满足默认的对齐方式。结构的总大小也有个约束条件，分下面两种情况：如果n大于所有成员变量类型所占用的字节数，那么结构的总大小必须为占用空间最大的变量占用的空间数的倍数；

   否则必须为n的倍数。下面举例说明其用法。

   #pragma pack(push) //保存对齐状态

   #pragma pack(4)//设定为4字节对齐

   struct test

   {

   char m1;

   double m4;

   int m3;

   };

   #pragma pack(pop)//恢复对齐状态

   以上结构的大小为16，下面分析其存储情况，首先为m1分配空间，其偏移量为0，满足我们自己设定的对齐方式（4字节对齐），m1占用1个字节。接着开始为 m4分配空间，这时其偏移量为1，需要补足3个字节，这样使偏移量满足为n=4的倍数（因为sizeof(double)大于n）,m4占用8个字节。接着为m3分配空间，这时其偏移量为12，满足为4的倍数，m3占用4个字节。这时已经为所有成员变量分配了空间，共分配了16个字节，满足为n的倍数。如果把上面的#pragma pack(4)改为#pragma pack(16)，那么我们可以得到结构的大小为24。（请读者自己分析）

   2、 sizeof用法总结

   在VC中，sizeof有着许多的用法，而且很容易引起一些错误。下面根据sizeof后面的参数对sizeof的用法做个总结。

   A．参数为数据类型或者为一般变量。例如sizeof(int),sizeof(long)等等。这种情况要注意的是不同系统系统或者不同编译器得到的结果可能是不同的。例如int类型在16位系统中占2个字节，在32位系统中占4个字节。
   B．参数为数组或指针。下面举例说明.
   int a[50]; //sizeof(a)=4*50=200; 求数组所占的空间大小
   int *a=new int[50];// sizeof(a)=4; a为一个指针，sizeof(a)是求指针
   //的大小,在32位系统中，当然是占4个字节。
   C．参数为结构或类。Sizeof应用在类和结构的处理情况是相同的。但有两点需要注意，第一、结构或者类中的静态成员不对结构或者类的大小产生影响，因为静态变量的存储位置与结构或者类的实例地址无关。
   第二、没有成员变量的结构或类的大小为1，因为必须保证结构或类的每一
   个实例在内存中都有唯一的地址。
   下面举例说明，
   Class Test{int a;static double c};//sizeof(Test)=4.
   Test *s;//sizeof(s)=4,s为一个指针。
   Class test1{ };//sizeof(test1)=1;
   D．参数为其他。下面举例说明。
   int func(char s[5]);
   {
   cout<
   //数的参数在传递的时候系统处理为一个指针，所
   //以sizeof(s)实际上为求指针的大小。
   return 1;
   }
   sizeof(func(“1234”))=4//因为func的返回类型为int，所以相当于
   //求sizeof(int).
   以上为sizeof的基本用法，在实际的使用中要注意分析VC的分配变量的分配策略，这样的话可以避免一些错误

gcc 的字节对齐扩展
在阅读ffmpeg代码时经常看到类似下面的语句:
#pragma pack(n)
#pragma pack()
和
__attribute((aligned (8)))
__attribute__ ((packed));
例如:
#    ifdef __GNUC__
static inline uint32_t unaligned32(const void *v)
{
    struct Unaligned
    {
uint32_t i;
    } __attribute__((packed));
    return ((const struct Unaligned *) v)->i;
}
struct FieldTest
{
int a;
char b;
char c;
}__attribute__((packed)) ft;
// 取消编译器优化对齐，取实际长度
//----------------------------------------------------
这两种方式是gcc的c扩展，用来对齐的，包括栈对齐，变量地址对齐,内存分配对齐和结构体对齐方式.
Note:在设置新的#pragma pack(n)之前,应该先取消以前的对齐,也就是说要调用一下#pragma pack().
#pragma pack(n)
n的取值可以为1、2、4、8,在编译过程中按照n个字结对齐
#pragma pack()
取消对齐，按照编译器的优化对齐方式对齐
__attribute__ ((packed));
是说取消结构在编译过程中的优化对齐。
__attribute__ ((aligned (n)));
让所作用的成员对齐在n字节自然边界上,如果结构中有成员的长度大于n，则按照机器字长来对齐
gcc手册中说了不建议使用 #pragma,而且#pragma最多只能支持8字节的对齐.
由于不同编译器可能对对齐的实现有区别，在不同编译器编译的程序间进行数据传递就有可能要用到这些东西了.
struct abc {
u32 sid;
u8 p;
union {
int digest[4];
char ctldta[10];
} data;
char dummy[0] __attribute__ ((aligned (64)));
} __attribute__ ((packed));
//__attribute__ ((packed)); 是说取消结构在编译过程中的优化对齐。
//__attribute__ ((aligned (64))); 是说让dummy成员对齐在64-bit自然边界上。
#include <iostream.h>
struct FieldTest
{
int a;
char b;
char c;
} __attribute__((aligned(16))) ft; //Aligned by 128 bit
int main(int argc,char** argv)
{
cout<<"the size of FieldTest is "<<sizeof(ft)<<endl;
return 0;
}
//---------------------------------------------------------
g++ packed_test.cpp -o test.exe -Wno-deprecated
./test.exe
the size of FieldTest is 16

人为对齐就是保证每组数据都是4字节的。
例如：
{
char s1[3] ;
long l ;
char s2 ;
}
应改为
{
char s1[3] ;
char s2 ;
long l ;
}

同理，
{
short a ;
long l ;
short b ;
}
应改为
{
short a ;
short b ;
long l ;
}

就是保证每个数据的起始位置符合4字节对齐要求。
若是有奇数个short, 如：
{
short s1;
short s2;
short s3;
long l ;
}
那么要想对齐，就得手工补足：
{
short s1;
short s2;
short s3;
short temp ;
long l ;
}
这样就不用编译器帮你对齐了。它的最大好处其实是不论1，2，4字节对齐，
编译器生成的结构都是一样的。这在通信和文件保存方面有莫大的好处。

char也一样，全应补足为4字节。

更改C编译器的缺省字节对齐方式
     在缺省情况下，C编译器为每一个变量或是数据单元按其自然对界条件分配空间。一般地，可以通过下面的方法来改变缺省的对界条件：
　　? 使用伪指令#pragma pack (n)，C编译器将按照n个字节对齐。
     ? 使用伪指令#pragma pack ()，取消自定义字节对齐方式。

     另外，还有如下的一种方式：
     ? __attribute((aligned (n)))，让所作用的结构成员对齐在n字节自然边界上。如果结构中有成员的长度大于n，则按照最大成员的长度来对齐。
     ? __attribute__ ((packed))，取消结构在编译过程中的优化对齐，按照实际占用字节数进行对齐。

以上的n = 1, 2, 4, 8, 16... 第一种方式较为常见。

应用实例

　　在网络协议编程中，经常会处理不同协议的数据报文。一种方法是通过指针偏移的方法来得到各种信息，但这样做不仅编程复杂，而且一旦协议有变化，程序修改起来也比较麻烦。在了解了编译器对结构空间的分配原则之后，我们完全可以利用这一特性定义自己的协议结构，通过访问结构的成员来获取各种信息。这样做，不仅简化了编程，而且即使协议发生变化，我们也只需修改协议结构的定义即可，其它程序无需修改，省时省力。下面以TCP协议首部为例，说明如何定义协议结构。其协议结构定义如下：

#pragma pack(1) // 按照1字节方式进行对齐
struct TCPHEADER
{
     short SrcPort; // 16位源端口号
     short DstPort; // 16位目的端口号
     int SerialNo; // 32位序列号
     int AckNo; // 32位确认号
     unsigned char HaderLen : 4; // 4位首部长度
     unsigned char Reserved1 : 4; // 保留6位中的4位
     unsigned char Reserved2 : 2; // 保留6位中的2位
     unsigned char URG : 1;
     unsigned char ACK : 1;
     unsigned char PSH : 1;
     unsigned char RST : 1;
     unsigned char SYN : 1;
     unsigned char FIN : 1;
     short WindowSize; // 16位窗口大小
     short TcpChkSum; // 16位TCP检验和
     short UrgentPointer; // 16位紧急指针
};
#pragma pack() // 取消1字节对齐方式