Hi, On Fri, 12 Nov 2010 00:46:43 +0100 (CET), Dimitri Smits <smi...@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. > ---8<-----------8<-----------8<-----------8<-----------8<----------- > > [... snipped use of interface hacks to implement scoped memory...] > > should I file (2/a) bug report(s)? or is there no point in doing so since > they won't be fixed either? 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). 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 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. (*) maybe newer Delphis have the C# "using" keyword or something similar (maybe "with" recycling?). I would be interested to hear about that. Thomas _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel