[fpc-pascal] ppcjvm issues

Jon Foster jon-lists at jfpossibilities.com
Fri Jan 27 18:52:55 CET 2017

On 01/27/2017 06:36 AM, Dmitry Boyarintsev wrote:
> On Tue, Jan 10, 2017 at 6:14 AM, Michael Schnell <mschnell at lumino.de 
> <mailto:mschnell at lumino.de>> wrote:
>     If destroying an object is not necessary, the class should provide a
>     dummy Free procedure. So the application programmer always can/should
>     use Free.
> Why dummy? if it should be like this
> procedure TObject.Free;
> begin
> if Self<>nil then Self:=nil;
> end;
> Destroying object is not necessary, but dereferencing is.
> If the code keeps the reference to an object, it would not be collected.
> [...]
Correct me if I'm wrong: It would seem like that your free implementation 
doesn't actually do anything, other than fulfilling the obligation of 
having a "free". If I do this:

     o: TObject;
     { do something ... }

Wouldn't "o" still contain a reference after "free" is called? In non-JVM 
FPC "self" is just another variable, who's origin is somewhat hidden by the 
compiler. The call to "o.free" would do something like "TObject.free(o)" 
where "o" is passed by *value* into the procedure variable "self". "Self" 
comes and goes with the scope of the "TObject.free" procedure. Which is why 
if I'm concerned about detecting whether or not "o" still contains a 
correct object reference I would need to do something like this: "o.free; 
o:=nil;" so I can test for "nil" later. Although I think FPC added a 
procedure to do that some time back. Yup, I see it "SysUtils.FreeAndNil".

I'm not sure of the specific semantics of the JVM calls but from what I 
read in the various FPC JVM related pages on the wiki it would seem to use 
similar semantics.

- Jon


Jon Foster
JF Possibilities, Inc.

More information about the fpc-pascal mailing list