Differences between Delphi Desktop Compilers and Delphi Mobile Compilers
Differences between Delphi Desktop Compilers and Delphi Mobile Compilers
(Yanked from the What's new page)
The two Delphi mobile compilers (DCCIOSARM and DCCIOS32) are quite different from the Delphi desktop compilers (DCC32, DCC64, DCCOSX). The mobile compilers can be considered a "Next Generation" of the Delphi language, and the mobile platform is a new step in the continuing evolution of the Delphi language. Keep in mind, however, that the language differences typically are not related to platform differences.
To summarize:
- No inline assembly is supported on iOS, but four atomic intrinsic functions are supported by the Delphi mobile compiilers
- COM is not supported
- Seven of the older string types are not supported:
AnsiString
WideString
AnsiChar and PAnsiChar
PWideChar
OpenString
ShortString
Strings are:
- Immutable (constant), so you cannot index into a string as an array and manipulate the characters in a string
- If you attempt to modify a string, the Delphi mobile compilers might emit the message W1068 Modifying strings in place may not be supported in the future (Delphi).
- You can specify whether the message x1068 is emitted as a warning or an error. In the Hints and Warnings page, set the warning "Modifying strings in-place...." to "true" or "error".
- 0-based instead of 1-based (requiring possible changes to string handling routines)
- You can use the new Delphi compiler directive {$ZEROBASEDSTRINGS} to change the string indexing scheme locally. However, the RTL for the Delphi mobile compilers uses 0-based strings, so you must use 0-based strings when you are using the RTL in a Delphi mobile app.
For example, {$ZEROBASEDSTRINGS} is useful if you have an isolated instance of in-place string editing that you cannot migrate to 0-based indexing at the moment. It is not safe to use {$ZEROBASEDSTRINGS} for code larger than a snippet; do not use {$ZEROBASEDSTRINGS} for an entire module or application.
For all string handling, we recommend using TStringHelper functions. See Migrating Delphi Code to iOS from Desktop for examples.
For editing a string in place, we recommend using TStringBuilder.
Automatic Reference Counting is on by default for classes as well as interfaces, strings and dynamic arrays.
Note: The With statement might not be supported in the future by the mobile compilers or new compilers. We recommend that you refactor or rewrite any With statements in your code base, and eliminate With statements where possible.
For more information about writing code for the Delphi mobile compilers, see Migrating Delphi Code to iOS from Desktop. (http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop)
http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop
(Yanked from the What's new page)
The two Delphi mobile compilers (DCCIOSARM and DCCIOS32) are quite different from the Delphi desktop compilers (DCC32, DCC64, DCCOSX). The mobile compilers can be considered a "Next Generation" of the Delphi language, and the mobile platform is a new step in the continuing evolution of the Delphi language. Keep in mind, however, that the language differences typically are not related to platform differences.
To summarize:
- No inline assembly is supported on iOS, but four atomic intrinsic functions are supported by the Delphi mobile compiilers
- COM is not supported
- Seven of the older string types are not supported:
AnsiString
WideString
AnsiChar and PAnsiChar
PWideChar
OpenString
ShortString
Strings are:
- Immutable (constant), so you cannot index into a string as an array and manipulate the characters in a string
- If you attempt to modify a string, the Delphi mobile compilers might emit the message W1068 Modifying strings in place may not be supported in the future (Delphi).
- You can specify whether the message x1068 is emitted as a warning or an error. In the Hints and Warnings page, set the warning "Modifying strings in-place...." to "true" or "error".
- 0-based instead of 1-based (requiring possible changes to string handling routines)
- You can use the new Delphi compiler directive {$ZEROBASEDSTRINGS} to change the string indexing scheme locally. However, the RTL for the Delphi mobile compilers uses 0-based strings, so you must use 0-based strings when you are using the RTL in a Delphi mobile app.
For example, {$ZEROBASEDSTRINGS} is useful if you have an isolated instance of in-place string editing that you cannot migrate to 0-based indexing at the moment. It is not safe to use {$ZEROBASEDSTRINGS} for code larger than a snippet; do not use {$ZEROBASEDSTRINGS} for an entire module or application.
For all string handling, we recommend using TStringHelper functions. See Migrating Delphi Code to iOS from Desktop for examples.
For editing a string in place, we recommend using TStringBuilder.
Automatic Reference Counting is on by default for classes as well as interfaces, strings and dynamic arrays.
Note: The With statement might not be supported in the future by the mobile compilers or new compilers. We recommend that you refactor or rewrite any With statements in your code base, and eliminate With statements where possible.
For more information about writing code for the Delphi mobile compilers, see Migrating Delphi Code to iOS from Desktop. (http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop)
http://docwiki.embarcadero.com/RADStudio/XE4/en/Migrating_Delphi_Code_to_iOS_from_Desktop
I can hear the sound of code breaking - but perhaps for the better?
ReplyDeleteThe question is how much old and ugly code do you want to reuse for some iOS software you are creating tomorrow. I think the minority of developers has software written for Windows they can just throw into dccios to make it available on iPhone.
ReplyDeleteImo the problem is rather the opposite. New code will require lots of work and possibly ifdefs making it usable with dcc32/64/osx and nextgen for ios (string index, ARC, ...)
Very likely, Stefan Glienke. I going over in my head what core code that would need adaptation to be cross platform compatible, and many areas won't be much of a problem as the string handling is well encapsulated - while others (parsing related) will more or less require a rewrite.
ReplyDeleteI wonder if they will ever introduce ARC for x86 and x64?
From my (limited) knowledge of LLVM it should already be possible as we now have the Delphi frontend. From there in theory any platform can be targeted if a backend exists.
ReplyDeleteWhy?!!! I think, neither hardware nor operating system may impose such restrictions on the language constructions.
ReplyDeleteLars Fosdal In semi-private correspondence (not confidential), Allen Bauer indicated (yet again) that features such as absolute would have to be stripped out on the way to major compiler improvements. I cannot imagine that refers to anything but LLVM for the desktop compilers.
ReplyDeleteIgor Schevchenko The LLVM architecture and the implementation of the Delphi frontend does.
ReplyDeleteAbsolute is not much else than a typecast on the in-argument reference, so that's not so hard to work around, Bill Meyer
ReplyDeleteLars Fosdal I realize that, but my point was that Allen's position is an indication that LLVM is in Delphi's Windows future.
ReplyDeletePoint taken.
ReplyDeleteDid I notice that frames are now supported in FMX or was I dreaming?
ReplyDeleteA few things are not correct. Immutable strings is currently a suggestion for the future, you can modify a string element with str1[i]. You can use 1-based strings as you like. Strings are just strings, you can pass any string to any string function, no matter the fact the code manipulating them uses 0-based or 1-based notation. We recommend using a single approach for readability, but it is your take.
ReplyDeleteThere is another bigger change, which is ARC support....
See Delphi Language for Mobile Development white paper at http://www.embarcadero.com/resources/white-papers/application-development (This is a 40 pages technical document I wrote, and it should have all of the answers)
ReplyDelete