delphi - 我应该如何为最终的 64 位编译器准备我的 32 位 Delphi 程序？

Question

这个问题在这里已经有了答案:





How to also prepare for 64-bits when migrating to Delphi 2010 and Unicode

(4 个回答)


6年前关闭。

Possible Duplicate:
How to also prepare for 64-bits when migrating to Delphi 2010 and Unicode

因为我相信 64 位 Delphi编译器即将出现，
我很好奇是否有人知道什么样的程序
现在是 32 位 无需任何更改即可编译和工作
使用时 64 位 编译器。

如果有一个一般规则，我们应该做出什么样的改变
系统地制作我们要编译的旧程序
如 64 位 ?

最好在的时候做好准备64 位 编译器会突然出现...

任何建议将不胜感激。

Answer 1

首先，免责声明:虽然我为 Embarcadero 工作。我不能代表我的雇主说话。我将要写的内容是基于我自己对假设的 64 位 Delphi 应该如何工作的看法，但可能存在也可能不存在相互竞争的观点以及其他可预见或不可预见的不兼容性和导致做出替代设计决策的事件。

那说:

有两种整数类型，NativeInt 和 NativeUInt，它们的大小将
根据平台在 32 位和 64 位之间 float 。他们一直
周围有很多版本。没有其他整数类型会改变大小
取决于目标的位数。

确保任何依赖于将指针值转换为
整数或反之亦然是使用 NativeInt 或 NativeUInt 作为整数
类型。在更高版本的 Delphi 中，TComponent.Tag 应该是 NativeInt。

我建议 不要将 NativeInt 或 NativeUInt 用于非基于指针的值 .尝试使您的代码在 32 位和 64 位之间在语义上保持相同。如果需要 32 位范围，请使用 Integer；如果需要 64 位，请使用 Int64。这样你的代码应该在两个bitnesses上运行相同。仅当您在某种类型的 Pointer 值(例如引用或 THandle)之间进行转换时，才应使用 NativeInt。

使用 PByte尽可能用于指针运算，优先于 NativeInt或 NativeUInt .它可以满足大多数用途，并且更加类型安全，因为它不会(容易)被误认为是普通整数类型，反之亦然。

类似指针的东西应该遵循与指针类似的规则:对象
引用(显然)，还有 HWND、THandle 等。

不要依赖字符串和动态数组的内部细节，比如
他们的标题数据。

我们对 64 位 API 更改的一般政策应该是保持
尽可能在 32 位和 64 位之间使用相同的 API，即使这意味着
64 位 API 不一定会利用机器。为了
例如，TL​​ist 可能只处理 MaxInt div SizeOf(Pointer)
元素，以便将计数、索引等保持为整数。因为
整数类型不会 float (即根据位数改变大小)，我们
不想对客户代码产生链式 react :任何索引
通过整数类型变量或 for 循环索引进行往返，
会被截断并可能导致细微的错误。

在 API 扩展为 64 位的情况下，它们很可能会使用
一个额外的函数/方法/属性来访问额外的数据，这
API 也将支持 32 位。例如，Length() 标准
例程可能会返回整数类型的值作为参数
类型字符串或动态数组；如果要处理非常大的
动态数组，也可能有一个 LongLength() 例程，其
32 位的实现与 Length() 相同。 Length() 会抛出
如果应用于超过 2^32 的动态数组，则 64 位异常
元素。

与此相关，可能会改进错误检查
语言中的缩小操作，尤其是缩小 64 位值
到 32 位位置。这会影响分配的可用性
如果 Length()，则将 Length 的值返回到 Integer 类型的位置，
返回 Int64。另一方面，专门针对编译器魔术
像 Length() 这样的函数，可能会有一些魔法的优势，
例如根据上下文切换返回类型。但优势不可能
在非魔法 API 中也采用类似的方法。

动态数组可能会支持 64 位索引。请注意，Java
数组仅限于 32 位索引，即使在 64 位平台上也是如此。

字符串可能仅限于 32 位索引。我们有一个艰难的
是时候为人们想要 4GB+ 的字符串提出现实的理由了
这确实是字符串，而不仅仅是托管的数据块，为此
动态数组也可以发挥作用。

也许是内置汇编器，但有限制，比如不能与 Delphi 代码自由混合；在 x64 上还需要遵循有关异常和堆栈帧布局的规则。