概念
在C语言中,结构是一种复合数据类型,其构成元素既可以是基本数据类型(如int、long、float等)的变量,也可以是一些复合数据类型(如数组、结构、联合等)的数据单元。在结构中,编译器为结构的每个成员按其自然边界(alignment)分配空间。各个成员按照它们被声明的顺序在内存中顺序存储,第一个成员的地址和整个结构的地址相同。
为了使CPU能够对变量进行快速的访问,变量的起始地址应该具有某些特性,即所谓的”对齐”,比如4字节的int型,其起始地址应该位于4字节的边界上,即起始地址能够被4整除,也即对齐跟数据在内存中的位置有关。如果一个变量的内存地址正好位于它长度的整数倍,他就被称做自然对齐。
比如在32位cpu下,假设一个整型变量的地址为0x00000004(为4的倍数),那它就是自然对齐的,而如果其地址为0x00000002(非4的倍数)则是非对齐的。
现代计算机中内存空间都是按照byte划分的,从理论上讲似乎对任何类型的变量的访问可以从任何地址开始,但实际情况是在访问特定类型变量的时候经常在特定的内存地址访问,这就需要各种类型数据按照一定的规则在空间上排列,而不是顺序的一个接一个的排放,这就是对齐。
为什么要字节对齐
需要字节对齐的根本原因在于CPU访问数据的效率问题。假设上面整型变量的地址不是自然对齐,比如为0x00000002,则CPU如果取它的值的话需要访问两次内存,第一次取从0x00000002-0x00000003的一个short,第二次取从0x00000004-0x00000005的一个short然后组合得到所要的数据,如果变量在0x00000003地址上的话则要访问三次内存,第一次为char,第二次为short,第三次为char,然后组合得到整型数据。
而如果变量在自然对齐位置上,则只要一次就可以取出数据。一些系统对对齐要求非常严格,比如sparc系统,如果取未对齐的数据会发生错误,而在x86上就不会出现错误,只是效率下降。
各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。
比如有些架构的CPU在访问一个没有进行对齐的变量的时候会发生错误,那么在这种架构下编程必须保证字节对齐,但其他平台可能没有这种情况,但是最常见的是如果不按照适合其平台要求对数据存放进行对齐,会在存取效率上带来损失。
比如有些平台每次读都是从偶地址开始,如果一个int型(假设为32位系统)如果存放在偶地址开始的地方,那么一个读周期就可以读出这32bit,而如果存放在奇地址开始的地方,就需要2个读周期,并对两次读出的结果的高低字节进行拼凑才能得到该32bit数据。显然在读取效率上下降很多。
另外字节对齐的作用不仅是便于cpu快速访问,同时合理的利用字节对齐可以==有效地节省存储空间==。
也即CPU一次访问时,要么读0x01~0x04,要么读0x05~0x08…硬件不支持一次访问就读到0x02~0x05
例:如果0x02~0x05存了一个int,读取这个int就需要先读0x01~0x04,留下0x02~0x04的内容,再读0x05~0x08,留下0x05的内容,两部分拼接起来才能得到那个int的值,这样读一个int就要两次内存访问,效率就低了。
针对字节对齐,我们在编程中如何考虑?
先让我们看编译器是按照什么样的原则进行对齐的:
数据类型自身的对齐值:为指定平台上基本类型的长度。对于char型数据,其自身对齐值为1,对于short型为2,对于int,float,double类型,其自身对齐值为4,单位字节。
结构体或者类的自身对齐值:其成员中自身对齐值最大的那个值。
指定对齐值:#pragma pack (value)时的指定对齐值value。
数据成员、结构体和类的有效对齐值:自身对齐值和指定对齐值中小的那个值。
对于标准数据类型,它的地址只要是它的长度的整数倍就行了,而非标准数据类型按下面的原则对齐:
数组 :按照基本数据类型对齐,第一个对齐了后面的自然也就对齐了。
联合 :按其包含的长度最大的数据类型对齐。
结构体: 结构体中每个数据类型都要对齐。
当数据类型为结构体时,编译器可能需要在结构体字段的分配中插入间隙,以保证每个结构元素都满足它的对齐要求。第一个数据变量的起始地址就是数据结构的起始地址。结构体的成员变量要对齐排放(对于非对齐成员需要在其前面填充一些字节,保证其在对齐位置上),结构体本身也要根据自身的有效对齐值圆整(就是结构体总长度需要是结构体有效对齐值的整数倍),此时可能需要在结构末尾填充一些空间,以满足结构体整体的对齐—-向结构体元素中最大的元素对齐。
通过上面的分析,对结构体进行字节对齐,我们需要知道四个值:
指定对齐值:代码中指定的对齐值,记为packLen;
默认对齐值:结构体中每个数据成员及结构体本身都有默认对齐值,记为defaultLen;
成员偏移量:即相对于结构体起始位置的长度,记为offset;
成员长度:结构体中每个数据成员的长度(注结构体成员为补齐之后的长度),记为memberLen。
及两个规则:
对齐规则: offset % vaildLen = 0,其中vaildLen为有效对齐值vaildLen = min(packLen, defaultLen);
填充规则: 如成员变量不遵守对齐规则,则需要对其补齐;在其前面填充一些字节保证该成员对齐。需填充的字节数记为pad
Linux和Microsoft Windows的对齐方式
一.Linux的对齐策略:
在Linux中2字节数据类型(例如short)的地址必须是2的倍数,而较大的数据类型(例如int,int *,float和double)的地址必须是4的倍数。也就是说Linux下要么2字节对齐,要么4字节对齐,没有其他格式的对齐。
二.Microsoft Windows的对齐策略:
在Windows中对齐要求更严–任何K字节基本对象的地址都必须是K的倍数,K=2,4,或者8.特别地,double或者long long类型数据的地址应该是8的倍数。可以看出Windows的对齐策略和Linux还是不同的。
更改C编译器的缺省字节对齐方式
在缺省情况下,C编译器为每一个变量或是数据单元按其自然对界条件分配空间。一般地,可以通过下面的方法来改变缺省的对界条件:
使用伪指令#pragma pack (n),C编译器将按照n个字节对齐。
使用伪指令#pragma pack (),取消自定义字节对齐方式。
另外,还有如下的一种方式:
__attribute((aligned (n))),让所作用的结构成员对齐在n字节自然边界上。如果结构中有成员的长度大于n,则按照最大成员的长度来对齐。
__attribute__ ((packed)),取消结构在编译过程中的优化对齐,按照实际占用字节数进行对齐。
字节对齐的作用不仅是便于cpu快速访问,同时合理的利用字节对齐可以有效地节省存储空间。
对于32位机来说,4字节对齐能够使cpu访问速度提高,比如说一个long类型的变量,如果跨越了4字节边界存储,那么cpu要读取两次,这样效率就低了。但是在32位机中使用1字节或者2字节对齐,反而会使变量访问速度降低。所以这要考虑处理器类型,另外还得考虑编译器的类型。在vc中默认是4字节对齐的,GNU gcc 也是默认4字节对齐。
什么时候需要设置对齐
在设计不同CPU下的通信协议时,或者编写硬件驱动程序时寄存器的结构这两个地方都需要按一字节对齐。即使看起来本来就自然对齐的也要使其对齐,以免不同的编译器生成的代码不一样.
结构体举例
例子1
/************************
> File Name: struct_test.c
> Author:Marvin
> Created Time: Thu 22 Mar 2018 07:19:46 PM CST
**********************/
#include<stdio.h>
int main()
{
struct test {
char a;
short b;
int c;
long d;
};
struct test t = {'a',11,11,11};
printf("size of struct t = %u\n", sizeof(t));
return 0;
}
在64位centos上编译编译后结构struct test的布局如下:
由于要保证结构体每个元素都要数据对齐,因此必须在a和b之间插入1字节的间隙使得后面的short元素2字节对齐int元素4字节对齐long元素8字节对齐,这样最终test结构大小为16字节。
运行程序结果为:
size of struct t = 16
例子2
现在考虑这样一个结构体:
struct test2 {
int a;
long b;
char c;
};
struct test2 t2 = {11,11,'c'};
在64位centos上编译编译后结构struct test2的布局如下:
结构体struct test2的自然对界条件为8字节,所以需要在最后的char型数据后面再填充7个字节使得结构体整体对齐。
运行程序结构为
size of struct test2 = 24
例子3
不妨将结构体struct test2里面成员的顺序重新排列一下:
struct test3 {
char c;
int a;
long b;
};
struct test3 t3 = {'c',11,11};
在64位centos上编译编译后结构struct test2的布局如下:
运行结果为:
size of struct test3 = 16
可见适当地编排结构体成员地顺序,可以在保存相同信息地情况下尽可能节约内存空间。
例子4
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,这些已有类型的自身对齐值也是基于数组考虑的,只是因为这些类型的长度已知了,所以他们的自身对齐值也就已知了.
例子5
#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.
对于结构体嵌套地情况,结构体对齐算法思想:深度优先填充。
padLen = getPadLen(offset , defaultLen);
int getPadLen(int offsetLen, int defaultLen)
{
int vaildLen = min(packLen,defaultLen);
if(0 == vaildLen || 0 == offsetLen % vaildLen)
{
return 0;
}
return vaildLen - (offsetLen % vaildLen);
}
先对齐内层结构体:对每个数据成员计算其defaultLen、memberLen和offset;
再遍历每个数据成员时计算:对于基本数据类型成员defaultLen=memberLen;对于结构体成员defaultLen等于它的所有成员的最大的memberLen;遍历时对成员的memberLen进行累加,得到当前成员的offsetLen;
运用对齐及填充规则:在当前结构体成员前填充padLen个字节;
下面是结构体作为成员的例子:
struct test1 {
int a;
long b;
};
struct test4 {
char a;
struct test1 b;
int c;
};
struct test4 t4 = {'a', {11,11},11}
test1的内存分布:
test4的内存分布:
字节对齐可能带来的隐患
代码中关于对齐的隐患,很多是隐式的,比如在强制类型转换的时候,例如:
unsigned int i = 0x12345678;
unsigned char *p = NULL;
unsigned short *p1 = NULL;
p = &i; //这里可假设p指向了一个4的整数倍地址,例如0x04
*p = 0x00;
p1 = (unsigned short *)(p + 1); //这里p1指向了p后移一位,也即为0x05
*p1 = 0x0000;
这样最后两句代码,从奇数边界去访问unsigned short型变量,显然不符合对齐的规定,在x86上,类似的操作只会影响效率,但是在MIPS或者sparc上,可能就是一个error,因为它们要求必须字节对齐.
如何查找与字节对齐方面的问题
如果出现对齐或者赋值问题首先查看编译器的big little端设置
看这种体系本身是否支持非对齐访问
如果支持看设置了对齐与否,如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作
举例:
#include<iostream>
using namespace std;
//windows 64 位默认 结构体对齐系数为8,32位 结构体对齐系数为4
//测试系统对齐系数
// #pragma pack(8) my_struct_1 为16字节
// #pragma pack(4) my_struct_1 为12字节
// 不加#pragma pack(8) my_struct_1 为16字节
//顾系统默认对齐系数为8
struct my_struct_1
{
char a; //1
double b; //之前补7 +8 8/8==1
};
#pragma pack(4)
struct my_struct_2
{
char a; //1
double b; //3+8
int c; //4 16/4=4
};
#pragma pack()
#pragma pack(2)
struct my_struct_3
{
char a; //1
double b; //1+8
int c; //4 14/2
};
#pragma pack()
#pragma pack(4)
struct my_struct_4
{
char a[5]; //5
double b; //3+8 16/4
};
#pragma pack()
#pragma pack(2)
struct my_struct_5
{
char a[5]; //5
double b; //1+8 14/2
};
#pragma pack()
#pragma pack(4)
struct my_struct_6
{
char a; //1
char b[3]; //3
char c; //1 1+3+1
};
#pragma pack()
#pragma pack(4)
struct my_struct_7
{
char a; //1
char b[3]; //3
char c; //1
int d; //补齐 3 +4
};
#pragma pack()
#pragma pack(4)
struct test
{
char x1; //1
short x2; //补齐1+ 2
float x3; //4
char x4; //1 补齐+3
};
#pragma pack()
int main()
{
cout<<"char:"<<sizeof(char)<<endl;
cout<<"short:"<<sizeof(short)<<endl;
cout<<"int:"<<sizeof(int)<<endl;
cout<<"long:"<<sizeof(long)<<endl;
cout<<"float:"<<sizeof(float)<<endl;
cout<<"double:"<<sizeof(double)<<endl;
cout<<"long double:"<<sizeof(long double)<<endl;
cout<<sizeof(my_struct_1)<<endl;//8
cout<<sizeof(my_struct_2)<<endl;//16
cout<<sizeof(my_struct_3)<<endl;//14
cout<<sizeof(my_struct_4)<<endl;//16
cout<<sizeof(my_struct_5)<<endl;//14
cout<<sizeof(my_struct_6)<<endl;//5
cout<<sizeof(my_struct_7)<<endl;//12
cout<<sizeof(test)<<endl;//12
system("pause");
return 0;
}
-----------------------------------------------------------------------------
版权声明:本文借鉴CSDN博主「czw94」的原创文章修改而来,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/cclethe/article/details/79659590