« | October 2025 | » | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | |
| 公告 |
戒除浮躁,读好书,交益友 |
Blog信息 |
blog名称:邢红瑞的blog 日志总数:523 评论数量:1142 留言数量:0 访问次数:9722807 建立时间:2004年12月20日 |

| |
[c++]寻找丢失的内存,关于内存对齐的问题 原创空间, 心得体会
邢红瑞 发表于 2005/3/15 11:09:02 |
最近与东东讨论内存对齐的问题,一个例子
#include <stdio.h>#pragma pack(push,1)struct s1{ int i; int j; char c;} s_1; #pragma pack(pop)
struct s2{ int i; int j; char c;} s_2;
int main(){ s_1.i = 0x49424344; s_1.j = 0x45464748; s_1.c = 'c'; printf("\nTest for struct s1\nsize \t%d\n",sizeof(s_1)); fwrite(&s_1,sizeof(s_1),1,stdout); fflush(stdout);
s_2.i = 0x494A4B4C; s_2.j = 0x4D4E4F50; printf("\nTest for struct s2\nsize \t%d\n",sizeof(s_2)); fwrite(&s_2,sizeof(s_2),1,stdout); fflush(stdout);
return 0;}gcc和vc的结果是9,12,tc2的结果都是5,因为tc的int是2位的,对于pc的开发问题不是很大,但是对于嵌入式开发,必须考虑到内存浪费的问题。
一般的编译器要对内存进行对齐,在处理结构体变量时,编译器都会根据一定的设置将长短不同的成员变量的数据长度进行对齐以加快内存处理速度,这就可能造成程序的不同部分对内存的处理出现错误.如一个结构struct a{char i;int j;};尽管i只有一个字节,j占4个字节,但编译器可能为了对齐为i分配4个字节,结果整个结构是8个字节,这就是4字节对齐的情况,而在编译器设为单字节对齐时则正好是5个字节。
#include <stdio.h>struct test{char a;short b;char c;};struct test t;int main(void){ printf("%d",sizeof(t));}
结果是6,为了优化编译器性能,结构体的长度一般会补到2或者4的整数倍,test长度为6,如果把b改为int,结果会变为12,因为此时a和c都会补全到4字节,就是12字节。如果b变为double 8个字节,总长度就是16字节,b和c还是4字节。Struct member alignment用以指定数据结构中的成员变量在内存中是按几字节对齐的,根据计算机数据总线的位数,不同的对齐方式存取数据的速度不一样。这个参数对数据包网络传输等应用尤为重要,不是存取速度问题,而是数据位的精确定义问题,一般在程序中使用#pragma pack来指定。
在Unix系统/GCC编译器中,GCC/G++ : -fpack-struct ,在 Visual C++ 中,使用 "-ZP1" 就可以让编译器对自定义结构进行单字节对齐,实际就是取消了对齐优化。 如果效率非常重要,就尽量不要使用#pragma pack,如果必须使用,也最好仅在需要的地方进行设置。因此需要加pack的地方一定要在定义结构的头文件中加,不要依赖命令行选项,因为如果很多人使用该头文件,并不是每个人都知道应该pack。这特别表现在为别人开发库文件时,如果一个库函数使用了struct作为其参数,当调用者与库文件开发者使用不同的pack时,就会造成错误,而且该类错误很不好查。
在VC及BC提供的头文件中,除了能正好对齐在四字节上的结构外,都加了pack,否则我们编的Windows程序哪一个也不会正常运行。
如果进行网络程序的开发,考虑的不同CPU之间的通信,最好设置为·字节对齐,会减少很多麻烦。 |
|
回复:寻找丢失的内存,关于内存对齐的问题 原创空间, 心得体会
Jobs(游客)发表评论于2005/9/16 18:56:06 |
|
回复:寻找丢失的内存,关于内存对齐的问题 原创空间, 心得体会
agile(游客)发表评论于2005/3/15 12:37:35 |
|
» 1 »
|