如何选择从Delphi 2007迁移的路径

Question

我正在与一个团队一起开发一个使用Delphi 2007的大型应用程序。它使用一个更大的遗留框架来访问数据。应用程序和框架都使用String作为字符串的数据类型。我已经开始修改框架中的代码以支持Delphi 2009字符串，有关此问题请参见我的先前的问题。

现在我看到了两个选择：

选项1 - 继续像以前一样使用String。这可能是最干净的解决方案，因为框架将支持Unicode。但是，框架中的代码必须进行大量修改才能使其正常工作。这需要深入了解框架内部算法。这也会有更大的机会引入新的错误。

选项2 - 将String替换为AnsiString，将Char替换为AnsiChar。这可能是一个更容易的解决方案，也是我开始修改代码的方式（但后来我开始思考并提出了这个问题...）。这种方法的负面影响是不支持Unicode。虽然Unicode支持不是必需的，因为之前它可以工作，但是它很好用。它在未来也可能很有用。另一个问题是应用程序必须像以前一样在方法的参数中发送Ansistring变量，而不是String。有数千个调用需要更改...

所以我现在不知道该怎么办了。两个选项都需要大量的工作，但是选项1可能更具风险，耗时更长。我想从这个论坛中得到反馈和评论，因为我猜我不是第一个遇到这个问题的人。

编辑 另一个问题是内存占用。我编写了一个快速测试，分配了一个包含一百万个字符串的数组。每个字符串都填充了从A到Z的26个字符。

使用Delphi 2007，它占用了40,011,600字节，时间为4:15分钟。 使用Delphi 2009，它占用了72,015,580字节，时间为4:45分钟。

内存消耗是通过GetHeapStatus.TotalAllocated来测量的。

我认为我们不能承受字符串分配两倍的内存。

现在每个客户端的内存消耗通常达到500 MB，其中很多是字符串。我们尽可能使用AnsiString。

谢谢！

- Roland Bengtsson

---

大家的评论都很有趣，谢谢！显然不太清楚该选择什么。我更倾向于Alt 2，但Andreas的评论让我担心。如果Pos返回错误的索引，可能会引入新的错误。 - Roland Bengtsson

请查看我回答中的编辑部分：“在CodeRage 4的Unicode会话链接和对Andreas所描述情况的解释”。 - Jeroen Wiert Pluimers

Answer 1

要么继续使用旧版Delphi，要么彻底升级。无论如何，您迟早都必须这样做。

请注意，“用ansistring替换所有内容”的方案也不是完全可靠的，特别是如果涉及流和文件格式需要保持不变的情况。现在已经没有明确的TStringlists、tstringstreams等ansistring了。

同样的问题可能也存在于Datasnap、Indy和其他框架中。

您可以先尝试在某些字符串密集部分使用此技巧，以避免直接更改太多代码。例如，我有一个自己的XML库，我对其进行了补丁，使其大部分仍然是ansistring。该库只是侧面使用，对于它来说Unicode并不重要。

- Marco van de Voort

---

是的，我注意到 AnsiString 替换跟踪不完美。 - Roland Bengtsson

Answer 2

从“alt 2”开始，逐步向您的框架添加Unicode支持，然后转向Unicode。

原因：您想要一个稳定的应用程序；切换到Delphi 2009+最终将要求您真正支持Unicode。

编辑：20100125

在进行“alt 2”时，请注意Delphi编译器中的提示和警告。
Andreas描述的情况将生成此类提示和警告。

我在CodeRage 4有关Unicode和其他编码的会议中解释了这一点。
上面的链接指向一个页面，您可以在其中查看该会议的重播。

如果您仍有疑问，请在此处留言。

--jeroen

- Jeroen Wiert Pluimers

---

Alt 2可能比Alt 1给他带来更多麻烦，因为RTL和VCL是Unicode的。例如，如果他使用"Pos"函数，编译器会优先选择Unicode版本，除非两个参数都是AnsiStrings类型。如果第一个是字符串常量或字符常量，编译器将使用Unicode版本。而且，有一些多字节字符串在Unicode中由不同数量的字符表示，这导致Pos返回错误的索引。 - Andreas Hausladen

有趣，你有任何参考或真实案例可以证明这种情况吗？ - Roland Bengtsson

我认为他的意思是，在确定调用哪个版本时，从字面值到Unicode的转换优先于从字面值到Ansistrings的转换。我认为这是正确的，尽管不应该高估它。我预计(ansistring,char)会选择ansistring版本。 - Marco van de Voort

Answer 3

我们在一年前评估了2007年到2009年的转换，并尝试了一个较小的项目（200k行）。结果是，只要您不使用“花哨”的东西，例如指针、char集合等，移植就真的不那么困难。特别是GUI单元在一天左右内就可以移植完成。这相当于opt1。

低级例程、访问测量系统等库单元则完全不同。在这里，我们选择将字符串转换为ansistring，字符转换为ansichar等等。移植这些单元是很痛苦的，而客户不会为此付费。因此，对于这些单元，我们选择了opt2。

这种混合方法给我们带来了最好的两个世界，但我们将保留一些大型项目在Delphi 2007中，并且可能只有在64位版本的编译器推出时才进行移植。

- Ritsaert Hornstra

---

可能这将是我们进行对话的方式，但整个团队都需要讨论和规划。 - Roland Bengtsson

Answer 4

虽然需要更多的工作，但我强烈建议您升级到Unicode字符串，因为这是VCL的本地字符串类型，所以所有控件都将处理Unicode字符串。试图来回转换将会给您带来各种麻烦。

- Mason Wheeler

---

正如我所说，这是最清晰的解决方案。我担心的是我们需要更改框架中我们未完全理解的代码。这需要进行大量测试以确保质量。 - Roland Bengtsson