迁移到 Delphi 2010 和 Unicode 时如何准备 64 位 [英] How to also prepare for 64-bits when migrating to Delphi 2010 and Unicode
问题描述
由于下一个版本预计不会支持 64 位，因此不再需要等待将现有代码库一次性迁移到 unicode 和 64 位的可能性.但是，如果我们在进行 unicode 转换时已经可以为 64 位准备代码，那就太好了.如果它最终出现在 2020 版中，这将最大限度地减少影响.如果它要到 2020 年才到货，有什么建议可以在不引入太多混乱的情况下解决这个问题吗?
As 64 bits support is not expected in the next version it is no longer an option to wait for the possibility to migrate our existing code base to unicode and 64-bit in one go. However it would be nice if we could already prepare our code for 64-bit when doing our unicode translation. This will minimize impact in the event it will finally appear in version 2020. Any suggestions how to approach this without introducing to much clutter if it doesn't arrive until 2020?
推荐答案
这里有另一个类似的问题，但我也会在这里重复我的回复，以确保有尽可能多的人看到此信息:
There's another similar question, but I'll repeat my reply here too, to make sure as many people see this info:
首先，免责声明:虽然我为 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 作为整数类型.TComponent.Tag 在 Delphi 的更高版本中应该是 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.这样，您的代码应该在两个位上运行相同.仅当您在某种类型的指针值(例如引用或 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.
类似指针的东西应该遵循与指针类似的规则:object参考资料(显然)，还有 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() 会抛出如果应用于超过 232 的动态数组，则会出现 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 232 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.
这篇关于迁移到 Delphi 2010 和 Unicode 时如何准备 64 位的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
