Delphi 7 与 2009 年（和 2010 年）相比创纪录大小

Question

将代码从 Delphi 7 转换为 2010 时，我遇到了一个奇怪的问题。它与记录有关。下面定义的记录在 D7 中调整大小时为 432 字节，在 D2009（和 2010）中为 496 字节。我知道，一个简单的解决方案是使其成为打包记录，然后所有版本都为 426 字节...但是，我们在流式传输记录的位置存储了数据，现在我们正在尝试使用更新的语言读取这些流。

TToTry = Record
 a,b,c,d : Extended;
 e,f,g,h : Extended;
 i : String[15];
 j,k,l,m,n,o,p,q,r,s,t : Array[1..3] of Extended; End;

在调查这个问题时，我创建了另一条记录，并且出于某种原因，大小是相同的？记录较小，但具有相同的数据类型。但在该语言的所有版本中它的大小都是相同的。

TMyRecord = Record
Ext1  : Extended;
Ext2  : Extended;
Ext3  : Extended;
Ext4  : Extended;
Ext5  : Extended;
Ext6  : Extended;
Int1  : Integer;
Int2  : Integer;
char1 : AnsiChar;
char2 : AnsiChar;
MyString  : String[15];
Arr1  : Array[1..3] of Extended;
Arr2  : Array[1..3] of Extended; end;

有人知道为什么一张记录如此不同，而另一张记录却相同吗？肯定与 Delphi 中的字节边界对齐有关。但从一个版本到下一个版本，是什么发生了如此巨大的变化呢？

Answer 1

嗯，第一个问题是您将非打包记录存储到磁盘上。字段和数组封装允许在产品版本之间进行更改，因为通常内存中的布局在进程之外不可见。你已经违反了这条规则。

如果在 Delphi 7 和 Delphi 2009 之间字节填充默认值发生了变化，请找出 D7 中的默认值并将默认值设置为 Delphi 2009 中的相同值。

还要检查数组填充默认值。我不记得是否有单独的设置。

在 Delphi 2009 的调试内存视图中查看记录结构。部分或全部额外大小可能是由于记录本身（而不是其中的字段）的填充造成的，因此当在数组中使用记录时，数组元素位于快速机器边界上。

如果这些都没有帮助，请在 D2009 中创建临时打包记录类型，并在实际数据字段之间手动插入字节填充字段，直到记录大小和字段对齐与 D7 布局匹配。这不仅仅是大小，还有字段对齐。使用此临时打包记录读取旧数据文件。然后将数据逐字段传输到 D2009 中的“真实”记录类型中，并写出一个新文件。

当您执行此操作时，将该记录类型打包到 D2009 中，这样就不会再发生这种情况。

Answer 2

我相信您已经找到了一个功能！我无法使用 D2007 的 TToTry 获得合理的大小，因此我必须使用调试器查找字段地址；

首先，以下记录的大小

{$A8}
type
  TToTry = record
    j: array[1..3] of Extended;
    k: array[1..3] of Extended;
    l: array[1..3] of Extended;
    m: array[1..3] of Extended;
  end;

为128 (32*4)。这是预期的，因为扩展是 10 字节，30 字节将对齐 32 字节。

但该记录的大小

{$A8}
type
  TToTry = record
    j, k, l, m: array[1..3] of Extended;
  end;

是120 (30*4)。这当然是出乎意料的——字段仍应在 8 字节边界上对齐。

（我没有D7来验证，但我的想法是：）

现在我们知道分组字段是打包的，因此 D7 上的对齐是 8 个字节，并且您的记录几乎是打包的；

TToTry = Record 
 a,b,c,d : Extended;    // 40 bytes (8*5)
 e,f,g,h : Extended;    // 40 bytes (8*5)
 i : String[15];        // 16 bytes (8*2)
 j,k,l,m,n,o,p,q,r,s,t: Array[1..3] of Extended; // 330 bytes
End; 

编译器将 6 个字节填充到最后一组，使其成为 8 的倍数，然后得到 40+40+16+336 = 432 字节。

使用 D2009/D2010，您要么声明每个字段 - 而不对它们进行分组，要么行为发生改变。无论哪种方式打包您的记录并在末尾添加一个 6 字节数组虚拟字段，您就可以开始了。

如果这不起作用，请使用 D7 查看记录的字段地址，然后使用打包记录并根据需要使用虚拟字段在 D2009 上创建精确的副本，导入存储的数据后，您可以删除虚拟字段。

--

我从来不知道这种行为，也找不到任何地方的记录。尽管如此，它仍然非常像一个功能，以至于我不太愿意将其称为错误。我不知道该行为与 D2009 或 D2010 是否相同，请测试一下是否相同。如果是，为了获得预期结果（不要有半打包记录），不要偷懒，为非打包记录单独声明每个字段。

Answer 3

我知道这是一篇旧文章，但昨天我在 Delphi XE2 中遇到了同样的问题。我有几个使用 Turbo Delphi 2006 应用程序编写的键入文件，并且我还犯了不使用打包记录的错误。我的情况很复杂，因为我使用的是可变长度记录（这就是我们在 z/OS 世界中对它们的称呼，不是 100% 确定的 Delphi 术语），因此未对齐导致记录键标签最终没有出现在正确的字段，从而导致没有子记录位于正确的位置，从而导致整个文件无用。

我发现您可以将对齐编译器指令放在特定的代码块周围。除此之外，我还发现了这个小宝石： {$OLDTYPELAYOUT ON}

{$OLDTYPELAYOUT ON}
 RMasterRecord = Record       
    mKey       : word;
    mDeleted   : boolean;
    case mType : ANSIChar of
       'V' : //Info
          (Vers : RVersionLayout);
       […]
{$OLDTYPELAYOUT OFF}

我只将指令放在写入和读取文件的主记录周围，而不是放在子记录定义周围。这解决了我的问题，我现在可以在 XE2 中编译并读取我的 TD2006 文件。下次我将使用打包记录（或者更好的是 SQLite）。但我想我会分享这个，因为这个网站多年来为我提供了不可估量的帮助。

您可以在此处阅读有关 $OLDTYPELAYOUT 的更多信息：http://docwiki.embarcadero.com/ RADStudio/XE5/en/Internal_Data_Formats#Record_Types。顺便说一句，第一个修复它的是 {$A4} 但当我发现 {$OLDTYPELAYOUT ON} 时，我将其切换为使用它，因为它更明显。

Answer 4

我相信默认对齐方式变宽了。在以后的版本中指定对齐方式 4，看看它是否按照您想要的方式显示。

将来，您应该确保任何要写入磁盘的记录都以打包方式存储，这样您就不会被这种方式烧毁。

编辑：由于没有任何对齐方式起作用（这让我感到惊讶），我会回到原始版本并弄清楚它是如何真正对齐的。用类似 $FF 的内容填充记录，将数据放入并写出 - 查看 $FF 幸存的位置。获取新记录，对其进行打包并添加填充符以匹配旧记录中的填充。

一件事：这实际上只是一张记录吗？过去，我使用对象作为带有继承的假记录——哎呀，在继承时应用了正常对齐，我无法阻止它。我最终不得不在数据之前进行填充，以使强制对齐不会破坏我的数据。 （这是一个 API，它必须是对的，我无法独立处理这些字段。）

Answer 5

应用 {$A8} 指令并不意味着所有记录字段都在 8 字节边界对齐 - 编译器使用不同的对齐策略。例如，

{$A8}
type
  TToTry = record
    a: byte;
    b: word;
    c: longword;
  end;

Delphi 2009中的大小为8字节，因为编译器将2字节值在2字节边界对齐，4字节值在4字节边界对齐，而上例中唯一实际对齐的是b字段对齐在 2 字节边界。

至于最初的问题 Delphi 7 和 Delphi 2009 之间发生了什么变化 - 请阅读 Sertac Akyuz 的回答和我的评论