Is an update to D2010 really meaningful

Question

I am trying to migrate my own projects to delphi 2010. But it seems to be very difficult.

1. 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.
2. 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.
3. A confusing warning, when trying to cast an AnsiString to UnicodeString. This conversation won't cause a data lose, will it?
4. 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?

Answer 1

1. conversion Unicode string to specified code page with only Delphi: Simpler than ever. Thanks to the String class ability to create a string of a desired codepage, and convert cleanly from one codepage to another.
2. FillChar is bytes, not characters, name is now unfortunate. Not that confusing really.
3. That warning is there to make you think, which it did. Job done.
4. Oh yes. But that retesting and re-reading has been the biggest benefit for me.

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.

Answer 2

1. 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.

2. 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.

3. 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.

4. 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.