结构体字节对齐

梦里梦外; 2022-05-13 09:36 320阅读 0赞

# 结构体字节对齐 #

[http://blog.163.com/ecy\_fu/blog/static/4445126200910603739941/][http_blog.163.com_ecy_fu_blog_static_4445126200910603739941]

[ http://hi.baidu.com/skyland\_lee/blog/item/45604bca81e1928cc91768d7.html][http_hi.baidu.com_skyland_lee_blog_item_45604bca81e1928cc91768d7.html]，这篇文章比较专业地分析了字节对齐在VC和GCC的特点，写得非常不错。这两天我在为毕业设计做准备，所以要花点时间研究字节对齐的问题。

文章中有这样一段话：

Win32平台下的微软C编译器(cl.exe for 80×86)的对齐策略：

1)  结构体变量的首地址能够被其最宽基本类型成员的大小所整除；

备注：编译器在给结构体开辟空间时，首先找到结构体中最宽的基本数据类型，然后寻找内存地址能被该基本数据类型所整除的位置，作为结构体的首地址。将这个最宽的基本数据类型的大小作为上面介绍的对齐模数。

2)  结构体每个成员相对于结构体首地址的偏移量（offset）都是成员大小的整数倍，如有需要编译器会在成员之间加上填充字节（internal adding）；

备注:为结构体的一个成员开辟空间之前，编译器首先检查预开辟空间的首地址相对于结构体首地址的偏移是否是本成员的整数倍，若是，则存放本成员，反之，则在本成员和上一个成员之间填充一定的字节，以达到整数倍的要求，也就是将预开辟空间的首地址后移几个字节。

3)  结构体的总大小为结构体最宽基本类型成员大小的整数倍，如有需要，编译器会在最末一个成员之后加上填充字节（trailing padding）。

备注：结构体总大小是包括填充字节，最后一个成员满足上面两条以外，还必须满足第三条，否则就必须在最后填充几个字节以达到本条要求。

通过一个例子来验证之，有这样一个结构体：

struct S

int a;

double b;

int c;

\};

sizeof得到它的大小为24，显然为了满足第2)条，在a后面填充了4个字节，以保证b成员的地址相对于结构体首地址的偏移量是8的倍数；为了满足 3)条，在c的后面填充了4个字节，使得结构体的总大小为结构体最宽基本类型成员大小的整数倍。这样sizeof(S)就是24了。至于第一条，我倒是第一次看到，验证了下发现有点奇怪，测试代码如下（VS2008）：

struct S s1;

int a = 4;

struct S s2;

printf("%d, %d\\n", &s1, (int)(&s1) % 8);

printf("%d, %d\\n", &s2, (int)(&s2) % 8);

观察内存可知，&s1是能被8整除的，s1后面填充了好多字节，然后就是a，a后面又填充了一些字节，然后才是s2，感觉有点乱？最后发现"(int)&s2 % 8"等于4，这就不符合1)条了。

如果使用“\#pragma pack(4)声明下”，这个结构体的大小就会变成16，也就是按照4字节对齐了。pack(n)用于指明对齐的最大值。

文章中对于位域结构体有这样一段话：

如果结构体中含有位域(bit-field)，那么VC中准则又要有所更改：

1) 如果相邻位域字段的类型相同，且其位宽之和小于类型的sizeof大小，则后面的字段将紧邻前一个字段存储，直到不能容纳为止；

2) 如果相邻位域字段的类型相同，但其位宽之和大于类型的sizeof大小，则后面的字段将从新的存储单元开始，其偏移量为其类型大小的整数倍；

3) 如果相邻的位域字段的类型不同，则各编译器的具体实现有差异，VC6采取不压缩方式（不同位域字段存放在不同的位域类型字节中），Dev-C++和GCC都采取压缩方式；

用几个例子来测试一下：

struct S2

int a: 2;

int b: 3;

int c: 3;

\};

struct S3

char a : 2;

int b : 3;

\};

sizeof(S2)=4，满足1)条；sizeof(S3)=8，满足3)条。

同GCC的差异性。GCC最大的对齐模数为4，所以S的大小为16；S2，S3的大小为4，因为GCC会将S3中的a和b压缩在一个4字节中，VC却采用非压缩方式。

# [C语言结构体的字节对齐原则][C] #

[http://blog.csdn.net/shenbin1430/article/details/4292463][C]

为什么要对齐?

现代计算机中内存空间都是按照byte划分的，从理论上讲似乎对任何类型的变量的访问可以从任何地址开始，但实际情况是在访问特定类型变量的时候经常在特定的内存地址访问，这就需要各种类型数据按照一定的规则在空间上排列，而不是顺序的一个接一个的排放，这就是对齐。

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

二.字节对齐对程序的影响:

先让我们看几个例子吧(32bit,x86环境,gcc编译器):

设结构体如下定义：

struct A

int a;

char b;

short c;

\};

struct B

char b;

int a;

short c;

\};

现在已知32位机器上各种数据类型的长度如下:

char:1(有符号无符号同)

short:2(有符号无符号同)

int:4(有符号无符号同)

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. 如果支持看设置了对齐与否,如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。

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\]

\*/

//这样可以很清楚的看到非对齐访问是如何产生错误的

//以及如何消除非对齐访问带来问题

//也可以看到非对齐访问和对齐访问的指令差异导致效率问题

sizeof进行结构体大小的判断

typedef struct

int a;

char b;

\}A\_t;

typedef struct

int a;

char b;

char c;

\}B\_t;

typedef struct

char a;

int b;

char c;

\}C\_t;

void main()

char\*a=0;

cout<<sizeof(a)<<endl;//4

cout<<sizeof(\*a)<<endl;//1--这个能理解

cout<<sizeof(A\_t)<<endl;//8

cout<<sizeof(B\_t)<<endl;//8

cout<<sizeof(C\_t)<<endl;//12

为什么是这样的结果啊？

2. 语法：

sizeof有三种语法形式，如下：

1) sizeof( object ); // sizeof( 对象 );

2) sizeof( type\_name ); // sizeof( 类型 );

3) sizeof object; // sizeof 对象;

5. 指针变量的sizeof

既然是来存放地址的，那么它当然等于计算机内部地址总线的宽度。所以在32位计算机中，一

个指针变量的返回值必定是4（以字节为单位），可以预计，在将来的64位系统

中指针变量的sizeof结果为8。

char\* pc = "abc";

int\* pi;

string\* ps;

char\*\* ppc = &pc;

void (\*pf)();// 函数指针

sizeof( pc ); // 结果为4

sizeof( pi ); // 结果为4

sizeof( ps ); // 结果为4

sizeof( ppc ); // 结果为4

sizeof( pf );// 结果为4

指针变量的sizeof值与指针所指的对象没有任何关系，正是由于所有的指针变量所占内存

大小相等，所以MFC消息处理函数使用两个参数WPARAM、LPARAM就能传递各种复杂的消息结

构（使用指向结构体的指针）。

6. 数组的sizeof

数组的sizeof值等于数组所占用的内存字节数，如：

char a1\[\] = "abc";

int a2\[3\];

sizeof( a1 ); // 结果为4，字符串末尾还存在一个NULL终止符

sizeof( a2 ); // 结果为3\*4=12（依赖于int）

一些朋友刚开始时把sizeof当作了求数组元素的个数，现在，你应该知道这是不对的，那

么应该怎么求数组元素的个数呢？Easy，通常有下面两种写法：

int c1 = sizeof( a1 ) / sizeof( char ); // 总长度/单个元素的长度

int c2 = sizeof( a1 ) / sizeof( a1\[0\] ); // 总长度/第一个元素的长度

写到这里，提一问，下面的c3，c4值应该是多少呢？

void foo3(char a3\[3\])

int c3 = sizeof( a3 ); // c3 ==

void foo4(char a4\[\])

int c4 = sizeof( a4 ); // c4 ==

也许当你试图回答c4的值时已经意识到c3答错了，是的，c3!=3。这里函数参数a3已不再是

数组类型，而是蜕变成指针，相当于char\* a3，为什么？仔细想想就不难明白，我们调用

函数foo1时，程序会在栈上分配一个大小为3的数组吗？不会！数组是“传址”的，调用者

只需将实参的地址传递过去，所以a3自然为指针类型（char\*），c3的值也就为4。

7. 结构体的sizeof

这是初学者问得最多的一个问题，所以这里有必要多费点笔墨。让我们先看一个结构体：

struct S1

char c;

int i;

\};

问sizeof(s1)等于多少？聪明的你开始思考了，char占1个字节，int占4个字节，那么加起

来就应该是5。是这样吗？你在你机器上试过了吗？也许你是对的，但很可能你是错的！V

C6中按默认设置得到的结果为8。

Why？为什么受伤的总是我？

请不要沮丧，我们来好好琢磨一下sizeof的定义——sizeof的结果等于对象或者类型所占

的内存字节数，好吧，那就让我们来看看S1的内存分配情况：

S1 s1 = \{ a , 0xFFFFFFFF \};

定义上面的变量后，加上断点，运行程序，观察s1所在的内存，你发现了什么？

以我的VC6.0为例，s1的地址为0x0012FF78，其数据内容如下：

0012FF78: 61 CC CC CC FF FF FF FF

发现了什么？怎么中间夹杂了3个字节的CC？看看MSDN上的说明：

When applied to a structure type or variable, sizeof returns the actual size,

which may include padding bytes inserted for alignment.

原来如此，这就是传说中的字节对齐啊！一个重要的话题出现了。

为什么需要字节对齐？计算机组成原理教导我们这样有助于加快计算机的取数速度，否则

就得多花指令周期了。为此，编译器默认会对结构体进行处理（实际上其它地方的数据变

量也是如此），让宽度为2的基本数据类型（short等）都位于能被2整除的地址上，让宽度

为4的基本数据类型（int等）都位于能被4整除的地址上，以此类推。这样，两个数中间就

可能需要加入填充字节，所以整个结构体的sizeof值就增长了。

让我们交换一下S1中char与int的位置：

struct S2

int i;

char c;

\};

看看sizeof(S2)的结果为多少，怎么还是8？再看看内存，原来成员c后面仍然有3个填充字

节，这又是为什么啊？别着急，下面总结规律。

字节对齐的细节和编译器实现相关，但一般而言，满足三个准则：

1) 结构体变量的首地址能够被其最宽基本类型成员的大小所整除；

2) 结构体每个成员相对于结构体首地址的偏移量（offset）都是成员大小的整数倍，如有

需要编译器会在成员之间加上填充字节（internal adding）；

3) 结构体的总大小为结构体最宽基本类型成员大小的整数倍，如有需要编译器会在最末一

个成员之后加上填充字节（trailing padding）。

对于上面的准则，有几点需要说明：

1) 前面不是说结构体成员的地址是其大小的整数倍，怎么又说到偏移量了呢？因为有了第

1点存在，所以我们就可以只考虑成员的偏移量，这样思考起来简单。想想为什么。

结构体某个成员相对于结构体首地址的偏移量可以通过宏offsetof()来获得，这个宏也在

stddef.h中定义，如下：

\#define offsetof(s,m) (size\_t)&(((s \*)0)->m)

例如，想要获得S2中c的偏移量，方法为

size\_t pos = offsetof(S2, c);// pos等于4

2) 基本类型是指前面提到的像char、short、int、float、double这样的内置数据类型，

这里所说的“数据宽度”就是指其sizeof的大小。由于结构体的成员可以是复合类型，比

如另外一个结构体，所以在寻找最宽基本类型成员时，应当包括复合类型成员的子成员，

而不是把复合成员看成是一个整体。但在确定复合类型成员的偏移位置时则是将复合类型

作为整体看待。

这里叙述起来有点拗口，思考起来也有点挠头，还是让我们看看例子吧（具体数值仍以VC

6为例，以后不再说明）：

struct S3

char c1;

S1 s;

char c2

\};

S1的最宽简单成员的类型为int，S3在考虑最宽简单类型成员时是将S1“打散”看的，所以

S3的最宽简单类型为int，这样，通过S3定义的变量，其存储空间首地址需要被4整除，整

个sizeof(S3)的值也应该被4整除。

c1的偏移量为0，s的偏移量呢？这时s是一个整体，它作为结构体变量也满足前面三个准则

，所以其大小为8，偏移量为4，c1与s之间便需要3个填充字节，而c2与s之间就不需要了，

所以c2的偏移量为12，算上c2的大小为13，13是不能被4整除的，这样末尾还得补上3个填

充字节。最后得到sizeof(S3)的值为16。

通过上面的叙述，我们可以得到一个公式：

结构体的大小等于最后一个成员的偏移量加上其大小再加上末尾的填充字节数目，即：

sizeof( struct ) = offsetof( last item ) + sizeof( last item ) + sizeof( trail

ing padding )

到这里，朋友们应该对结构体的sizeof有了一个全新的认识，但不要高兴得太早，有一个

影响sizeof的重要参量还未被提及，那便是编译器的pack指令。它是用来调整结构体对齐

方式的，不同编译器名称和用法略有不同，VC6中通过\#pragma pack实现，也可以直接修改

/Zp编译开关。\#pragma pack的基本用法为：\#pragma pack( n )，n为字节对齐数，其取值

为1、2、4、8、16，默认是8，如果这个值比结构体成员的sizeof值小，那么该成员的偏移

量应该以此值为准，即是说，结构体成员的偏移量应该取二者的最小值，公式如下：

offsetof( item ) = min( n, sizeof( item ) )

再看示例：

\#pragma pack(push) // 将当前pack设置压栈保存

\#pragma pack(2)// 必须在结构体定义之前使用

struct S1

char c;

int i;

\};

struct S3

char c1;

S1 s;

char c2

\};

\#pragma pack(pop) // 恢复先前的pack设置

计算sizeof(S1)时，min(2, sizeof(i))的值为2，所以i的偏移量为2，加上sizeof(i)等于

6，能够被2整除，所以整个S1的大小为6。

同样，对于sizeof(S3)，s的偏移量为2，c2的偏移量为8，加上sizeof(c2)等于9，不能被

2整除，添加一个填充字节，所以sizeof(S3)等于10。

现在，朋友们可以轻松的出一口气了，

还有一点要注意，“空结构体”（不含数据成员）的大小不为0，而是1。试想一个“不占

空间”的变量如何被取地址、两个不同的“空结构体”变量又如何得以区分呢？于是，“

空结构体”变量也得被存储，这样编译器也就只能为其分配一个字节的空间用于占位了。

如下：

struct S5 \{ \};

sizeof( S5 ); // 结果为1

8. 含位域结构体的sizeof

前面已经说过，位域成员不能单独被取sizeof值，我们这里要讨论的是含有位域的结构体

的sizeof，只是考虑到其特殊性而将其专门列了出来。

C99规定int、unsigned int和bool可以作为位域类型，但编译器几乎都对此作了扩展，允

许其它类型类型的存在。

使用位域的主要目的是压缩存储，其大致规则为：

1) 如果相邻位域字段的类型相同，且其位宽之和小于类型的sizeof大小，则后面的字段将

紧邻前一个字段存储，直到不能容纳为止；

2) 如果相邻位域字段的类型相同，但其位宽之和大于类型的sizeof大小，则后面的字段将

从新的存储单元开始，其偏移量为其类型大小的整数倍；

3) 如果相邻的位域字段的类型不同，则各编译器的具体实现有差异，VC6采取不压缩方式

，Dev-C++采取压缩方式；

4) 如果位域字段之间穿插着非位域字段，则不进行压缩；

5) 整个结构体的总大小为最宽基本类型成员大小的整数倍。

还是让我们来看看例子。

示例1：

struct BF1

char f1 : 3;

char f2 : 4;

char f3 : 5;

\};

其内存布局为：

|\_f1\_\_|\_\_f2\_\_|\_|\_\_\_\_f3\_\_\_|\_\_\_\_|

|\_|\_|\_|\_|\_|\_|\_|\_|\_|\_|\_|\_|\_|\_|\_|\_|

0 3 7 8 1316

位域类型为char，第1个字节仅能容纳下f1和f2，所以f2被压缩到第1个字节中，而f3只能

从下一个字节开始。因此sizeof(BF1)的结果为2。

示例2：

struct BF2

char f1 : 3;

short f2 : 4;

char f3 : 5;

\};

由于相邻位域类型不同，在VC6中其sizeof为6，在Dev-C++中为2。

示例3：

struct BF3

char f1 : 3;

char f2;

char f3 : 5;

\};

非位域字段穿插在其中，不会产生压缩，在VC6和Dev-C++中得到的大小均为3。

9. 联合体的sizeof

结构体在内存组织上是顺序式的，联合体则是重叠式，各成员共享一段内存，所以整个联

合体的sizeof也就是每个成员sizeof的最大值。结构体的成员也可以是复合类型，这里，

复合类型成员是被作为整体考虑的。

所以，下面例子中，U的sizeof值等于sizeof(s)。

union U

int i;

char c;

S1 s;

\};

# 详解结构体、类等内存字节对齐 #

[http://www.2cto.com/kf/201109/105769.html][http_www.2cto.com_kf_201109_105769.html]

先说个题外话：早些年我学C程序设计时，写过一段解释硬盘MBR分区表的代码，对着磁盘编辑器怎么看，怎么对，可一执行，结果就错了。当时调试也不太会，又根本没听过结构体对齐这一说，所以，问题解决不了，好几天都十分纠结。后来万般无奈请教一个朋友，才获悉可能是结构体对齐的事，一查、一改，果真 如此。  
问题是解决了，可网上的资料多数只提到内存对齐是如何做的，却鲜有提及为什么这样做(即使提，也相当简单)。笔者是个超级健忘者，很难机械式的记住这些破规则，于是仔细想了想，总算明白了原因，这样，这些对齐的规则也就不会再轻易忘记了。  
不光结构体存在内存对齐一说，类(对象)也如此，甚至于所有变量在内存中的存储也有对齐一说(只是这些对程序员是透明的，不需要关心)。实际上，这种对齐 是为了在空间与复杂度上达到平衡的一种技术手段，简单的讲，是为了在可接受的空间浪费的前提下，尽可能的提高对相同运算过程的最少(快)处理。先举个例 子：  
假设机器字长是32位的(即4字节，下面示例均按此字长)，也就是说处理任何内存中的数据，其实都是按32位的单位进行的。现在有2个变量：  
char A;  
int B;  
假设这2个变量是从内存地址0开始分配的，如果不考虑对齐，应该是这样存储的(见下图,以intel上的little endian为例，为了形象，每16个字节分做一行，后同)：

因为计算机的字长是4字节的，所以在处理变量A与B时的过程可能大致为：  
 A:将0x00-0x03共32位读入寄存器，再通过左移24位再右移24位运算得到a的值(或与0x000000FF做与运算)  
B:将0x00-0x03这32位读入寄存器，通过位运算得到低24位的值；再将0x04-0x07这32位读入寄存器，通过位运算得到高8位的值；再与最先得到的24位做位运算，才可得到整个32位的值。  
上面叙述可知，对a的处理是最简处理，可对b的处理，本身是个32位数，处理的时候却得折成2部分，之后再合并，效率上就有些低了。  
想解决这个问题，就需要付出几个字节浪费的代价，改为下图的分配方式：

按上面的分配方式，A的处理过程不变；B却简单得多了：只需将0x04-0x07这32位读入寄存器就OK了。  
我们可以具体谈结构体或类成员的对齐了：  
结构体在编译成机器代码后，其实就没有本身的集合概念了，而类，实际上是个加强版的结构体，类的对象在实例化时，内存中申请的就是一些变量的空间集合(类 似于结构体，同时也不包含函数指针)。这些集合中的每个变量，在使用中，都需要涉及上述的加工原则，自然也就需要在效率与空间之间做出权衡。  
为了便捷加工连续多个相同类型原始变量，同时简化原始变量寻址，再汇总上述最少处理原则，通常可以将原始变量的长度做为针对此变量的分配单位，比如内存可用64个单元，如果某原始变量长度为8字节，即使机器字长为4字节，分配的时候也以8字节对齐(看似IO次数是相同的)，这样，寻址、分配时，均可以按每 8字节为单位进行，简化了操作，也可以更高效。  
系统默认的对齐规则，追求的至少两点：1、变量的最高效加工 2、达到目的1的最少空间  
举个例子，一个结构体如下：  
  
//by [www.datahf.net][] zhangyu  
typedef struct T  
\{  
char c; //本身长度1字节  
 \_\_int64 d; //本身长度8字节  
 int e; //本身长度4字节  
 short f; //本身长度2字节  
 char g; //本身长度1字节  
 short h; //本身长度2字节  
\};  
假设定义了一个结构体变量C，在内存中分配到了0x00的位置，显然：  
对于成员C.c 无论如何，也是一次寄存器读入，所以先占一个字节。  
对于成员C.d 是个64位的变量，如果紧跟着C.c存储，则读入寄存器至少需要3次，为了实现最少的2次读入，至少需要以4字节对齐；同时对于8字节的原始变量，为了在寻址单位上统一，则需要按8字节对齐，所以，应该分配到0x08-0xF的位置。  
对于成员C.e 是个32位的变量，自然只需满足分配起始为整数个32位即可，所以分配至0x10-0x13。  
对于成员C.f 是个16位的变量，直接分配在0x14-0x16上，这样，反正只需一次读入寄存器后加工，边界也与16位对齐。  
对于成员C.g 是个8位的变量，本身也得一次读入寄存器后加工，同时对于1个字节的变量，存储在任何字节开始都是对齐，所以，分配到0x17的位置。  
对于成员C.h 是个16位的变量，为了保证与16位边界对齐，所以，分配到0x18-0x1A的位置。  
分配图如下(还不正确，耐心读下去)：

结构体C的占用空间到h结束就可以了吗?我们找个示例：如果定义一个结构体数组 CA\[2\]，按变量分配的原则，这2个结构体应该是在内存中连续存储的，分配应该如下图：

分析一下上图，明显可知，CA\[1\]的很多成员都不再对齐了，究其原因，是结构体的开始边界不对齐。  
那结构体的开始偏移满足什么条件才可以使其成员全部对齐呢。想一想就明白了：很简单，保证结构体长度是原始成员最长分配的整数倍即可。  
上述结构体应该按最长的.d成员对齐，即与8字节对齐，这样正确的分配图如下：

当然结构体T的长度:sizeof(T)==0x20;  
再举个例子，看看在默认对齐规则下，各结构体成员的对齐规则：  
  
//by [www.datahf.net][] zhangyu  
typedef struct A  
\{  
char c; //1个字节  
 int d; //4个字节，要与4字节对齐，所以分配至第4个字节处  
 short e; //2个字节， 上述两个成员过后，本身就是与2对齐的，所以之前无填充  
 \}; //整个结构体，最长的成员为4个字节，需要总长度与4字节对齐，所以， sizeof(A)==12  
typedef struct B  
\{  
char c; //1个字节  
 \_\_int64 d; //8个字节，位置要与8字节对齐，所以分配到第8个字节处  
 int e; //4个字节，成员d结束于15字节，紧跟的16字节对齐于4字节，所以分配到16-19  
short f; //2个字节，成员e结束于19字节，紧跟的20字节对齐于2字节，所以分配到20-21  
A g; //结构体长为12字节，最长成员为4字节，需按4字节对齐，所以前面跳过2个字节,  
//到24-35字节处  
 char h; //1个字节，分配到36字节处  
 int i; //4个字节，要对齐4字节，跳过3字节，分配到40-43 字节  
\}; //整个结构体的最大分配成员为8字节，所以结构体后面加5字节填充，被到48字节。故：  
//sizeof(B)==48;  
具体的分配图如下：

上述全部测试代码如下：  
  
//by [www.datahf.net][] zhangyu  
\#include "stdio.h"  
typedef struct A  
\{  
char c;  
int d;  
short e;  
  
\};  
typedef struct B  
\{  
char c;  
\_\_int64 d;  
int e;  
short f;  
A g;  
char h;  
int i;  
\};  
typedef struct C  
\{  
char c;  
\_\_int64 d;  
int e;  
short f;  
char g;  
short h;  
\};  
typedef struct D  
\{  
char a;  
short b;  
char c;  
\};  
int main()  
\{  
  
B \*b=new B;  
void \*s\[32\];  
s\[0\]=b;  
s\[1\]=&b->c;  
s\[2\]=&b->d;  
s\[3\]=&b->e;  
s\[4\]=&b->f;  
s\[5\]=&b->g;  
s\[6\]=&b->h;  
s\[7\]=&b->g.c;  
s\[8\]=&b->g.d;  
s\[9\]=&b->g.e;  
s\[10\]=&b->i;  
b->c= 0x11;  
b->d= 0x2222222222222222;  
b->e= 0x33333333;  
b->f=0x4444;  
b->g.c=0x50;  
b->g.d=0x51515151;  
b->g.e=0x5252;  
b->h=0x66;  
int i1=sizeof(A);  
int i2=sizeof(B);  
int i3=sizeof(C);  
int i4=sizeof(D);  
printf("i1:%d\\ni2:%d\\ni3:%d\\ni4:%d\\n",i1,i2,i3,i4);//12 48 32 6  
\}  
运行时的内存情况如下图：

最后，简单加工一下转载过来的内存对齐正式原则：  
  
先介绍四个概念：  
1)数据类型自身的对齐值：基本数据类型的自身对齐值，等于sizeof(基本数据类型)。  
2)指定对齐值：\#pragma pack (value)时的指定对齐值value。  
3)结构体或者类的自身对齐值：其成员中自身对齐值最大的那个值。  
4)数据成员、结构体和类的有效对齐值：自身对齐值和指定对齐值中较小的那个值。  
有效对齐值N是最终用来决定数据存放地址方式的值，最重要。有效对齐N，就是表示“对齐在N上”，也就是说该数据的"存放起始地址%N=0".而数据结构 中的数据变量都是按定义的先后顺序来排放的。第一个数据变量的起始地址就是 数据结构的起始地址。结构体的成员变量要对齐排放，结构体本身也要根据自身的有效对齐值圆整(就是结构体成员变量占用总长度需要是对结构体有效对齐值的整 数倍)  
  
\#pragma pack (value)来告诉编译器，使用我们指定的对齐值来取代缺省的。  
如\#pragma pack (1) /\*指定按2字节对齐\*/  
\#pragma pack () /\*取消指定对齐，恢复缺省对齐\*/  
  
  
作者“张宇(数据恢复)”

\[StructLayout(LayoutKind.Explicit)\]  
public struct pp  
\{  
\[FieldOffset(4)\]  
public tt ts; -------这个大小是56  
\[FieldOffset(1)\]  
public char errorcode;-----这个应该是1  
  
\}

using System.Runtime.InteropServices;  
  
  
\[StructLayout(LayoutKind.Explicit)\]  
struct abc  
\{  
\[FieldOffset(0)\]  
//字段.......  
\[FieldOffset(2)\]  
//字段..........  
\[FieldOffset(4)\]  
//字段...........  
\}

# C\#中struct的内存对齐 #

[http://qingchina.bokee.com/3399821.html][http_qingchina.bokee.com_3399821.html]

author: 李艳庆 QQ: 375369930  
date: 2005年11月3日

很少有人谈起struct的内存对齐问题, 就是在很多C\#书中, 也很少提及. 但在实际应用中, 如果不注意内存对齐, struct比较大的话, 则会浪费一定的内存.  
先从一个实例看起.  
public unsafe struct MyStruct1  
\{  
byte b;  
string s;  
int i;  
char c;  
\}  
在这个struct中, 各个成员的字节数为, b:1, s:4, i:4, c:1. s为指针, 所以为4个字节. 把这些成员的字节数加起来应该为10个字节, 很多人都是这么理所当然的认为.但实际上呢, 却并非如此. 可以做一个测试.  
public class test  
\{  
  
public static void Main()  
\{  
MyValue mv = new MyValue();  
int size = System.Runtime.InteropServices.Marshal.SizeOf(mv);  
Console.WriteLine(size.ToString());  
\}  
  
\}  
结果显示为16个字节, 与所想的有一定差距. 为什么会出现这种情况呢, 这就涉及到了内存对齐的问题struct member alignment.  
在编译器中使用内存对齐, 是为了提高程序的性能. 访问未对齐的内存, 处理器需要做两次的内存访问, 但是, 对齐的内存, 仅需一次. 因为编译器将struct与自然边界对象. 自然边界为偶数地址, 可以被4或8整除. 一个struct的成员字节跨越了自然边界数, 认为是未对齐, 如果没有跨越, 可以访问一次就能读取.  
我们再来分析上面的struct. struct在分配内存的时候, 各个成员的地址是相邻的. C\#中alignment的字节数为4个字节. 因此, 它将4个字节作为一个分配单元. 如果相邻的几个成员字节数相加不超过一个分配单元, 则这几个成员都会在一个分配单元中. 上面的struct中, b为1个字节, s为4个字节, 相加后超过了一个分配单元的大小, 因此它们被分配到两个单元中, 每个所占空间为4个字节. 成员i和c的情况亦是如此. 因此, 上面的struct被分配了4个单元, 所占内存就为16个字节, 而不是简单相加所得到的10个字节.  
现在我们把上面的struct做一个调整, 将byte类型和char类型相邻.  
public unsafe struct MyStruct2  
\{  
byte b;  
char c;  
string s;  
int i;  
\}  
现在再来测试一下它的内存大小, 结果为12. 它变小了, 少了4个字节. 按照上面所讲的原理, b和c相加, 没有超过4个字节, 因此它们被分配到一个单元中, 总得分配单元为3个, 因此结果变为12个字节.  
明白了这个道理, 以后在设计struct时, 就要struct的成员类型和位置多做一些思考了.

# [.NET Compact Framework结构体的对齐问题][.NET Compact Framework] #

[http://www.cnblogs.com/procoder/archive/2010/08/30/NET-Compact-Framework-aligment.html][.NET Compact Framework]

使用.NET Compact Framework进行P/Invoke或者需要解析异构系统的数据时，需要准备结构体。如下：

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]
    internal struct TestStruct
    {
        [MarshalAs(UnmanagedType.R8)]
        public double f1; 
    }

在.NET Framework StructLayoutAttribute包含了一个Pack属性，可以指定对齐，可是在.NET Compact Framework去掉了这个属性，所有没有办法知道对齐方式的，在ARM平台下，默认的对齐为4.另外一个可能的解决方案是使用 TypeAttributes.ExplicitLayout，入下图，在.NET Framework，下面的结构体的长度是10，可是在.NET Compact Framework长度是12，为什么呢？

[StructLayout(LayoutKind.Explicit, CharSet = CharSet.Auto)]
    internal struct TestStruct
    {
        [FieldOffset(0)]
        public byte b1;
        [FieldOffset(1)]
        public byte b1;
        [FieldOffset(2)]
        public double f1; 
    }

看源码能找到原因，下面是.NET Compact Framework 2.0 StructLayoutAttribute的源代码

[AttributeUsage(AttributeTargets.Struct | AttributeTargets.Class, Inherited = false)]
    public sealed class StructLayoutAttribute : Attribute
    {
        // Fields
        public CharSet CharSet;
    
        public int Size;
    
    
        // Methods
        public StructLayoutAttribute(LayoutKind layoutKind)
        {
        }
    }

下面是.NET Framework 4.0 StructLayoutAttribute的源码

[AttributeUsage(AttributeTargets.Struct | AttributeTargets.Class, Inherited = false), ComVisible(true)]
    public sealed class StructLayoutAttribute : Attribute
    {
        // Fields
        internal LayoutKind _val;
        public CharSet CharSet;
        private const int DEFAULT_PACKING_SIZE = 8;
        public int Pack;
        public int Size;
    
        // Methods
        [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
        public StructLayoutAttribute(short layoutKind)
        {
            this._val = (LayoutKind)layoutKind;
        }
    
        [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
        public StructLayoutAttribute(LayoutKind layoutKind)
        {
            this._val = layoutKind;
        }
    
        [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
        internal StructLayoutAttribute(LayoutKind layoutKind, int pack, int size, CharSet charSet)
        {
            this._val = layoutKind;
            this.Pack = pack;
            this.Size = size;
            this.CharSet = charSet;
        }
    
        [SecurityCritical]
        internal static Attribute GetCustomAttribute(RuntimeType type)
        {
            if (!IsDefined(type))
            {
                return null;
            }
            int packSize = 0;
            int classSize = 0;
            LayoutKind auto = LayoutKind.Auto;
            switch ((type.Attributes & TypeAttributes.LayoutMask))
            {
                case TypeAttributes.AutoLayout:
                    auto = LayoutKind.Auto;
                    break;
    
                case TypeAttributes.SequentialLayout:
                    auto = LayoutKind.Sequential;
                    break;
    
                case TypeAttributes.ExplicitLayout:
                    auto = LayoutKind.Explicit;
                    break;
            }
            CharSet none = CharSet.None;
            TypeAttributes attributes2 = type.Attributes & TypeAttributes.CustomFormatClass;
            if (attributes2 == TypeAttributes.AutoLayout)
            {
                none = CharSet.Ansi;
            }
            else if (attributes2 == TypeAttributes.UnicodeClass)
            {
                none = CharSet.Unicode;
            }
            else if (attributes2 == TypeAttributes.AutoClass)
            {
                none = CharSet.Auto;
            }
            type.GetRuntimeModule().MetadataImport.GetClassLayout(type.MetadataToken, out packSize, out classSize);
            if (packSize == 0)
            {
                packSize = 8;
            }
            return new StructLayoutAttribute(auto, packSize, classSize, none);
        }
    
        internal static bool IsDefined(RuntimeType type)
        {
            return ((!type.IsInterface && !type.HasElementType) && !type.IsGenericParameter);
        }
    
        // Properties
        public LayoutKind Value
        {
            [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
            get
            {
                return this._val;
            }
        }
    }

在.NET Compact Framework完全没有实现StructLayoutAttribute ，所有不管使用LayoutKind.Sequential还是LayoutKind.Explicit默认还是使用Sequential。所以如果在.NET Compact Framework解析异构系统的结构体，只能使用byte\[\]一点点手工解析了。换句话说就是把int，float等数据类型转换成byte的数组，然后放到相应的位置上。

[http_blog.163.com_ecy_fu_blog_static_4445126200910603739941]: http://blog.163.com/ecy_fu/blog/static/4445126200910603739941/
[http_hi.baidu.com_skyland_lee_blog_item_45604bca81e1928cc91768d7.html]: http://hi.baidu.com/skyland_lee/blog/item/45604bca81e1928cc91768d7.html
[C]: http://blog.csdn.net/shenbin1430/article/details/4292463
[http_www.2cto.com_kf_201109_105769.html]: http://www.2cto.com/kf/201109/105769.html
[www.datahf.net]: http://www.datahf.net/
[http_qingchina.bokee.com_3399821.html]: http://qingchina.bokee.com/3399821.html
[.NET Compact Framework]: http://www.cnblogs.com/procoder/archive/2010/08/30/NET-Compact-Framework-aligment.html