[fpc-devel] Interface scope incompatibility with Delphi

[Dimitri Smits]

----- "Thomas Schatzl" <tom_at_work at gmx.at> schreef:

> Hi,
> 
> On Fri, 12 Nov 2010 00:46:43 +0100 (CET), Dimitri Smits
> <smitco at telenet.be> wrote:
> > 
> > it seems that the stackvariables are NOT unloaded in the correct
> order
> > (ie: reverse order of declaration).
> > It shouldn't matter in what order you fill them, but in the order
> they
> are
> > declared. (like good practice in constructor vs destructor, but then
> in
> > stack variables setup/cleanup)
> 
> Imho the compiler should generally be free to
> reorder/remove/reuse/add
> temporary variables on the stack as it sees fit. What you experience
> is
> only an artifact of the current implementation.
> Making assumptions about exact stack layout (in particular of local
> variables) beyond what is specified by the calling convention is
> generally
> not a good idea.

[snip]

> 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.

anyway, I never mix dependent variables like that in the same method, so it would not matter a lot to me. Was just stating that this is "how delphi does it" and that some code may depend on it.

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.

> 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.

> Or, this interface memory management may be implemented using tracing
> garbage collection in some future target (LLVM, JVM, CLR, ...) the
> same
> way.

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.

COM interfaces are semi-unmanaged objects either way. (interface vars are managed, but the implementations have explicitly coded provisions for assistence)

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)!!!!

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

> 
> What would be interesting would be how garbage-collected Delphis
> handle
> this, can anyone help? Other than that, there is imo nothing else to
> say
> than that Pascal/Delphi(*) does not have explicitly scoped lifetimes
> with
> automatic destructor call for classes/objects at the moment.
> 

argument is moot. .Net has provisions for object-instance assignment and internal "ref-counting" in the CLI and/or VM/interpreter. Java the same with its bytecode & jvm. 


> (*) 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.

kind regards,
Dimitri Smits