千万千万不要小看delphi中的packed

当下，很多人，甚至熟练的程序员对delphi中的packed不以为然，普遍认为它的出现更多的是为了节约内存空间，在内存足够大的今天，packed无用武之地。我也一直苟同这个观点。

如果你现在还在认为packed是为了压缩而存在，也许有一天也会焦头烂额。

今天被一个record的问题搞得头大，请看这段代码：

  AB = record
  a : array [0..5] of byte;
  b:longword;

用sizeof得到的AB的大小是12字节，比预料的10增加了2个字节。因为32位操作系统的常规内存分配，是按照4个字节（8位=1字节）来分配，这有利于配合CPU的运算。所以，这个sizeof的结果，永远是被4整除的。

我以为是这样，但事实上还并不这么简单，在多次试验后发现一个规律，发现delphi有一种算法来分配内存。看似优化，其实也有不足，也许是为了兼容性吧。

  AB = record
  a : longword;
  b:byte;
 c:byte;
d:byte;

和

  ABC = record
  a : byte;
  b:byte;
 c:longword;
d:byte;

ABC和AB拥有同样的字段类型，只是顺序不一样，结果，他们的所占的内存空间也不一样了。

熟练的程序员从上面两个字段可以猜得到，这是32位内存分配导致的，但是，在实际编程中，恐怕我们的字段不会这么少，代码不会这么简单，也许你更会怀疑是否哪里的赋值或者逻辑出问题了。

 

而delphi对packed的说明中，写有：
When you declare a structured type, you can include the reserved word packed to implement compressed data storage.
delphi对packed的压缩数据功能给予肯定。

Using packed slows data access and, in the case of a character array, affects type compatibility (for more information, see Memory management ).
DELPHI指明packed的数据存在兼容性问题。并且会影响程序的执行速度（恐怕影响速度才是因为多数人不爱用它的原因吧）

when the declaration does not include a packed modifier, the type is an unpacked record type, and the fields of the record are aligned for efficient access by the CPU.
delphi写明没有packed的数据会根据cpu的规则来分配内存。

我们看到，并不是任何数据都packed就是好，比如需要兼容某个函数中的参数时，恐怕packed之后的数据就不会映射到预设的内存位置了。