[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:

var
     o: TObject;
begin
     o:=TObject.create;
     { do something ... }
     o.free;
end.

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