关于数据结构8字节对齐的问题(200分)

  • 主题发起人 主题发起人 一个过客
  • 开始时间 开始时间

一个过客

Unregistered / Unconfirmed
GUEST, unregistred user!
最近用java做一个网络项目,服务器端软件(C++代码)已经提供了TCP/IP接口,只不过它的数据结构是8字节对齐的,java很难实现,因此我开始研究8字节对齐的内部实现,正好delphi比较熟悉,而且delphi也支持8字节对齐,因此就用delphi来开始研究吧。

我知道,当我们在delphi中定义如下数据结构,在默认情况下应该就是8字节对齐的:
代码:
  TTest = record
    a:char;
    b:word;
    c:int64;
    d:integer;
  end;

现在我定义一个变量,并且赋值,然后看看内存中数据是怎么排列的:
代码:
var t:TTest;
    s:array of char;
begin
  t.a:='a';
  t.b:=word($1111);
  t.c:=int64($2222222222222222);
  t.d:=integer($33333333);

  setlength(s,sizeof(t));
  fillchar(s[0],sizeof(t),#0);
  copymemory(@s[0],@t,sizeof(t));
按照我的想象,现在s这个数组里面的数据应该是这样的(共24个字节,数据用16进制显示,X表示无效字节,用于填充空位):

[a] [11] [11] [x] [x] [x] [x] [x] [22] [22] [22] [22] [22] [22] [22] [22] [33] [33] [33] [33] [x] [x] [x] [x]

也就是说,为了保证8字节对齐,第一个字节a和后面的两个字节$1111,再加上5个填充字节,构成第一个8字节段,中间8个$2222222222222222构成第二个8字节段,最后四个字节$33333333加上4个填充字节,构成第三个8字节段,总共是24个字节;

但是当我一个一个检查s数组内数据的时候,我发现内存排列并不是这样的,而是:
[red][a] [8] [11] [11][/red] [x] [x] [x] [x] [22] [22] [22] [22] [22] [22] [22] [22] [33] [33] [33] [33] [x] [x] [x] [x]
也就是说,第二个域$1111并没有紧挨着第一个域排列,它们之间有一个$8,这个$8可能也是一个无效的填充字节。这是什么规律呢?

因此我的疑惑就是,delphi里面的8字节对齐,究竟内部实现的规律是什么?它的实现方法是否是标准的?
 
delphi里是32的,应该是32/8=4字节对齐的吧
所以再你的a后面有个填充字节,
两个11之后有4个字节而不是你分析的5个字节
 
如果是4字节,在最后就不用填4个无效字符了
 
不清楚了,可能是因为你使用了int64吧,所以按8字节对齐了,
不过局部方面还是32位对齐的,
 
结构怎么不能改呢,还说是tcp/ip,看来你是不懂.

从网络一头送一个c++要求的数据给它就可以了,它管你结构细节嘛,不管的;
 
研究了一下,抛砖引玉哦.//shangshang.
delphi默认设置是按8字节对齐的,之所以有对齐,是为了优化编译器的访问速度,这大家都知道.但对齐的规则和填充的内容是什么呢,我大概猜想了一下,然后写了几句代码.
type
TTest = record
a:char;
b:word;
c:int64;
d:integer;
end;


function BufToHexStr(ABuf: PChar; ABuf_Len: DWORD): string;
var
i: integer;
begin
Result := '';
for i := 0 to ABuf_Len - 1 do
begin
Result := Result + IntToHex(Byte(ABuf), 2) + ' ';
if (i + 1) mod 16 = 0 then
Result := Result + #13#10;
end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var t:TTest;
s:array of byte;
begin
t.a:='a';
t.b:=word($1111);
t.c:=int64($2222222222222222);
t.d:=integer($33333333);

setlength(s,sizeof(t));
fillchar(s[0],sizeof(t),#0);
copymemory(@s[0],@t,sizeof(t));
edit1.Text:=(BufToHexStr(PChar(@s[0]),SizeOf(t)));
end;

type
TTest2 = record
b:word;
c:int64;
a:char;
d:integer;
end;

procedure TForm1.Button2Click(Sender: TObject);
var t:TTest2;
s:array of byte;
begin
t.a:='a';
t.b:=word($1111);
t.c:=int64($2222222222222222);
t.d:=integer($33333333);

setlength(s,sizeof(t));
fillchar(s[0],sizeof(t),#0);
copymemory(@s[0],@t,sizeof(t));
edit2.Text:=(BufToHexStr(PChar(@s[0]),SizeOf(t)));
end;

TTest1和Test2的差别是我把成员a移到成员c的下面了.
两个edit的结果分别是
TTest1:61 00 11 11 02 00 00 00 22 22 22 22 22 22 22 22
33 33 33 33 4C 2C D3 77
TTest2:11 11 00 00 02 00 00 00 22 22 22 22 22 22 22 22
61 F6 12 00 33 33 33 33

根据我的分析,应该是仍然为了优化访问速度.相连的成员size和小于8,就会放在同一个8字节区域里,这是按8字节对齐的基础,当然不会把一个成员分开放入两个区域的尾和首里.除非这个成员的大小大于8.呵呵.按8字节对齐后,不足8字节的填充的是随机值,因为编译器访问时肯定按数据类型去访问的,不会越界出错
那么,按8自己对齐后的,某个区域中如果有多个成员,又怎么布局的呢?楼主想像是
每个成员紧缩存储在一起,不足8位补充随机值.实际却不是这样,我认为是编译器仍然按上面所述8自己对齐的原理,继续以4,2的长度去对齐每个8字节区域的成员.这样,我上面的例子就能解释了. 我认为这样,仍然可以继续优化编译器的访问速度.
 
楼上的,我说了这个问题是为了java来解决问题的,接口是对方给的,不能更改。

这个问题我经过试验已经搞的差不多清楚了,但是还没有找到权威的资料来证实。
 
噢?你不是要了解delphi8中record 的对齐和填充原理的吗?我说的就是delphi的实现原理啊.他的实现是否和java一样我不敢断言,你只能通过试验得知.但我告诉了delphi的实现方式,你就能分析是否和java一样啦.
再则,我问过lichengbin大侠.他说,delphi的对齐和C++是一致的.
这个地址是讲C++的对齐原理的.
http://www.zahui.com/html/9/18625.htm
 
关注。
试验了一下,
结果如下。
8字节对齐。
1 a后面有一个$00,而不是$8
2 数组最后没有无效的填充字节。

4字节对齐
同8字节对齐一样

1字节对齐
同packed效果一样
总结:
我认为
1 系统是32位的,一次读取16位,(也就是说实际上系统内核还是16的)
在操作1字节8bit时,为了统一格式提高效率,系统会给8位的变量增加一个高位$00
2 在packed时,我认为是系统统一了格式,只是表现形式变了而已。

3 lz的末尾补充的无效字符,很不好解释,但我倾向于认为它是个错误,因为
lz可能把integer($88888888)后面多些了一个2个的,就会出现那样的错误。
因为我在实验的时候也出现这样的错。
参考csdn资料:
http://community.csdn.net/Expert/FAQ/FAQ_Index.asp?id=25108
//============
楼主看看有没有用
看得时候还没人回,现在这么多了。。。。
嗯,若有所得.....
 
偶的例子和分析是能够解释你看到的内存排列现象的.请耐心看一下.呵呵
 
你要认为我的分析纯属臆测,毫无权威性可言,那我没话说了.呵呵.
 
shanghsnag , 不好意思, 我回贴的时候还没看到你的贴子,是说给前面的人听的。
待我仔细看看你的代码,谢谢!!
 
没关系,我也是刚分析了一下,请教了几个人,还有uiit大侠给的一个C++的对齐测试说明;贴出来,希望对你有所帮助.呵呵.



在最近的项目中,我们涉及到了“内存对齐”技术。对于大部分程序员来说,“内存对齐”对他们来说都应该是“透明的”。“内存对齐”应该是编译器的 “管辖范围”。编译器为程序中的每个“数据单元”安排在适当的位置上。但是C语言的一个特点就是太灵活,太强大,它允许你干预“内存对齐”。如果你想了解更加底层的秘密,“内存对齐”对你就不应该再透明了。

一、内存对齐的原因
大部分的参考资料都是如是说的:
1、平台原因(移植原因):不是所有的硬件平台都能访问任意地址上的任意数据的;某些硬件平台只能在某些地址处取某些特定类型的数据,否则抛出硬件异常。
2、性能原因:数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于,为了访问未对齐的内存,处理器需要作两次内存访问;而对齐的内存访问仅需要一次访问。

二、对齐规则
每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。程序员可以通过预编译命令#pragma pack(n),n=1,2,4,8,16来改变这一系数,其中的n就是你要指定的“对齐系数”。

规则:
1、数据成员对齐规则:结构(struct)(或联合(union))的数据成员,第一个数据成员放在offset为0的地方,以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员自身长度中,比较小的那个进行。
2、结构(或联合)的整体对齐规则:在数据成员完成各自对齐之后,结构(或联合)本身也要进行对齐,对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中,比较小的那个进行。
3、结合1、2颗推断:当#pragma pack的n值等于或超过所有数据成员长度的时候,这个n值的大小将不产生任何效果。

三、试验
我们通过一系列例子的详细说明来证明这个规则吧!
我试验用的编译器包括GCC 3.4.2和VC6.0的C编译器,平台为Windows XP + Sp2。

我们将用典型的struct对齐来说明。首先我们定义一个struct:
#pragma pack(n) /* n = 1, 2, 4, 8, 16 */
struct test_t {
  int a;
  char b;
  short c;
  char d;
};
#pragma pack(n)
首先我们首先确认在试验平台上的各个类型的size,经验证两个编译器的输出均为:
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4

我们的试验过程如下:通过#pragma pack(n)改变“对齐系数”,然后察看sizeof(struct test_t)的值。

1、1字节对齐(#pragma pack(1))
输出结果:sizeof(struct test_t) = 8 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(1)
struct test_t {
  int a;  /* 长度4 < 1 按1对齐;起始offset=0 0%1=0;存放位置区间[0,3] */
  char b;  /* 长度1 = 1 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
  short c; /* 长度2 > 1 按1对齐;起始offset=5 5%1=0;存放位置区间[5,6] */
  char d;  /* 长度1 = 1 按1对齐;起始offset=7 7%1=0;存放位置区间[7] */
};
#pragma pack()
成员总大小=8

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 1) = 1
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 8 /* 8%1=0 */ [注1]

2、2字节对齐(#pragma pack(2))
输出结果:sizeof(struct test_t) = 10 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(2)
struct test_t {
  int a;  /* 长度4 > 2 按2对齐;起始offset=0 0%2=0;存放位置区间[0,3] */
  char b;  /* 长度1 < 2 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
  short c; /* 长度2 = 2 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
  char d;  /* 长度1 < 2 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 2) = 2
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 10 /* 10%2=0 */

3、4字节对齐(#pragma pack(4))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(4)
struct test_t {
  int a;  /* 长度4 = 4 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
  char b;  /* 长度1 < 4 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
  short c; /* 长度2 < 4 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
  char d;  /* 长度1 < 4 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 4) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */

4、8字节对齐(#pragma pack(8))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(8)
struct test_t {
  int a;  /* 长度4 < 8 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
  char b;  /* 长度1 < 8 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
  short c; /* 长度2 < 8 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
  char d;  /* 长度1 < 8 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 8) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */


5、16字节对齐(#pragma pack(16))
输出结果:sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程:
1) 成员数据对齐
#pragma pack(16)
struct test_t {
  int a;  /* 长度4 < 16 按4对齐;起始offset=0 0%4=0;存放位置区间[0,3] */
  char b;  /* 长度1 < 16 按1对齐;起始offset=4 4%1=0;存放位置区间[4] */
  short c; /* 长度2 < 16 按2对齐;起始offset=6 6%2=0;存放位置区间[6,7] */
  char d;  /* 长度1 < 16 按1对齐;起始offset=8 8%1=0;存放位置区间[8] */
};
#pragma pack()
成员总大小=9

2) 整体对齐
整体对齐系数 = min((max(int,short,char), 16) = 4
整体大小(size)=$(成员总大小) 按 $(整体对齐系数) 圆整 = 12 /* 12%4=0 */

四、结论
8字节和16字节对齐试验证明了“规则”的第3点:“当#pragma pack的n值等于或超过所有数据成员长度的时候,这个n值的大小将不产生任何效果”。另外内存对齐是个很复杂的东西,上面所说的在有些时候也可能不正确。呵呵^_^

[注1]
什么是“圆整”?
举例说明:如上面的8字节对齐中的“整体对齐”,整体大小=9 按 4 圆整 = 12
圆整的过程:从9开始每次加一,看是否能被4整除,这里9,10,11均不能被4整除,到12时可以,则圆整结束。
 
shangshang 兄,你的研究结果和我的差不多。 我归纳一下:

1、相连的成员size和小于8,就会放在同一个8字节区域里,这是按8字节对齐的基础
2、在8字节段内部,数据域必须放在数据长度的整除位置上。以前面TTest的例子:
[a][x][11][11][x][x][x][x]
第二个域$1111是word,长度为2字节,它必须放置在0,2,4,6的位置上,因此在第一个域a的后面填充了一个[x],以凑齐2字节,使$1111放置在2的位置上。

而且后面TTest2的例子也可以证明这个规律,注意最后的8个字节段:
61 F6 12 00 33 33 33 33
最后的$33333333是4字节,它必须放置在0,4的位置上,因此61后面填充了3个字符,以保证它能放置在第4个位置上。

=======================================
规律应该是没问题的,不过是否有delphi的这方面的权威的资料呢?或者至少有权威的资料说delphi和C在这方面一样处理即可。
 
[a][x][11][11][x][x][x][x]
第二个域$1111是word,长度为2字节,它必须放置在0,2,4,6的位置上,因此在第一个域a的后面填充了一个[x],以凑齐2字节,使$1111放置在2的位置上。
这个规律我们的看法不一样,
我的意思是在这个8字节区域内的放置规则,仍然是按照对齐规则来放置.只不过按4,2的对齐大小来顺序处理安放.
比如上面的8个字节, 因为成员a+b的size还小于等于4,所以,再按4对齐,这俩成员被集中放置在前4字节上,后面4字节随机.
然后继续按2对齐前4字节中的两个成员a和b ,这样,a后填充一个,b单独占后俩字节. 这样,各成员对编译器来说,都有了独立的访问区域,这些大小区域都是优化过了的.呵呵. 个人意见,仅供参考.有不同意见,尽管指出
 
我觉得我们的说法虽然不一样,但是并不矛盾。 除非你能拿出反例来驳倒我的推论。
我目前找不到可以推翻你的推论的例子。
 
shangshang的说法应该是对的,不过一个过客的说法其实也不矛盾,可以这样理解。
所谓对齐应该就是这个样子:以8字节对齐时char放在哪个位置都行,short就应该放在0,2,4,6上,long就在0,4上,int64只能在0的位置上。
 
多人接受答案了。
 
后退
顶部