Hairy Pixels <generic...@gmail.com> schrieb am Sa., 4. Nov. 2023, 15:48:

>
>
> > On Nov 4, 2023, at 4:22 PM, Sven Barth <pascaldra...@googlemail.com>
> wrote:
> >
> > Then don't assign them every "frame". If you just keep them around then
> they aren't more expensive than a virtual method call.
> > And any other mechanism would involve the heap as well, because that's
> how anonymous functions that capture variables work and thus anything that
> wants to store them must play by the same rules. There won't be any changes
> there.
> >
>
> The need for a universal function pointer type really isn't about the
> function references even though they work for that, albeit with unneeded
> overhead.
>
> Lets say you have a sort function which takes a compare callback
> parameter. You can make the callback type "is nested" which works on global
> and nested/anonymous functions but not methods. What if the user wants to
> provide the compare function as a method because they're calling it in a
> class which shares the code elsewhere? As the writer of the function you'd
> need to make 2 versions of the function, one "is nested" and "of object".
>
> The writer of the sort function shouldn't need to know what kind of
> function it will be passed, just that a comparison callback is provided,
> right?
>

Then you simply make the callback function type a function reference and be
done. The user can pass in any kind of function they want and *nearly*
every type of function-like pointer.

And if you're really worried about performance when providing such a class
then simply provide overloads woth different function-like pointer types,
the compiler will pick the most suitable one then.

It's really not that hard as an implementer of a class.

Regards,
Sven

>
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to