Being your hero is a good enough reason for me! One little thing that's driven me, even though it's not really an issue, is the size of the EXE files that are produced, so I seek to find any little way to shrink them down without compromising performance in the final binary.
What I like about this project is that we all have our little motivators and objectives, and we're free to explore and research. I had an idea to potentially improve the compiler speed on modern systems, but requires a lot of refactoring and I'm currently got my attention focused on researching pure function support. One drawback with any kind of memory management code is that it can put a lot of space and speed overhead on your project, although it is very useful from a debugging point of view. I've programmed my own ones in the past for C-based test projects that are meant to run for 24 hours sometimes, mostly in response to frequent crashes. It's proven very useful in catching memory leaks and identifying where they are so the memory can be freed properly. So, long story short... if you find memory that isn't freed, free it (once you check it's not used afterwards), even if the operating system or RTL cleans it up for you. Gareth aka. Kit On Mon 30/07/18 15:05 , "Karoly Balogh (Charlie/SGR)" char...@scenergy.dfmk.hu sent: Hi, On Mon, 30 Jul 2018, J. Gareth Moreton wrote: > I would say that that's a little naïve and dangerous to think like that. > Sure, Windows might have the means to clean up memory after an > application terminates, but not all platforms have such heap > deallocation features (e.g. pure DOS, where certain procedures and > interrupts remain in memory even after the application terminates... > so-called memory-resident programs). While I generally agree, in practice it's usually a non-issue. Pure DOS, as in the 16bit target is not supported to run the compiler, only via GO32V2, and having DPMI TSRs is... well... :) On Amiga and similar systems, AROS, MorphOS for example, which indeed does not free up the memory after a program terminates, I implemented a memory pool in the FPC RTL, so all memory is freed anyway during the program's exit. Any application which wants to go beyond this behavior for whatever of its own reasons is free to use the OS allocation functions directly, or implement its own memory manager. The same with open files on this platform, actually, which wouldn't be closed without the RTL taking care of them. And I also have to manage our own stack, and lets not even mention threading... :) The sideeffect is, that this approach silently "fix" the compiler's own leaks too, so FPC remains useable on these systems. In general it is much safer anyway, because expecting all the broken code out there to get fixed for such systems is sadly just naive. Having this said, anyone who still fixes leaks win the compiler will be my hero! :) Charlie
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
