[fpc-pascal] A serious Memleak using delegates/implements (was: Delegate Interface class does not seem to be referenced counted)

[Lars]

On Wed, October 5, 2016 9:54 pm, Martin Schreiber wrote:
> On Thursday 06 October 2016 00:16:22 Tony Whyman wrote:
>
>> On 05/10/16 23:03, Graeme Geldenhuys wrote:
>>
>>> Martin Schreiber recently mentioned in another Interface discussion
>>> that there is a very good reason he doesn’t use COM style
>>> interfaces… Reference Counting!
>>>
>>
>> Used properly reference counted interfaces are very powerful and allow
>> for some very elegant programming. Do you complain about AnsiStrings?
>> They are reference counted. Would you really want to have to free every
>>  string explicitly? Dynamic arrays are similarly reference counted.
>>
> Reference counting is great for simple types like strings and dynamic
> arrays but is a nightmare with the venturesome mixture of COM-interface
> and classes from Delphi. Even reference counting for complex classes is no
> good idea IMO, I fear the times when FPC will implement ARC.
> I don't think that a programming language should hide more and more of the
>  internal working of the code he writes from the programmer. Take a look
> at the modern C++ programs; the LLVM-compiler is a good example. It is
> horrific slow. Stepping through the code shows that there are complex
> multi-level dynamic type conversion and dataaccess routines at almost
> every statement. The typical C++ programmer does not need to care about
> because the programming language takes care for the boring tasks. The
> typical C++ programmer actually *does* not care about performance because
> competing programs are not faster; they are written in a modern
> programming language too... Recently I had to revive my stone old AMD-K6 PC
> with Windows 95. What marvel, that relict with its age-old applications
> provides a better user experience, is snappier, more convenient and more
> productive than my newest Linux machine with the modern desktops and
> applications.
>
> Martin

Replying to an old thread in my inbox. Apologies if it's obsolete as it is
a month old.

Martin, as you know, Windows 95 is mostly coded in plain C, so guess what
that meant: you had to reboot your pc every day to reset all the memory
leaks. So your idea that we should not be hiding code with more
abstraction layers is a double edged sword. Windows 95 is a very zippy,
fast, snappy operating system. But it also was not garbage collected so
had memory leaks due to poor programming in plain C.  Remember when people
migrated over to Windows 2000 and Windows XP and found that they no longer
needed to restart their PC daily to reset the memory leaks?

 Sometimes my windows 98 computer would last for a week, and that was
about it before I had to restart. Usually I had to restart every 1-3
days. And why is that? Because windows 95/98 did not have an abstract
programming language in place which hid details. It's all manual memory
management which causes tons of bugs. And these bugs are the same issue
seen in all kinds of delphi/lazarus apps....

Admitting, however, that Windows 2000 and XP did not migrate to any
garbage collected language, they just improved the old buggy code so that
there were less memory leaks and now instead of rebooting your PC every
day or 3 days, you can wait a month before rebooting, or sometimes a
couple weeks, or sometimes a week. But there are still bugs in
win2000/windows10/windows7 which cause me having to reboot my PC.  And
wow, Firefox needs to be constantly restarted, as the memory leaks grow
out of control. But that's not a plain C app.

At the same time, I'm also scared of reference counting as you are, for
classes, as garbage collection mechanism. But since you are against hiding
details from the programmer, what's your opinion of Oberon garbage
collection that Wirth designed, if it was somehow implemented in FPC?
Likely that won't happen. However you say you are against hiding too many
details from the programmer (abstraction) so you think Oberon's garbage
collection system is too high level and would prefer to free and create?

To keep it on topic, related to fpc, and to not divert to oberon
discussion only: are you saying that if somehow and oberon like garbage
collection was implmented in fpc you'd be against that as it is too
abstract, or are you saying you are just against reference counting, but
would accept an Oberon like garbage collection? Unfortunately, that means
more like a new programming language rather that continuing fpc as it is,
likely. As oberon is designed to be that way, to handle garbage collection
and even module unloading/loading at run time, whereas fpc not so much.