Strict type checking for tObject.

[A.M. Hoornweg 144]

Hello all,

 

I saw how FreeAndNil is implemented in the RTL using a "CONST [ref]" parameter and then a little "tweak" is used to NIL the variable being referenced. I wondered why the heck the object wasn't simply passed as a VAR parameter in the first place. Until I tried that out and found that it wouldn't compile. Delphi insists that you either pass the exact object type or use a typecast.

 

What I don't understand is the reason why Delphi is so strict here; if a class derives from tObject, it still has all the original stuff in place from its ancestor so you can't really "break" anything by treating it as a tObject, so why is Delphi so strict?  It feels counter-intuitive.

 

Type tBase=Class(tObject)
  procedure test;
end;

Procedure tBase.Test;
begin
//
end;

Procedure MyFreeAndNil(VAR obj: tObject);
begin
 obj.free; 
 obj:=Nil;
end;


procedure test;
var t:tbase;
begin
  t:=tbase.create;
  MyFreeAndNil(t);
end;

 

[Stefan Glienke 2009]

It is pretty simple - imagine if the code below would work that way:

procedure ReplacePet(var pet: TPet);
begin
  pet.Free;
  pet := TCat.Create;
end;

procedure Main;
var
  dog: TDog;
begin
  ReplacePet(dog);
  dog.Bark; // meow?!
end;

FreeAndNil is special because it just destroys and assigns nil. But a var parameter does not give that guarantee.

Edited November 25 by Stefan Glienke

[Remy Lebeau 1405]

Perhaps this will help: Magic behind FreeAndNil

Edited November 25 by Remy Lebeau

[Dalija Prasnikar 1399]

Another more elaborate example that will show why is compiler strictness for var parameter necessary, and why without it we could easily and unintentionally write the code that can corrupt memory otherwise Pass the Dog, Get the Cat