Get ready for Delphi 2009 and up when developing with Delphi 7?

Question

Hi

I'm developing a Word addin in Delphi 7, but soon I'll upgrade it to Delphi 2010, as you know, since version 2009 Delphi introduces the new string type UnicodeString which equals to the keyword string . On the other hand, according to this thread we need to use WideString to communicate with COM.

My question is, what should I do in order to get ready for Delphi 2010 in the future while currently developing in Delphi 7? Currently in my code I use a user-defined type UnicodeString, the idea is that when compile with D7 my string is WideString, when compile with D2009 and up it's UnicodeString, I see Virtual TreeView uses such technique ,like the following code:

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

Answer 1

Step 1
Usually you should stick to using the 'normal' types as far as possible: i.e. String and Char
This way your code will be 'automatically' converted when you upgrade.
NOTE : There are a few application-specific exceptions.

If you don't do this, you're likely to experience a problem I had when upgrading a library of code that had in some places used AnsiString. This wasn't a problem in old Delphi when AnsiString = String. But obviously this was problematic when the types were no longer the same.

Step 2
Read the guidelines provided for migrating to Unicode Delphi 2009. It mentions the functions that are typically abused when working with strings because it is assumed that each character is 1 byte. Take note of these, and code according to those recommendations.

Steps 3, 4 and 5
Avoid the use of conditional compilation. You'll only give yourself more headaches.

Steps 6, 7, 8, , 9 and 10
Don't try to second guess the compiler by redefining its internal types. You're exposing yourself to many headaches. The thing is that the VCL, run-time libraries and 3rd party components all have an 'understanding' of what String is. The 'new understanding' will still be shared when you upgrade to Delphi 2009.

If you change that definition, then things may still work in the old version due to implicit compatibility; however it is likely to break horribly when in Delphi 2009 things suddenly change.

Remember! The kind of string used is an important consideration with Windows API calls. Windows typically supports both Ansi and Wide versions of most functions. In older Delphi, Ansi versions are used by default; and from Delphi 2009, Wide versions are used by default.

Notes
Regarding your concerns about WideString in COM development:
Older versions of Delphi provide automatic typecasting between String and WideString - let your compiler work for you where it can. Obviously your COM interfaces have to be declared with WideString, but try to avoid anything beyond that.

EDIT
Take a look at the link provided by Hughes: http://stackoverflow.com/questions/2048601/get-ready-for-delphi-2009-and-up-when-developing-with-delphi-7/2048942#2048942

Also just to emphasise: Each new version of Delphi attempts to maintain some level of backward compatibility (Delphi 2009 included). If you just code 'normally' you're unlikely to be impacted to any great degree. In fact the converse is generally true; the more fancy you get, the more likely you are to encounter problems.

The only serious problems I've ever had with moving to new versions of Delphi are:

• 3rd party code/libraries without source code.
• Unmaintained 3rd party code where their developers resorted to various coding 'tricks'.
• Midas code in Delphi 3 was a particularly arduous upgrade. (But there again, developers bypassing the recommended techniques was a big culprit.)

Answer 2

Good to know Unicode Migration White Paper

Answer 3

(The odd pbyte declaration of VST is probably more a workaround for the fact that {$pointermath on} is D2009 and you can't overindex pbyte in lower versions. It is probably not unicode related)

Answer 4

You can follow one simple rule that will make code you write in Delphi 7 migrate very easily into the Unicode world:

Do not assume anywhere that the size of a Char is 1.

In other words, always use

SizeOf(Char) instead of a 1 in your code.

If you code with that simple rule in mind, your path should be quite smooth. It is entirely possible to write code that will compile without change in both environments.