[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