Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27

Thread: Objective comparison between FreePascal/Lazarus and Delphi

  1. #21
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    Quote Originally Posted by Murmandamus View Post
    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
    Jason McMillen
    Pascal Game Development
    Co-Founder





  2. #22
    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.

  3. #23
    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.

  4. #24
    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.

  5. #25
    Quote Originally Posted by Murmandamus View Post
    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.

  6. #26
    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.
    Last edited by Murmandamus; 11-02-2011 at 01:15 AM.

  7. #27
    Quote Originally Posted by WILL View Post
    That kind of falls into the 'too many cooks spoil the soup' scenario. More coders doesn't make a better project nessissarily. Yes the project could benefit from more people to tackle the LCL problem (huge workload, not enough coders to do it all), but there are other problems that plague the project that have nothing to do with the amount of coders contributing to it.
    I don't agree. And as far as I understood noone called you lazy, or insinuated that. But I think that would be starting to stride from the objectivity topic of the topic at hand.

    It's not incredible goals the project is trying to achieve. It just seems to me that some people put the wrong expectations on the program(lazarus). Working with GDB isn't exactly magic, but it varies alot from each platform apparently, so I don't know why it's only Martin and Marc working on it. There's a standard, but GDB implementors don't even follow it themselves. I think I'll try abstracting it in the future because I need remote debugging to debug AVR32's

    "Good opensource software is created out of necessity; not necessarily altruism" - I think Marco Van Der Voort said something like that once

    As far as I've understood it's the only same guy who's been working on the official documentation for the last 10 years. Without getting paid of course

    "In opensource projects there aren't any lack of people telling others which direction to take; only lack of people willing to implement those changes" - Some other dude from one of the epic the Embacadero threads on Lazarus
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

Page 3 of 3 FirstFirst 123

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •