D2010的更新真的有意义吗
我正在尝试将自己的项目迁移到delphi 2010。但这似乎非常困难。
- 我在旧项目中使用 TntControls。如果我删除这个库，一些运行时函数必须由我自己重新实现。例如：将UnicodeString转换为指定的代码页。
- “SizeOf”、“Length”、FillChar() 仍然让我困惑。如果 SizeOf() 应该替换为 Length()，编译器将抛出警告。但我还没有找到任何对我来说白痴安全的教程。
- 尝试将 AnsiString 转换为 UnicodeString 时出现令人困惑的警告。这次对话不会导致数据丢失，不是吗？
- 许多代码（zip、字符串实用程序等）必须重新测试。
太多头痛了...有人可以分享将现有项目从非常旧的 delphi 迁移到 delphi 2010 的经验吗？
I am trying to migrate my own projects to delphi 2010. But it seems to be very difficult.
- I use TntControls for old projects. If I remove this library, some runtime functions must be re-implemented by myself. For instance: convert UnicodeString to a specified code page.
- The "SizeOf", "Length", FillChar() still confuse me. Compiler will throw a warning, if SizeOf() should be replaced with Length(). But I have not found any idiot-safe tutorials for me.
- A confusing warning, when trying to cast an AnsiString to UnicodeString. This conversation won't cause a data lose, will it?
- Many code (zip, string utils, etc.) must be retested.
Too many headaches... Can someone share experience on migrating existing project from a very old delphi to delphi 2010?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我已将我的所有项目迁移到 Delphi 2009/2010，并发现好处包括：
A. 彻底重新阅读我的代码带来了我需要清理它的许多方法（因为它是一堆臃肿的旧事故和增量代码污泥） ，就像大多数 RAD/delphi 项目最终的结果一样），其中很少有纯粹的 unicode 或端口相关的，但所有这些都使产品更好地被迫进行更改。
B. 一个更清洁的世界，更少的第三方组件。放弃 TNT 和十两个第三方组件将使您的项目更小、更正交且更易于支持。
C. 没有理由将其移植为一种方式。我的项目端口实际上都没有永久“移动”到 Delphi 2009/2010 中。它们在两个世界中都构建得很好。我在所有代码中广泛使用 UnicodeString 类型，只要我需要它，并且在 Delphi 2007 或更早版本上编译时，我将 typedef 设置为 WideString。
D. delphi 2010 ide 在 Windows Vista 和 Windows 7 上运行良好，并且使用该语言是一种乐趣。 Delphi 2009 和 2010 不会崩溃，而 Delphi 2007 和 Delphi 7 经常会崩溃。
如果您不需要支持 Vista 和 Win7，并且您 100% 满意且无故障地运行 TNT 组件，并且您的应用程序无法为您赚钱，那么请将其保留在原处。如果它能让你赚钱，那就投入你的时间，你很快就会看到回报。 Delphi 2010 和 2009 无疑是有史以来最好的 Delphi 版本，唯一令人头疼的是，自从他们放弃 WinHelp 格式的帮助文件后，文档的质量一直低于 Delphi 7 的质量。
I have migrated all my projects to Delphi 2009/2010 and found the benefits included:
A. a thorough re-reading of my code brought many ways I needed to clean it up (because it's a bloated old mass of accidents and incremental code-sludge, like most RAD/delphi projects end up), few of which are purely unicode or port related, but all of which made the products better for being forced through the changes.
B. a cleaner world, with fewer third-party components. Dropping TNT, and a dozen or two third party components will make your project smaller, more orthogonal and easier to support.
C. There's no reason in porting to make it one way. None of my project ports are actually "moved" permanently into Delphi 2009/2010. They all build in both worlds just fine. I use the type UnicodeString widely in all my code wherever I need it, and I make a typedef to WideString, when compiling on Delphi 2007 or older versions.
D. The delphi 2010 ide works great on Windows Vista and Windows 7, and the language is a joy to work with. Delphi 2009 and 2010 don't crash, which Delphi 2007 and Delphi 7 often do for me.
If you don't need to support Vista and Win7, and you're 100% happy and glitch-free running TNT components, and your app doesn't make you money, then leave it where it is. If it makes you money, invest your time, and you will soon see the rewards. Delphi 2010 and 2009 are easily the best delphi versions ever, and the only major headache that remains is that the documentation has remained below the quality of Delphi 7 ever since they moved off WinHelp format help files.
如果您正在使用 Tnt 并且已经在代码页之间进行转换，那么是的，切换到 Delphi 2010 将会给您带来额外的工作，因为您需要删除 Delphi 无法处理的内容的代码现在本质上处理。最终，您的代码将变得更简单，但同时将其实现起来会很麻烦。
SizeOf、Length 和 FillChar 是非常基本的概念，作为专业软件开发人员，您应该理解这些概念。请清楚您正在处理字符数据还是非字符数据，并且在处理后者时，不要使用与字符相关的类型。您已拥有 TBytes；使用它。不要使用字符串作为字节缓冲区。当你想知道有多少字节时，使用 SizeOf;当你想知道你有多少“东西”时，使用长度。一般避免FillChar；无论如何，你可能不像今天那样需要它。由于填充的“字符”几乎总是为零，因此您可以考虑使用 ZeroMemory。它的参数更少，并且与 FillChar 一样快，特别是因为 Delphi 支持函数内联。
从 AnsiString 转换为 UnicodeString 时，编译器会发出警告，因为它不是简单的字符串赋值，而是一种转换，保证分配更多内存并一次复制一个字符的所有内容。这是性能警告，而不是数据丢失警告。相反方向的转换是两者（即使分配给 Utf8String 时也是如此，从技术上讲，如果仅用有效的 Unicode 字符填充，它永远不会丢失 UnicodeString 中的数据）。避免警告的最佳方法是首先不要使用 AnsiString。使用普通的旧字符串，除非代码确实需要知道将内容编码为什么代码页。
我认为“重新测试”的论点不是很强。库代码尤其应该具有每次重新编译时运行的单元测试。重新测试是您每天要做几次的事情；除非出现问题，否则不需要付出特别的努力。
If you're using Tnt and you're converting between code pages already, then yes, switching to Delphi 2010 will cause you extra work because you'll need to remove code for things that Delphi now handles intrinsically. Ultimately, your code will be simpler, but it will be a hassle to get it there in the meantime.
SizeOf, Length, and FillChar are very basic concepts that you, as a professional software developer, owe to yourself to understand. Be cognizant of whether you're dealing with character data or non-character data, and when dealing with the latter, don't use character-related types. You've got TBytes; use it. Don't use strings as byte buffers. When you want to know how many bytes you have, use SizeOf; when you want to know how many "things" you have, use Length. Generally avoid FillChar; you probably don't need it as much as you use it today anyway. Since the "char" that things are filled with is almost always zero anyway, you might consider using ZeroMemory instead. It has fewer parameters and is just as fast as FillChar, especially since Delphi supports function inlining.
The compiler warns you when converting from AnsiString to UnicodeString because it's not a simple string assignment but rather a conversion, guaranteed to allocate more memory and copy everything one character at a time. It's a performance warning, not a data-loss warning. Conversions in the opposite direction are both (even when assigning to Utf8String, which technically will never lose data from a UnicodeString, if it's filled only with valid Unicode characters). The best way to avoid the warning is to not use AnsiString in the first place. Use plain old String except for code that really does need to know what code page to encode things as.
I don't think the "retest" argument is very strong. The library code especially should have unit tests that you've been running every time you recompiled. Retesting is something you do several times a day; there's no special effort involved unless something goes wrong.