[fpc-devel] Interface scope incompatibility with Delphi

[Thomas Schatzl]

Hi,

On Fri, 12 Nov 2010 12:26:38 +0100 (CET), Dimitri Smits
<smitco at telenet.be> wrote:
> ----- "Thomas Schatzl" <tom_at_work at gmx.at> schreef:
>> Imo: Jonas already stated, the time of the release for interfaces is
>> not
>> guaranteed - afaik the docs/specs only state that they "will be
>> released if
>> the reference count gets zero" (I have not read the docs for the
>> exact
>> wording).
> 
> I was looking in the online docs for a mention of this behaviour
regarding
> "managed" types and stack unwinding. cannot find it.

I'm quite sure that the Delphi/fpc docs do not specify anywhere that the
managed types (interfaces, strings, dynamic arrays) are required to use
refcounting at all and how and when their memory is given back to the
system - these are implementation details as well.
Except maybe for the guarantee that the memory they use will be given back
eventually (and the Free() method of an object behind an interface will be
called at some time if it has been detected as unreferenced).

> tagging interfaces and their use in local variables are supposed to be
in
> scope until exit of procedure (be it by reaching 'end;', explicit exit
or
> exception). Then they are to be nilled (and _release'd), which may
result
> in refcount=0 => Free.

You mention it: "supposed", "may result": I totally agree that there is no
specified behavior for when memory is reclaimed (or the instance behind an
interface finalized). Additionally you forgot one point: what if the
runtime system keeps an extra reference to the interface for internal
purposes? Then the program code cannot set the refcount to zero, so it will
never be released immediately whatever you do. That behavior also conforms
to the docs.

In effect, you (as a programmer) should be aware that you rely on
implementation details if you do that, not something guaranteed by some
document written by anyone.

>> So what if the runtime system internally keeps a reference for en
>> masse garbage collection using a background thread? (I.e. the 
>> refcount starting at one. This is a totally valid use case for 
>> interfaces, and which btw, also makes the "stack ordering" issue 
>> a moot point too.
> 
> What most of you do not understand is that you CAN override the AddRef
and
> Release methods to NOT do ref_counted free's. Also, Interface use <>
> automatic garbage collection, not even when you use a
> refcounted-with-free-on-0 interface.

Totally agree - this has only been an example about an implementation that
conforms to the spec - that it still uses reference counts is only to
demonstrate the point: even with refcounting, you can have a conformant
implementation that has completely different runtime properties.

Btw, FPC has non-refcounted interfaces in the language (to keep being
on-topic :). Only use COM/XPCOM interfaces if you need.

> The argument for an external garbage collector can be made for
> object-references, not for interfaces (although variables of interface
type
> can be the reason why an instance of the implementation is not garbage
> collected)!!!!

Well, the discussion was about interfaces alone (afaik), and what the
runtime system does, or tries to do, is (imo) automatic dynamic memory
management (generally called "garbage collection") for interfaces.

Just like the Java compiler and VM do with all objects, the FPC compiler
and its runtime system does with interfaces.

> that some people use it as autoptr implementations does not mean that
> interface-use = garbage-collector.

That has actually been another point of my previous post. You
cannot/should not safely use this for autoptrs because it simply does not
work (as in: is not guaranteed by the language, but maybe by the
implementation. If that isn't the case either, bad luck).

Let's agree on that FPC has "limited garbage collection", okay? :)
 
>> (*) maybe newer Delphis have the C# "using" keyword or something
>> similar
>> (maybe "with" recycling?). I would be interested to hear about that.
> 
> newer delphi's <> .net => both are different beasts entirely. win32 is
NOT
> garbage collected.

Let me rephrase the question: afaik the latest Delphi 2009(?) does have a
native win32 compiler again, so did they add anything in that respect?

Thomas