步骤1
通常情况下,尽可能使用“正常”类型:即字符串和字符。
这样,当您升级时,您的代码将会被“自动”转换。
注意:有一些特定于应用程序的例外。
如果不这样做,升级代码库时可能会遇到我曾经遇到过的问题,在某些地方使用了AnsiString。在旧版本的Delphi中,AnsiString=String,所以这不是问题。但显然,当类型不再相同时,这是有问题的。
步骤2
阅读迁移到Unicode Delphi 2009的指南。它提到了在处理字符串时通常滥用的函数,因为它假定每个字符是1个字节。请注意这些内容,并根据这些建议进行编码。
步骤3、4和5
避免使用条件编译。这只会让你更头疼。
步骤6、7、8、9和10
不要试图重新定义编译器的内部类型,否则会遇到许多问题。事实上,VCL、运行时库和第三方组件都对有一个“理解”。在升级到Delphi 2009时,“新的理解”仍将被共享。
如果更改该定义,则在旧版本中可能仍然有效,由于隐式兼容性; 但是,在Delphi 2009中突然发生变化时,它很可能会彻底崩溃。
记住!使用的字符串类型是Windows API调用的重要考虑因素。Windows通常支持大多数函数的Ansi和Wide版本。在旧版本的Delphi中,默认使用Ansi版本;从Delphi 2009开始,默认使用Wide版本。
注意事项
关于您对COM开发中WideString的担忧:
旧版本的Delphi提供了String和WideString之间的自动类型转换-让编译器尽可能地为您工作。显然,您的COM接口必须声明为WideString,但请尽量避免其他任何东西。
编辑
请查看Hughes提供的链接:使用Delphi 7进行开发时准备好Delphi 2009及以上版本?
还要强调的是:每个新版本的Delphi都试图保持某种程度的向后兼容性(包括Delphi 2009)。如果您只是“正常”编码,您不太可能受到影响。事实上,相反通常是真的:越“花哨”的东西,遇到问题的可能性就越大。
我在升级到新版本的Delphi时遇到的唯一严重问题是:
- 没有源代码的第三方代码/库。
- 未维护的第三方代码,其开发人员采用了各种编码“技巧”。
- Delphi 3中的Midas代码是一次特别艰难的升级。(但是,开发人员绕过推荐的技术也是一个罪魁祸首。)