> On Nov 8, 2021, at 1:27 PM, Sven Barth via fpc-pascal
> <[email protected]> wrote:
>
> And there you have it (simplified obviously). As long as the compiler can
> determine *at compile time* the code of the function (and the function is
> inlineable) it should in theory be able to inline it. This is true no matter
> if it's a function variable, a method variable (pointing to a non-virtual
> method) or an anonymous function. However if somewhere between passing in the
> function address and calling the function inlining does not work for one
> reason or the other (e.g. due to open array parameters which are currently
> not supported by inlining) then the compiler obviously can't inline the
> provided function either.
Interesting, so the inlining the containing function is the key. I guess if the
container were not inlined it would basically be like a generic where a new
function body would be generated which contained the inline function pointers
body with arguments replaced.
For example:
function Map_MultBy2(aArr: TLongIntArray): TLongIntArray;
begin
SetLength(Result, Length(aArr));
for i := 0 to High(aArr) do
Result[i] := aArr[i] * 2; { MultBy2 is inlined here }
end;
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
