我应该如何为最终的 64 位编译器准备我的 32 位 Delphi 程序? [英] How should I prepare my 32-bit Delphi programs for an eventual 64-bit compiler?
问题描述
可能的重复:
如何准备迁移到 Delphi 2010 和 Unicode 时用于 64 位
既然我相信64bit Delphi编译器很快就会出现，我很好奇是否有人知道什么样的程序现在 32 位 无需任何更改即可编译和工作使用64位编译器时.
Since I believe that 64bit Delphi compiler will appear soon, I am curious if anybody knows what kind of programs that are now 32bit will compile and work without any changes when using 64bit compiler.
如果有一个一般规则，我们应该做什么样的改变系统地制作我们要编译的旧程序作为 64 位?
And if there is a general rule what kind of changes should we systematically make in our old programs to be compiled as 64bit?
当64位编译器突然出现时，做好准备是件好事......
It is good to be prepared when the 64bit compiler will suddenly be here...
任何建议将不胜感激.
推荐答案
首先声明:虽然我为 Embarcadero 工作.我不能代表我的雇主说话.我将要写的内容是基于我自己对假设的 64 位 Delphi 应该如何工作的看法，但可能存在也可能不存在竞争意见和其他可预见或不可预见的不兼容性和导致做出替代设计决策的事件.
First up, a disclaimer: although I work for Embarcadero. I can't speak for my employer. What I'm about to write is based on my own opinion of how a hypothetical 64-bit Delphi should work, but there may or may not be competing opinions and other foreseen or unforeseen incompatibilities and events that cause alternative design decisions to be made.
说:
有两种整数类型，NativeInt 和 NativeUInt，它们的大小将根据平台在 32 位和 64 位之间浮动.他们一直周围有很多版本.没有其他整数类型会改变大小取决于目标的位数.
There are two integer types, NativeInt and NativeUInt, whose size will float between 32-bit and 64-bit depending on platform. They've been around for quite a few releases. No other integer types will change size depending on bitness of the target.
确保任何依赖于将指针值转换为整数或反之亦然是使用 NativeInt 或 NativeUInt 作为整数类型.在更高版本的 Delphi 中，TComponent.Tag 应该是 NativeInt.
Make sure that any place that relies on casting a pointer value to an integer or vice versa is using NativeInt or NativeUInt for the integer type. TComponent.Tag should be NativeInt in later versions of Delphi.
我建议不要将 NativeInt 或 NativeUInt 用于非基于指针的值.尝试使您的代码在 32 位和 64 位之间在语义上保持相同.如果需要 32 位范围，请使用 Integer；如果需要 64 位，请使用 Int64.这样你的代码应该在两个位上运行相同.仅当您在某种类型的 Pointer 值(例如引用或 THandle)之间进行转换时，才应使用 NativeInt.
I'd suggest don't use NativeInt or NativeUInt for non-pointer-based values. Try to keep your code semantically the same between 32-bit and 64-bit. If you need 32 bits of range, use Integer; if you need 64 bits, use Int64. That way your code should run the same on both bitnesses. Only if you're casting to and from a Pointer value of some kind, such as a reference or a THandle, should you use NativeInt.
在可能的情况下使用 PByte 进行指针运算，优先于 NativeInt 或 NativeUInt.它可以满足大多数用途，并且更加类型安全，因为它不会(容易)被误认为是普通的整数类型，反之亦然.
Use PByte for pointer arithmetic where possible, in preference to NativeInt or NativeUInt. It will suffice for most purposes, and is more typesafe because it can't be (easily) mistaken for a normal integer type, and vice versa.
类似指针的东西应该遵循与指针类似的规则:对象引用(显然)，还有 HWND、THandle 等.
Pointer-like things should follow similar rules to pointers: object references (obviously), but also things like HWND, THandle, etc.
不要依赖字符串和动态数组的内部细节，比如他们的标题数据.
Don't rely on internal details of strings and dynamic arrays, like their header data.
我们关于 64 位 API 更改的一般政策应该是保持尽可能在 32 位和 64 位之间使用相同的 API，即使这意味着64 位 API 不一定会利用机器.为了例如，TList 可能只会处理 MaxInt div SizeOf(Pointer)元素，以保持计数，索引等为整数.因为整数类型不会浮动(即根据位数改变大小)，我们不想对客户代码产生连锁反应:任何索引通过整数类型变量或 for 循环索引进行往返，会被截断并可能导致细微的错误.
Our general policy on API changes for 64-bit should be to keep the same API between 32-bit and 64-bit where possible, even if it means that the 64-bit API does not necessarily take advantage of the machine. For example, TList will probably only handle MaxInt div SizeOf(Pointer) elements, in order to keep Count, indexes etc. as Integer. Because the Integer type won't float (i.e. change size depending on bitness), we don't want to have ripple effects on customer code: any indexes that round-tripped through an Integer-typed variable, or for-loop index, would be truncated and potentially cause subtle bugs.
在 API 扩展到 64 位的情况下，它们很可能会通过一个额外的函数/方法/属性来访问额外的数据，这API 也将支持 32 位.例如，Length() 标准例程可能会返回整数类型的值作为参数类型字符串或动态数组；如果要处理非常大的动态数组，也可能有一个 LongLength() 例程，其32 位的实现与 Length() 相同.Length() 会抛出如果应用于超过 2^32 的动态数组，则 64 位异常元素.
Where APIs are extended for 64-bit, they will most likely be done with an extra function / method / property to access the extra data, and this API will also be supported in 32-bit. For example, the Length() standard routine will probably return values of type Integer for arguments of type string or dynamic array; if one wants to deal with very large dynamic arrays, there may be a LongLength() routine as well, whose implementation in 32-bit is the same as Length(). Length() would throw an exception in 64-bit if applied to a dynamic array with more than 2^32 elements.
与此相关，可能会改进错误检查语言中的缩小操作，尤其是缩小 64 位值到 32 位位置.这会影响分配的可用性如果 Length()，则将 Length 的值返回到 Integer 类型的位置，返回 Int64.另一方面，专门针对编译器魔术像 Length() 这样的函数，可能会有一些魔法的优势，例如根据上下文切换返回类型.但优势不能在非魔法 API 中采用类似方法.
Related to this, there will probably be improved error checking for narrowing operations in the language, especially narrowing 64-bit values to 32-bit locations. This would hit the usability of assigning the return value of Length to locations of type Integer if Length(), returned Int64. On the other hand, specifically for compiler-magic functions like Length(), there may be some advantage of the magic taken, to e.g. switch the return type based on context. But advantage can't be similarly taken in non-magic APIs.
动态数组可能会支持 64 位索引.请注意，Java数组仅限于 32 位索引，即使在 64 位平台上也是如此.
Dynamic arrays will probably support 64-bit indexing. Note that Java arrays are limited to 32-bit indexing, even on 64-bit platforms.
字符串可能仅限于 32 位索引.我们有一个艰难的是时候为人们想要 4GB+ 的字符串提出现实的理由了这确实是字符串，而不仅仅是托管的数据块，为此动态数组也可以起到同样的作用.
Strings probably will be limited to 32-bit indexing. We have a hard time coming up with realistic reasons for people wanting 4GB+ strings that really are strings, and not just managed blobs of data, for which dynamic arrays may serve just as well.
也许是内置汇编器，但有限制，比如不能与 Delphi 代码自由混合；在 x64 上还需要遵循有关异常和堆栈帧布局的规则.
Perhaps a built-in assembler, but with restrictions, like not being able to freely mix with Delphi code; there are also rules around exceptions and stack frame layout that need to be followed on x64.
这篇关于我应该如何为最终的 64 位编译器准备我的 32 位 Delphi 程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
