[fpc-devel] Parameters must match exactly?

"Vinzent Höfler" JeLlyFish.software at gmx.net
Tue May 18 15:25:30 CEST 2010

Florian Klaempfl <florian at freepascal.org>:

> Vinzent Höfler schrieb:
> > Florian Klaempfl <florian at freepascal.org>:
> > 
> > 
> > You wouldn't *need* typecasts. It's a pointer and the instance it is
> > pointing to will be initialized by the subroutine you're calling. And
> > that one *knows* the size of the class it created. So there's
> > typecast involved at all, if used correctly.
> You even didn't get the problem :)

Maybe I didn't. But you were talking about factory pattern, so obviously you didn't get it neither. :P Enough of that personal nonsense.

Your example cites "var" parameters. Those, of course should match. But I was (and I believe Graeme, too) talking about "out" parameters for classes in a certain context. Maybe I'm wrong.

> I'll try again but I fear it's a waste of time.

Well, we do a lot of things that are a waste of time, I suppose. Explaining somebody else why something wouldn't work isn't one of them unless done for the third time, at least. ;)

> Before the change, code like
> {$mode objfpc}
> type
>   tc1 = class
>   end;
>   tc2 = class(tc1)
>   end;
>   tc3 = class(tc1)
>   end;
> procedure p(var c : tc1);

procedure p (out c : tc1);

>   begin
>     c:=tc2.create;
>   end;
> var
>   c3 : tc3;
> begin
>   p(c3);
> end.
> was allowed and this code is simply broken, the compiler has to complain
> and this was fixed.

Agreed. But in that case a function result of type tc1 wouldn't be allowed to be assigned to tc3 either. So your previous statement ("use a function instead") didn't make too much sense in this context, did it?

> Code depending on this lazy behaviour simply needs
> to be fixed, there are several solutions like inserting a explicit type
> cast or using functions maybe together with the as operator.

But that wasn't the problem. The problem I mean is that:

procedure p (out c : tc2)
   c := tc3.create;

  c1 : tc1;


seems not to be allowed anymore. And there's no reason for it. tc2 is a descendant of tc1, so just like assigning any descendant of tc1 to a tc1 variable, such a variable should also be allowed as an out parameter. Your example above tries to do it the other way around which is indeed flawed - in any case.

BTW, I still can not follow the argument of that "out" parameters need finalization. Sure, for reference counted types this may be true, I won't argue that, but "out" used to work for integers as well as other types needing no finalization, so the compiler should not insert finalization code when classes are involved (despite of the history of "out" coming from reference counted COM objects or whatever). The compiler should be able to statically determine the type of parameter involved and insert or omit finalization code as necessary for the /type/, not for a /parameter/ /mode/.


GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

More information about the fpc-devel mailing list