在使用 Delphi 7 进行开发时，准备好迎接 Delphi 2009 及更高版本了吗？答案

【问题标题】：Get ready for Delphi 2009 and up when developing with Delphi 7?在使用 Delphi 7 进行开发时，准备好迎接 Delphi 2009 及更高版本了吗？
【发布时间】：2010-01-12 11:43:16
【问题描述】：

我正在 Delphi 7 中开发一个 Word 插件，但很快我会将它升级到 Delphi 2010，如您所知，因为 2009 版 Delphi 引入了新的字符串类型 UnicodeString，它等于关键字 字符串 。另一方面，根据this thread，我们需要使用WideString 与COM 通信。

我的问题是，在当前使用 Delphi 7 进行开发的同时，我应该怎么做才能为将来的 Delphi 2010 做好准备？目前在我的代码中我使用用户定义的类型 UnicodeString，想法是当用 D7 编译时我的字符串是 WideString，当用 D2009 编译时它是 UnicodeString，我看到 Virtual TreeView 使用这种技术，如下代码：

{$ifndef COMPILER_12_UP}
type
  UnicodeString = WideString;
  PByte = PAnsiChar;
{$endif COMPILER_12_UP}

【问题讨论】：

我忘了提一个要求：目前在使用 D7 时，我需要使用 WideString 来支持 Unicode...

标签： delphi unicode

【解决方案1】：

第 1 步
通常你应该尽可能地坚持使用“普通”类型：即 String 和 Char
这样，您的代码将在升级时“自动”转换。
注意：有一些特定于应用程序的例外情况。

如果您不这样做，您可能会遇到我在升级某些地方使用 AnsiString 的代码库时遇到的问题。当 AnsiString = String 时，这在旧 Delphi 中不是问题。但显然，当类型不再相同时，这是有问题的。

第 2 步
阅读为迁移到 Unicode Delphi 2009 提供的指南。它提到了在处理字符串时通常被滥用的函数，因为假设每个字符都是 1 个字节。记下这些，并根据这些建议进行编码。

步骤 3、4 和 5
避免使用条件编译。你只会让自己更头疼。

步骤 6、7、8、、9 和 10
不要试图通过重新定义其内部类型来猜测编译器。你让自己头疼不已。问题是 VCL、运行时库和 3rd 方组件都对 String 是什么有一个“理解”。当您升级到 Delphi 2009 时，仍将共享“新理解”。

如果您更改该定义，那么由于隐式兼容性，旧版本可能仍然可以工作；但是，当在 Delphi 2009 中情况突然发生变化时，它可能会严重崩溃。

记住！使用的字符串类型是 Windows API 调用的一个重要考虑因素。 Windows 通常支持大多数功能的 Ansi 和 Wide 版本。在旧的 Delphi 中，默认使用 Ansi 版本；从 Delphi 2009 开始，默认使用 Wide 版本。

备注
关于您在 COM 开发中对 WideString 的担忧：
旧版本的 Delphi 提供 String 和 WideString 之间的自动类型转换 - 让您的编译器尽可能为您工作。显然，您的 COM 接口必须使用 WideString 声明，但请尽量避免超出此范围。

编辑
看看 Hughes 提供的链接：Get ready for Delphi 2009 and up when developing with Delphi 7?

还要强调：每个新版本的 Delphi 都试图保持一定程度的向后兼容性（包括 Delphi 2009）。 如果您只是“正常”编码，则不太可能受到很大程度的影响。事实上，反之亦然。你得到的花哨越多，你遇到问题的可能性就越大。

我在迁移到新版本的 Delphi 时遇到的唯一严重问题是：

没有源代码的第三方代码/库。
未维护的第 3 方代码，他们的开发人员在其中使用了各种编码“技巧”。
Delphi 3 中的Midas 代码是一次特别艰巨的升级。（但同样，绕过推荐技术的开发人员是一大罪魁祸首。）

【讨论】：

嗨 Craig，谢谢你的详细回答，我忘了提一个要求：现在使用 D7 时我需要使用 WideString 来支持国际语言。
嗨 Edwin，那么按照第 1 步，您确实有一个应用程序特定的理由不使用普通字符串。在这种情况下： - 您应该在必要时使用 WideString。 - 您可能已经避免了错误假设字符大小的常见陷阱。 - 你仍然不应该尝试“猜测”编译器。 PS：我假设您的应用程序将超越 'western' 语言进行国际化；否则 Ansi 已经支持许多西方语言字符。
嗨 Craig，我使用 WideString（以及其他 3rd 方库），因为这是使用 D7 进行国际化的唯一方法。

【解决方案2】：

很高兴知道Unicode Migration White Paper

【讨论】：

+1：我浏览了这篇文章，似乎很透彻……强烈推荐，我会读完全文。

【解决方案3】：

您可以遵循一个简单的规则，让您在 Delphi 7 中编写的代码非常容易地迁移到 Unicode 世界：

不要假设任何地方Char 的大小是 1。

换句话说，总是使用

SizeOf(Char) 而不是代码中的 1。

如果您在编写代码时牢记这一简单规则，那么您的路径应该会非常顺利。完全有可能编写在两种环境中都无需更改即可编译的代码。

【讨论】：

谢天谢地，自从我开始学习编程以来，我就有了这个好习惯；）

【解决方案4】：

（VST 的奇数 pbyte 声明可能更多的是一种解决方法，因为 {$pointermath on} 是 D2009 并且您不能在较低版本中过度索引 pbyte。它可能与 unicode 无关）

【讨论】：