FPC and 64 bit: the future is today
FPC published a 64 bit compiler using the Delphi/object pascal language in 2006.
It could have been fair and less confusing that Delphi engineers just follow the same patterns, for example use PtrInt and PtrUInt.I guess that in 2006, the 64 bit Delphi compiler was already a R&D
project at Borland, (and Codegear since February).
That's why NativeUInt and NativeInt were made available in Delphi 2007.
But FPC published its 64 bit compiler in 2006... and EMB is not able to promise
such a working x86-64 compiler before end of 2011.
The preview 64-bit compiler is still indicated with a "first half of 2011"
like it was and future versions should have both 64-bit and Mac support,
although from the slides it is not clear which features actually go into Pulsar
("Introduction of 64-bit and cross-platform to the RAD Studio product line"),
Wheelhouse ("Extending support for 64-bit and additional platforms"), and
Commodore ("Full support for 64-bit compilers for Windows, Mac OS, and Linux").
Part of the differentiators comes from the fact Delphi language will be there
before C++, according to come of the details.
See http://edn.embarcadero.com/article/39934
Some kind of messy
About the IDE, RadStudio is much more advanced than Lazarus. But there are some newcomers around, like mseide, which is light and powerful.
Newest Delphi compiler have some language enhancements (like generics and
attributes, without naming Unicode which is mostly VCL-related), but FPC
evolves (it includes generics and in the future clever property
attributes).
But the more it goes, the less compatible.
If you want your code to compile with both Delphi and FPC, you need a lot of
{$ifdef} and/or custom types... and a good knowledge of every compiler.
Sometimes, I miss a "standardized language", like C#, even if the libraries are not standardized (if you want to work cross-platform, e.g. using Mono, you can't rely simply on latest Microsoft libraries).
Will there be a "fratricidal war"?
If such a war happens (but isn't it already there?) in the object pascal
world, we can worry.
My first reaction is to think about "poor little FPC". And imagine me at the
compiler graveyard, praying on its tomb.
But after some deeper thinking, it's not so simple.
I'm not able to see which one will be the winner.
First of all, FPC is Open Source: it can't dye, if people
have interest in it.
And because of object pascal language strength, even a small team of coders can
handle it.
At a glance, Delphi seems more powerful than FPC, because of EMB. But it
could be exactly the contrary...
Remember the Delphi for DotNet compiler: it was replaced by Oxygene, a not EMB
product, but a more reactive product.
Since FPC is written in pure object pascal code (and the Delphi compiler isn't, by the way), it could be easy for EMB to embed the FPC compiler into their RadStudio XE... And by using wxforms, extending it with DB components, RadStudio could easily cross-compile to both Linux and MacOsX.
So will the Delphi for Win32 compiler dye, just as the Delphi for DotNet
did?
Isn't FPC at the right place, at the right moment?