Delphi XE4 NextGen compiler: using byte instead of ansichar?
When I first read the technical white paper covering all of the language changes in XE4 for mobile development (tied to the new ARM LLVM-based Delphi compiler), I have to confess I was pretty much confused.
Two great mORMot users just asked for XE4/iOS support of mORMot.
Win32/Win64 support for XE4 will be done as soon as we got a copy of
I suspect the code already works, since it was working as expected with XE3, and we rely on our own set of low-level functions for most internal work.
But iOS-targetting is more complex, due to the NextGen compiler, mainly.
It is first time we are explicitly asked for non-Windows support of
This is the reason why we did not put the cross-platform item of the roadmap at first place.
We did not do any support for this yet, because:
- No one did ask for cross-platform use of mORMot;
- FireMonkey was broken several times, has some part of it very poorly written, and do not support L2R languages - is it mature enough?
- iOS support was broken once - and I prefer FPC to this NextGen compiler (see below);
- We do not use FireMonkey in any of our applications;
- SmartMobileStudio is an innovative, fast growing, cheap, and stable alternative (with lack of documentation and 3rd party components, I admit);
- We also considered WxForms (which seems not supported any more, but did work well);
- Linux support is a goal for mORMot, on the server side.
Immutable strings are something I do not understand well, in the context of Delphi.
I still do not understand any benefit, in comparison to the copy-on-write paradigm
(COW) implemented in Delphi since the beginning for reference-counted value
With COW, you have the advantages of immutable strings and private copies and in-place modification, if needed, e.g. for fast parsing.
COW can allow your text buffer access to be safe and fast at the same time.
Using "array of byte" as a workaround from
AnsiString/RawByteString is possible, but will be slower and less
It will implements COW (if
const is used as expected in method
parameters), but it will fill the content with zeros, so slow down the
And it won't be displayed as text in the debugger, nor allow direct conversion to string.
Honestly, changing from everything from AnsiChar to Byte is just an awful workaround and breaking change.
Just like a regression from the modern/turbo Pascal paradigm to a low-level C data type.
The switch introduced by NextGen/ARM/LLVM is IMHO much bigger than the one
introduced with Delphi 2009.
For instance, for third party libraries (like our Open Source mORMot), you can maintain an existing code base for all versions of Delphi (e.g. Delphi 6 up to XE4), but you will have to maintain two versions of the code (or nest it with IFDEF) if you want to support NextGen syntax.
I understand that conversion to NextGen compiler can be easy.
See for instance how TMS reported it to be
not difficult for Aurelius.
But... do not forget that it may be on the depend of the performance.
Using pointers is not evil, if done with knowledge of it.
See this user feedback about FireBird ODBC access using Aurelius or our Open Source mORMot (which allows remote access, by the way, in addition to plain ORM).
IMHO this is one of the great features of compiled object pascal, in
comparison to managed code, or the "NextGen" model.
My point is that pointers are not evil, especially for performance.
Of course, I'm speaking about typed pointers, not blank untyped pointers.
Huge code modification... for nothing?
We could switch the mORMot code to be Next-Gen compatible, but
since we use UTF-8 at the lowest level, it will need a lot of IFDEF.
Using "array of byte" instead of "AnsiString(CP_UTF8)" and "byte" instead of "AnsiChar" is just an awful regression and compatibility break.
We would have to use a lot of function wrappers, or perhaps re-create at
hand a UTF-8 compatibility layer.
The whole mORMot core is depending on UTF-8, and IMHO this was *not* a wrong choice, on the contrary.
But why go in this direction?
I'm confused with the Embarcadero NextGen compiler.
Performance is not a goal. The RTL is just worse at every Delphi version.
... and compilation time is just dead slow, in comparison to the "PreviousGen" compiler. More than 20 times slower.
Is it worth it?
Deprecation of AnsiString was never prepared by Embarcadero.
We knew it about shortstring - OK.
We were told that the with keyword is the root of all evil, and should be avoided - OK.
But deprecation of AnsiString in the NextGen compiler sounds like a showstopper to me.
And don't tell me it is required by the LLVM compiler to have immutable
strings and UTF-16 encoding.
This is a pure Embarcadero choice.
And don't tell me it is for performance optimization.
The Delphi RTL can be dead slow and not scalable.
Current string process was not the main speed bottleneck.
And you have easy alternatives to circumvent those bottlenecks and unleash your CPU power.
And do not tell me that TStringBuilder is the answer.
In-place parsing of buffers is the fastest mean e.g. for JSON or XML performance.
TStringBuilder just replaces classic string concatenation of mutable strings associated with a modern memory manager.
It is a workaround to circumvent a performance problem. There is no benefit of using it.
I was impressed by the Win64 support of
latest versions of Delphi.
Very small breaking changes, when adapting mORMot to this platform.
IDE stable enough.
Resulting executable fast enough (at least when it relies on our SynCommons unit, and with some tuned asm code).
Even nice features where re-introduced into the compiler, after a complain in the newsgroups, like ability to compile x64 assembler functions/methods.
But here, I do not understand the direction.
Future Object Pascal
I do not want Delphi to be another managed-but-compiled language.
I like the object pascal language because:
- It has the benefits of high-level languages like C# or Java, with readability, strong typing, classes, generics, interfaces, dedicated (ansi/wide)char type, string and dynamic array reference counted types;
- It has some nice features I miss in C# for instance, like sets, enumerates or array of enumerations;
- The unit layout, with clear distinction between interface and implementation sections, is very powerful, in respect to C# or Java all-in-one syntax;
- It has the low-level power of C, if needed, especially for the library cores;
- It has a truly working class system (you can use
TMyClassClass = class of TMyClasswith success);
- It has a strong typing paradigm, which mitigates e.g. the use of pointer;
- Memory can be managed just as we need, with no Garbage Collector glitches;
- We have the whole RTL source code at hand, still readable (the C# RTL is much bigger and complex);
- It compiles very quickly, even for huge projects;
- It generates stand-alone applications, with no dll hell;
- It has a strong backward compatible history, with huge code available on the Internet.
Trying to make Delphi more C#-like is a mistake.
Just think how the attributes syntax in modern Delphi is not pascal-oriented: it should be defined after the type definition, as in the free pascal syntax, not before it, as in C#/Java.
Please fix NextGen roadmap!
Using byte instead of AnsiChar is IMHO not a
This is not "next generation".
This is a regression.
This is a breaking show-stopper.
I suspect (hope?) Embarcadero will be clever enough to
re-introduce AnsiString process to their compiler.
Forget about zero-based strings.
Allow mutable strings and pointer access to their buffer.
Otherwise, I honestly do not have much hope of continuing in this
Not worth it.
The "next gen" object pascal is not C#.
It may be the Oxygene compiler, even if I do not find so appealing a cross-compiler language with no cross-platform library.
It may either be FreePascal and its FCL/RTL, when targeting native compilation.
Your feedback is needed!
I understand that I may be one of the last one using Delphi as such.
That is, using Delphi not as a RAD tool, but as a strong platform to build huge applications.
With some unique benefits, in regard to alternatives (mainly Java or C#).
Huge list of users of mORMot, and continuous feedback on the forum, tends to prove that I'm not the only one!
Knowing that x64 assembler was re-introduced to Win64 compiler.
That Client-Server licensing was re-allowed after some newsgroup protest.
I do not want to troll, just to let Delphi have a long life!
I like Delphi, I do not want to stay with Delphi 7 for ever, I want the platform to be maintained and evolving!
But this NextGen roadmap may kill my hope, and switch to FPC and SMS.
Feedback is welcome on our forum!
Or even better please react on the Embarcadero forum directly!
Update: a lot of "reaction" did occur in the Embarcadero forum.
But no Embarcadero official did react by now.
Even Team-B members agreed about the need of a petition to integrate feedback of a lot of existing Delphi users.
Update: It is even worse than we thought...
One version later, it appears that the compiler itself and the RTL do support AnsiString!
See this blog article from Andy.......