<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Michael Van Canneyt <<a href="mailto:michael@freepascal.org">michael@freepascal.org</a>> schrieb am Mo., 20. Juni 2022, 08:04:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Mon, 20 Jun 2022, Sven Barth via fpc-pascal wrote:<br>
<br>
> Am 20.06.2022 um 03:37 schrieb Hairy Pixels:<br>
>><br>
>>> On Jun 19, 2022, at 10:04 PM, Sven Barth <<a href="mailto:pascaldragon@googlemail.com" target="_blank" rel="noreferrer">pascaldragon@googlemail.com</a>> <br>
> wrote:<br>
>>><br>
>>> As you can see the allocation only happens once and not all the time.<br>
>>> What might be worse however is the optimization behavior as in this <br>
> example the compiler wouldn't optimize the counter variable into a regvar <br>
> with enabled optimizations (however in case of a nested function the compiler <br>
> wouldn't do this either if the function isn't inlined).<br>
>>><br>
>><br>
>> I’m saying if the OUTER method is in a tight loop (Foo in this example) <br>
> you’re in trouble because it now contains an allocation which is unexpected.<br>
><br>
> In that case we're in the same territory as always: ensure that you know <br>
> what your code does. It's the same reason why adding character by <br>
> character to a managed String is slower then allocating the string once <br>
> and then setting the characters. And I think it's very seldom that <br>
> someone uses a function reference that does not leave the scope of the <br>
> surrounding function.<br>
<br>
Does this not depend on the callback declaration ?<br>
<br>
Type<br>
   FuncRef = reference to procedure(a : integer);<br>
<br>
Procedure DoSomething(f : FuncRef);<br>
begin<br>
end;<br>
<br>
Procedure UseSomething;<br>
<br>
begin<br>
   For I:=X to SomeLimit do<br>
     DoSomething(Whatever)<br>
end;<br>
<br>
Does the declaration of DoSomething (which uses reference to) not <br>
ensure that an interface is created in UseSomething ?</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, in your example this is the case, but look at mine again: it's unnecessary to create the capture object here and in theory the compiler could convert it to an ordinary nested function variable. </div><div dir="auto">But that 's all theoretical, because right now such an optimization doesn't exist.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I tried to find your original mail, to look for the answer myself, <br>
but I don't find it offhand.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Either in fpc-pascal or fpc-announce from end of May. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It may be a good idea to add the explanation you gave in the announcement <br>
mail to the wiki (and link to it in the user changes in trunk page)</blockquote></div></div><div dir="auto"><br></div><div dir="auto">There won't be a "User Changes Trunk" entry because nothing existing broke with this new feature. </div><div dir="auto">There will however be a "New Features Trunk" entry that will point to the announcement mail. There will be no documentation by me in the wiki. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>