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
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)"
On Mon, 30 Jul 2018, J. Gareth Moreton wrote:
> I would say that that's a little naÃ¯ve and dangerous to think like
> 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