5 ms·

>inline variable declarations (which wont be added because the Free Pascal developers feel that they aren't "Pascal-ish"). That is the big one And just in qua

• badsectoracula 6y ago
  > That is the big one Well, it isn't a matter of "catching up" then since the developers have explicitly decided to not implement that feature in terms of language design grounds (though IMO considering how many additional dialects and subdialects the compiler supports not adding it even behind a modeswitch is weird - but i wouldn't really call it a "big one"). > And just in quality. FPC compiles slower or even crashes during compiling. I'm using FPC for almost two decades now and the only time i had FPC crash was when i fed it around 300MB of randomly generated code to see how it'd react - it was the 32bit binary too so that probably helped :-P. I'm not saying it wouldn't crash for you but personally over the years over many projects, machines, installations and OSes (i've used it on Windows, Linux, macOS, OS/2 -well, eComStation, same thing- and even Haiku) and never had it crash so i doubt it is really a thing common enough to stand out. In my experience FPC was always rock solid - Lazarus too as of late 2000s (it used to be more crashy before that though). For performance i agree that it isn't ideal but on the other hand Free Pascal supports a much greater number of architectures, a bunch of different dialects and subdialects and all that make the compiler much more complicated and thus slower. And in practice even Lazarus which AFAIK is almost 2 million lines of code compiles in a matter of seconds (on my PC) so i do not really mind that much (though sure, it'd be nice if it was as fast as Delphi). > Debugging is worse with gdb. This is really gdb's issue though, there is a new debugger written specifically for Free Pascal that from the little i've used it is much more reliable.... and i just read as i was typing this that it should work under Windows properly now, so i might try it (i also have issues with gdb). > On Linux it uses longjmp exception handling which is rather slow. Hm, perhaps though i've often done profiling in my apps and never noticed anything related to exceptions to enter the picture (i'm not using exceptions myself much though - especially not in any 'hot path'). > It tries to warn about uninitialized variables, but does not track properly which ones are initialized There have been a bunch of changes very recently and in fact they introduced even more warnings :-P but TBH i only notice those whenever the initialization is based on conditions that may have other side effects and the use is based on those side effects - you writing the code know this can't happen, but the compiler cannot tell that (i'm not even sure if it is possible in all cases). I usually just either initialize the variable to "default" or hide the message through an IDE directive (it'll show in command-line builds though). > Lazarus is not FreePascal. They only include libraries that are Lazarus Packages (with an *.lpk file), and I use libraries that do not have one Yeah but Lazarus is by far the most common IDE used with Free Pascal so it is a safe assumption that someone using one also uses the other. And besides the Lazarus package manager doesn't contain every Lazarus package either, however what you originally wrote was that there isn't a package manager, not that everything should be available from it. > On the other hand, I used Lazarus (only LCL and lazbuild) is another project, and tried to submit it to an open-source app store, and they refused it, because they would not install Lazarus, because Lazarus was an IDE. Well, that isn't an issue with Lazarus either, though you should have told them that Lazarus does have a command-line project builder called lazbuild so it can also act as a building tool. > Anyways, what is missing is a single command line call that installs all dependencies I used in my projects. And these dependencies are neither in opm nor fppkg AFAIK fppkg was introduced in recent years and from what i remember from the mailing list not everyone was interested in package managers (e.g. personally i am not, i tend to stick with whatever comes with the language since external stuff may stop be developed - and Free Pascal and Lazarus come with a ton of packages out of the box anyway) so chances are you won't ever be able to find all dependencies in a package manager. It is there more as a convenience to avoid downloading stuff manually.
  • vram22 6y ago
    Thanks for the detailed answers, though I am not the one who asked.
  • benibela 6y ago
    >Well, it isn't a matter of "catching up" then since the developers have explicitly decided to not implement that feature in terms of language design grounds I am very frustrated by their opinion And that is also for the uninitialized variables. With inline variable it would be much simpler to always initialize all variables. >I'm using FPC for almost two decades now and the only time i had FPC crash was when i fed it around 300MB of randomly generated code to see how it'd react - it was the 32bit binary too so that probably helped :-P. The more complex my project becomes, the more it crashes. When I made too many units, I got this https://bugs.freepascal.org/view.php?id=37478 https://bugs.freepascal.org/view.php?id=37478 and now it has been going on for years (with the related issue) And I use the trunk version (3.3.1). It is much less stable than the official releases. >Hm, perhaps though i've often done profiling in my apps and never noticed anything related to exceptions to enter the picture (i'm not using exceptions myself much though - especially not in any 'hot path'). The problem with longjmp exception handling is that it is slow, even if no exceptions are used Like this procedure abc; var s: String; begin s := '123'; end; becomes project1.lpr:15 begin 0000000000401240 55 push %rbp 0000000000401241 4889e5 mov %rsp,%rbp 0000000000401244 488d642490 lea -0x70(%rsp),%rsp 0000000000401249 48c745f800000000 movq $0x0,-0x8(%rbp) 0000000000401251 488d55e0 lea -0x20(%rbp),%rdx 0000000000401255 488d75a0 lea -0x60(%rbp),%rsi 0000000000401259 bf01000000 mov $0x1,%edi 000000000040125E e8dd340100 callq 0x414740 <fpc_pushexceptaddr> 0000000000401263 4889c7 mov %rax,%rdi 0000000000401266 e8b50b0000 callq 0x401e20 <fpc_setjmp> 000000000040126B 4863d0 movslq %eax,%rdx 000000000040126E 48895598 mov %rdx,-0x68(%rbp) 0000000000401272 85c0 test %eax,%eax 0000000000401274 7510 jne 0x401286 <ABC+70> project1.lpr:16 s := '123'; 0000000000401276 488d7df8 lea -0x8(%rbp),%rdi 000000000040127A 488d35971d0900 lea 0x91d97(%rip),%rsi # 0x493018 <.Ld1$strlab+24> 0000000000401281 e8fa9c0000 callq 0x40af80 <fpc_ansistr_assign> 0000000000401286 e825380100 callq 0x414ab0 <fpc_popaddrstack> project1.lpr:17 end; 000000000040128B 488d7df8 lea -0x8(%rbp),%rdi 000000000040128F e88c9c0000 callq 0x40af20 <fpc_ansistr_decr_ref> 0000000000401294 488b4598 mov -0x68(%rbp),%rax 0000000000401298 4885c0 test %rax,%rax 000000000040129B 740f je 0x4012ac <ABC+108> 000000000040129D e8be390100 callq 0x414c60 <fpc_reraise> 00000000004012A2 48c7459800000000 movq $0x0,-0x68(%rbp) 00000000004012AA ebda jmp 0x401286 <ABC+70> 00000000004012AC 4889ec mov %rbp,%rsp 00000000004012AF 5d pop %rbp 00000000004012B0 c3 retq That one, innocently looking function includes 4 different functions calls for exception handling, although there are zero exceptions involved. Any function that has automatic memory handling, has to do: Register itself for exception handling at the beginning; unregister itself at the end; catch any exception and then forward it to the next registered exception handler >There have been a bunch of changes very recently and in fact they introduced even more warnings :-P They are making it worse every year. >I usually just either initialize the variable to "default" Sometimes not even that works. Especially with nested functions accessing variables of the outer function. If I had a say, there would be inline variables with mandatory initialization. Any variable not initialized at its declaration, should be a compile time error. >Well, that isn't an issue with Lazarus either, though you should have told them that Lazarus does have a command-line project builder called lazbuild so it can also act as a building tool. They google Lazarus, see it says "IDE", and then there is no point in talking to them anymore >(e.g. personally i am not, i tend to stick with whatever comes with the language since external stuff may stop be developed - and Free Pascal and Lazarus come with a ton of packages out of the box anyway) Me, too. But that is really bad. The RTL is coupled with the compiler, so you cannot really update it without updating FPC. Like the JSON parser does not work properly. They fix it (or I did it), and with a package manager you could update it. Or with an external library you could update that. But with FPC, you need to update FPC. But you cannot, because there is no release, for years. So you need to update to trunk and compile FPC yourself. But then you get an unstable, untested version, which is going to break a lot of unrelated code. Today I actually looked at another JSON parser. It is probably better than FPC's, but I am not going to use it, because it is too much trouble to install it. I looked at its code, and one of the first classes they implement in the JSON parser unit is a string builder. In 2021, string builders really should have been a solved problem. Implementing string builders is a big waste of time. FPC has a builtin string builder, but it is too slow, it is basically unusable. I also wrote a string builder. It is around 40 times faster than FPC's. (I actually profiled it recently. Mine has about the same performance as the default Java one. I started using Pascal, because I thought a native language would be faster than a byte code language. But apparently not. Inlining the char append method is important. Without inlining, the Java version was twice as fast. On the other hand, I reimplemented append in amd64 assembly. It is 5% faster without inlining than the inlined version. Now with an active open-source community, we could write one assembly version for each platform. That would give maximal performance. But I do not want to maintain it. 5% speed is not worth the risk of having a bug on some platform. I do not have time to test x86 and arm versions. I need one version that works the same everywhere. So I removed my assembly version again ) They could have just used my string builder in the JSON parser instead developing a new one. But they probably do not know about it. And they will probably think it is too much trouble to install it. So people keep reimplementing the same things again and again, and the ecosystem does not get anywhere