Delphi Mobile (NEXTGEN) compiler: the risk of a changed TSymbolName; unsupported data types means unsupported RTTI as well

The NEXTGEN family of Delphi compilers for the Mobile platforms changed quite a bit of things.

Most of it has been covered by various blogs posts. A non exhaustive list of ones I liked:

• Delphi Language for Mobile Development Paper by Marco Cantu with this 40 page PDF white paper.
• Lars Fosdal – Google+ – Differences between Delphi Desktop Compilers and Delphi Mobile Compilers….
• It’s a blong, blong, blong road…: New compiler directives in Delphi XE3 (he doesn’t mention NEXTGEN, but covers zero based strings in addition to compiler directives).
• Zero-based strings (Delphi) – RAD Studio explaining the ZEROBASEDSTRINGS directive.
• Everything TStringHelper is zero-based:
  Exploring Delphi XE3 – Record Helpers for simple types – System.SysUtils.TStringHelper | The Road to Delphi – a Blog about programming.
  Mark Edington’s Delphi Blog : XE3 RTL Changes: A closer look at TStringHelper.
• DWS and zero baded strings: Zero-based Strings indexes? – DelphiTools.info.
• TMS Software | Blog | TMS Aurelius in your iPhone.
• Delphi XE 4 – Is ARC for Everyone? | Olaf’s Thoughts About Development.
• and of course: Migrating Delphi Code to iOS from Desktop – RAD Studio.

Those articles do not contain two things I had’t found about yet though that are important when you do RTTI using NEXTGEN in Delphi XE4:

1. The TSymbolName changed from a types string[255] to Byte

Though TSymbolName is still documented as being a ShortString (classic Turto Pascal style non reference counted single byte string of maximum 255 characters with a length byte as very first (zeroth?) byte), it is not:

This creates all kinds of havoc, especially when you use System.SysUtils.Format or Exceptions to format readable RTTI output like this: as the %s will break when a Byte is passed.

So I worked around it using the SetString and Utf8ToUnicode methods: a NEXTGEN compatible GetShortStringString method.

Now the exception is raised like this:

2. Despite the absence of some types in the NEXTGEN compiler, the TTypeKind declaration in the TypInfo unit has not changed:

The TTypeKind is still declared to be this:

But in fact these TTypeKind values are not supported in NEXTGEN:

• tkWString: Identifies a WideString (wide string without reference counting) type.
• tkLString: Identifies an AnsiString (single byte string with reference counting) type.
• tkChar: Identifies a AnsiChar single-byte character type.
• tkString: Identifies a ShortString short string type or subtype.

That lead me to this code snippet:

–jeroen