[fpc-devel] Why/how does the compiler have a non-trivial numberofmemory leaks after over two decades of development?
R0b0t1
r030t1 at gmail.com
Mon Jul 30 23:35:58 CEST 2018
On Mon, Jul 30, 2018 at 2:40 PM, J. Gareth Moreton
<gareth at moreton-family.com> wrote:
> As mentioned before, the main problem with try...finally blocks is that they
> incur a massive speed penalty, so they're not things you want to enter and
> exit on a frequent basis. Whether that means we need to work on the compiler
> so it reduces this penalty on such blocks (such as internally removing the
> construct and copying the code in the 'finally' section into a local
> exception handler) I'm not sure.
>
> I do agree though that we should manage memory with care, especially as
> Pascal gives us such fine control over it (compared to, say, C++'s RAII
> feature which is a little nebulous at times with its garbage collection). I
> think first though we need to fix any obvious memory leaks, namely objects
> and blocks of memory that we forget to free, then build up from there. At
> least that will help reduce the risk of an out of memory situation during
> normal operation.
>
> Gareth aka. Kit
>
Adding locally allocated structures to a global list is a pretty
gnarly issue that will take some time to solve. The easier ones are
simply using labels to easily manage exit conditions. It looks a lot
nicer than nested if statements.
The issue with such code is it is fairly boring to write, so I
understand if someone didn't do it initially.
More information about the fpc-devel
mailing list