Comment by sirwhinesalot
1 month ago
I think local functions (like the GNU extension) that behave like C++ byref(&) capturing lambdas makes the most sense for C.
You can call the local functions directly and get the benefits of the specialized code.
There's no way to spell out this function's type, and no way to store it anywhere. This is true of regular functions too!
To pass it around you need to use the type-erased "fat pointer" version.
I don't see how anything else makes sense for C.
For what it's worth, that is the primary feature of the proposal linked in the blog post. It's just not talked about in the post because that post is about... performance!
https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Functio...
That actually goes a bit further than my suggestion, since it allows the closure to be returned with its unique type. I'm not a fan of introducing these "unnamable types" to C since it means the closure producing function cannot be declared in a header.
I do like the trampoline trick in 3.2.4, however, neat alternative to a fat pointer!
> There's no way to spell out this function's type, and no way to store it anywhere. This is true of regular functions too!
well regular functions decay to function pointers. You could have the moral equivalent of std::function_ref (or similarly, borland __closure) in C of course and have closures decay to it.
The price you pay for GCC nested (local) functions is an executable stack with 'trampolines'.
I'm a fan of nested functions but don't think the executable stack hack is worth it, and using a 'display' is a better solution.
See the Dragon Book or Compiler Construction: Principles and Practice (1984) by Louden
You misunderstood my comment. GNU local function syntax, C++ [&] lambda behavior (i.e., a hidden struct).
I really did, my comment is specific to C.
3 replies →
[dead]