Objective comparison between FreePascal/Lazarus and Delphi

[WILL]

I'm not interested in bashing anybody or speculating. Just the facts, and what they mean to me as a developer.

And I wouldn't accuse you of such. I was only making a half-joke. Your thread was a really good idea actually.

With regards to the GBD on Mac OS X debugger issue; I found this in the FAQ... http://wiki.lazarus.freepascal.org/G...r_Tips#Mac_OSX

[Murmandamus]

Oh, no, I didn't think you were. It is an important point. Like I said when I started the thread, I don't want to turn it into a "holy war", as it is easy to get distracted into going there; been there, done that, got the t-shirt.

The goal is to not only help us choose the tool that is right for our needs, but also see where the each tool is weak and in need of improvement. In my opinion, that is more pertinent for FP/L because it can be fed directly into the development process, whereas such improvements might lag a bit with Delphi because of the general nature of closed-source software development versus FOSS development. It still is good for both, though.

One example for both is the lack of a real macro preprocessor extension. While I really don't like C (and its dialects) as a language, there are some superlatives about it that I miss in Object Pascal; one of those is a decent macro preprocessor built into the compiler. FP does have an experimental one, but it is somewhat limited. Of course, some folks will say to just use m4 or some other macro preprocessor, but m4 is a bit heavy syntactically, and it doesn't have an "integrated" feel to it.

[LP]

FreePascal compiler itself is pretty powerful and is comparable to Delphi (with few quirks, see below). Lazarus has evolved quite a bit and has some nice features, but when compared to Delphi it still feels uncomfortable.

The main drawback of using FPC/Lazarus is the compilation time, which is considerably longer. If you have a very large project and need to correct/recompile very often (for instance when doing some precise 1-pixel adjustments in the rendered scene), it slows you down very much.

Although other people reported success with the debugger, I was never able to make it work reliably on any computer I've tried. In the best scenario it works only once and then you can't view any of the variables. In practical terms for me, working in FPC/Lazarus means working without the debugger (instead I use logging to an external text file for debugging).

The generated EXE files by FPC/Lazarus are quite larger when compared to Delphi, even after stripping everything down. However, Delphi XE also generates larger EXE files when compared to Delphi 2007 and earlier. In practical terms, this is not a problem, but still a little bit annoying.

Lazarus IDE still have some bugs that were not fixed, like the scrolling speed too slow with mouse scrolling wheel in some configurations.

Specifically to FPC: the compatibility/incompatibility with Delphi is quite weird. The most annoying thing is that if you declare property "HelloWorld", you can't use it as a parameter to function in the same class, unless you turn on Delphi compatibility. If you turn on Delphi compatibility, you loose FPC overloading capabilities.

There are other obscure weirdness with the namespaces where you try to access some global class/variable, which is declared in different files, and you include both in Interface and Implementation sections. In Delphi, this is straightforward, in FPC it is quite obscure and unpredictable.

[Murmandamus]

Hmmm.. I am beginning to formulate a future research topic idea..

Figuring out exactly what the "bloat" is in generated executables from both tools. I mean, I know that a lot of FP/Ls exe size is due to debugging info and not using the smart linker. One test form I tossed together (just an app with a single MDI form, a 30-item menu, and about 10 other controls, no actual functional code) generated a whopping 12MB EXE. Of course, I went in and twiddled with compiler/linker settings, and it went down to 1.8MB, but that's still a bit excessive for not a whole lot of code. As a result, I would conclude that either the code is not as "severable" as it should be, or the linker is not as smart as it could be.

Guess I need to whip out my file analyzer and see what's under the hood.

[LP]

As a result, I would conclude that either the code is not as "severable" as it should be, or the linker is not as smart as it could be.

I think the component set included with Lazarus by default is what makes the EXE so large. In a way, it is similar to Delphi - if you create a simple console application without any GUI whatsoever, the size is very small. In any case this may serve as an advantage; for instance, some applications compiled with VC++ need the VS runtimes to be distributed and installed, while in this case you have a fully stand-alone application. The "bloat" also exists (to a lesser degree) in apps compiled with Delphi XE, so we'd better get used to it.

[Murmandamus]

Oh yeah, I was aware that Delphi has the same problem. It always has; they even used to include a command-line utility called "W8LOSS.EXE" that scanned the EXE and stripped out some unused stuff the "smart" linker apparently missed. Primarily, it is the VCL which causes the bloat because there is potential for dynamic creation of any components at runtime, so it goes ahead and links it in, just in case.

Also, of course, all resources are linked into the EXE file.. any static bitmaps in TImageLists, Icons, strings, etc. General GUI data bloat adds its 20 pounds of flab to the EXE as well.

The one nice thing about it is that it generally is a one-time charge bloat. IE, the file sizes start out larger than you would expect for the basics, but don't balloon out at the same rate. Like you were saying, it more or less includes the equivalent of MSVSCRxx.DLL as part of the EXE, making it easy to pass around the standalone EXEs.