Date: Fri, 14 Apr 2023 19:22:28 +0000
On Friday, April 14th, 2023 at 6:18 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> void Some_Library_Func(void (*const pf)(void))
> {
> pf();
> }
>
> [...]
> We will define a simple POD struct to hold these two pieces of data:
>
> struct LambdaInfo {
> void *data, code;
> };
>
I see C callback APIs that split a context pointer
to an extra parameter very often:
void some_api(void cb(int), void *user_data);
And there is a paper trying to simplify that:
void some_api(void cb(int) _Wide);
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2862.pdf
I'm not sure whether it is worth the effort to
please the old APIs that don't support context by
pushing the solution to the next level.
>
> void Some_Library_Func(void (*const pf)(void))
> {
> pf();
> }
>
> [...]
> We will define a simple POD struct to hold these two pieces of data:
>
> struct LambdaInfo {
> void *data, code;
> };
>
I see C callback APIs that split a context pointer
to an extra parameter very often:
void some_api(void cb(int), void *user_data);
And there is a paper trying to simplify that:
void some_api(void cb(int) _Wide);
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2862.pdf
I'm not sure whether it is worth the effort to
please the old APIs that don't support context by
pushing the solution to the next level.
-- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________
Received on 2023-04-14 19:22:33