Pages

Thursday, January 10, 2008

Unicode Delphi

The Oracle at Delphi (aka Allen Bauer) has posted some information on Unicode support in the next Delphi (codenamed Tiburon).

Firstly, let me say that I really appreciate that we'll finally get VCL Unicode and reference-counted wide string support in Delphi. I really really really appreciate that.

Secondly, I must say, and I must say this very loud, that I DON'T LIKE HOW IT WILL BE IMPLEMENTED! (And I apologize for yelling in public.)

Allen wrote

This new data type will be mapped to string which is currently an AnsiString underlying type depending on how it is declared.  Any string declared using the [] operator (string[64]) will still be a ShortString which is a length prefixed AnsiChar array.  The UnicodeString payload will match that of the OS, which is UTF16.

And

If your code must still operate on Ansi string data, then simply be more explicit about it.  Change the declaration to AnsiString, AnsiChar, and PAnsiChar.  This can be done today and will recompile unchanged in Tiburon.

I wrote my response in comments to the Allen's post and I'll restate it here.

This is very very bad. This will not work for our company and I presume for many of us working with legacy applications with millions of source lines. We have applications using 3rd party components and libraries (all with source code, thankfully). We have applications using libraries that can be compiled for Win32 and for DOS (with BP7 and plenty of IFDEFs, of course). And we have no illusions that they will continue to work if string suddenly becomes an UTF-16-holding type.

We would like to move to Unicode Delphi, but we would like to do it gradually, when starting work on new applications. That way, we can test all units, components and libraries as they are introduced in the new program and we can fix all problems that will occur.

So please, CodeGear, give as an 'Unicode application' option. It should be disabled for old applications and enabled for new ones. That would be a much better plan.

[If you agree with me, make sure to post a comment in Allen's blog stating your opinion. If you don't agree with me, make sure to post a comment in Allen's blog stating your opinion. He needs as much feedback as possible to make decitions that will be good for us.]

6 comments:

  1. Anonymous03:24

    I don't think they care that much. Everyone's excited about that long awaited feature and the general attitude is "who needs the old applications anyway".
    I've given up hope. I'm not even sure why I insist on keeping using Delphi for new applications anymore.

    ReplyDelete
  2. Anonymous04:18

    Don't worry, I think there will be a project option to disable this auto mapping, like what they did for old ShortString (Syntax options -> Huge strings).

    ReplyDelete
  3. Of course there must be an option to switch on/off mapping of String to UnicodeString.

    I agree with author

    ReplyDelete
  4. I fully support CodeGear's decision... it's definitely the best solution for those who want to upgrade everything to Unicode. But I guess there will be an option to turn it off, too.

    ReplyDelete
  5. Apparently there won't be such an option: And now the $100,000 question.

    ReplyDelete
  6. Anonymous13:33

    Best way
    string == ansistring
    and add new type unicodestring

    ReplyDelete