> Heap-allocated trampolines have an obvious deallocation problem; it would be interesting to see what strategy is used for that.

With -ftrampoline-impl=heap, GCC automatically insert[1] pairs of constructor/destructor routines from libgcc which were built around mmap/munmap.

[1] https://godbolt.org/z/7s5nooMPz

>This uses a static variable to have it persist between both the compare function calls that qsort makes and the main call which (potentially) changes its value to be 1 instead of 0

The only misleading thing here is that ‘static’ is monospaced in the article (this can’t be seen on HN). Other than that, ‘static variable’ can plausibly refer to an object with a static storage duration, which is what the C standard would call it.

>moving the variable from the stack to the "global data" which is generally heap-allocated as the program loads

It is not heap-allocated because you can’t free() it. Non-zero static data is not even anonymously mapped, it is file-backed with copy-on-write.

I had a completely different response reading the sentence. I've been programming in C for 20+ years and am very familiar with exactly the problem the author is discussing. When they referred to a "static variable", I understood immediately that they meant a file static variable private to the translation unit. Didn't feel contrived or made up to me at all; just a reflection of the author's expertise. Precision of language.

I'm finding myself in a weird position now, because I disagree with a whole lot of things in the blog post (well, the parts I was willing to read anyways), but calling that variable static for the sake of persistence was correct.

The fact that you are questioning the use of the term shows that you are not familiar with the ISO C standard. What the author alludes to is static storage duration. And whether or not you use the "static" keyword in that declaration (also definition), the storage duration of the object remains "static". People mostly call those things "global variables", but the proper standardese is "static storage duration". In that sense, the author was right to use "static" for the lifetime of the object.

EDIT: if you drop "static" from that declaration, what changes is the linkage of the identifier (from internal to external).

The author contributes to ISO C and ISO C++ working groups, and his latest contribution was #embed.

It took me a second read to realise that the mention of static is a red herring. I think the author knows that the linkage is irrelevant for the rest of the explanation; it just happens to be static so they called it static. But by drawing attention to it, it does first read like they're confused about the role of static there.

That's a very weird comment, your spreading your knowledge and not really addresse what could have been changed in the article.

If I follow your comment, you mean that he could have use a non-static global variable instead and avoid mentioning "static" keyword afterward?

Even if you never copy the std::function the overhead is very large. GCC (14 at least) does not seem to be able to elide the allocation, nor inline the function itself, even if used immediately after use and the object never escapes the function. Given the opportunity, GCC seems to be able to completely remove one layer pf function_ref, but fails at two layers.

From the introduction, your paper seems like a counterproposal: support closures, just not the way others propose. But the paper seems to accept that closures / nested functions, supported at the language level directly, are a "good thing" for C specifically. I disagree with that. When and how has it become the consensus?

Yes, though it was a remarkably brief mention. I believe Borland tried to standardise it back in 2002 or so,* along with properties. (I was the C++Builder PM, but a decade and a half after that attempt.)

C++Builder’s entire UI system is built around __closure and it is remarkably efficient: effectively, a very neat fat pointer of object instance and method.

[*] Edit: two dates on the paper, but “bound pointer to member” and they note the connection to events too: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n13...

Would this be similar to how Rust handles async? The compiler creates a state machine representing every await point and in-scope variables at that point. Resuming the function passes that state machine into another function that matches on the state and continues the async function, returning either another state or a final value.

> a "state" keyword for declaring variables in a "stateful" function

Raku (née Perl 6) has this! https://docs.raku.org/language/variables#The_state_declarato...

I dreamed up a similar idea[1] upon reading the author's closure proposal, it's also really close to async coroutines.

[1] https://github.com/ThePhD/future_cxx/issues/55#issuecomment-...

That sounds cool, but this quickly gets complicated. Some aspects that need to be addressed:

- where does the automatically defined struct live? Data segment might work for static, but doesn't allow dynamic use. Stack will be garbage if closure outlives function context (ie. callback, future). Heap might work, but how do you prevent leaks without C++/Rust RAII?

- while a function pointer may be copied or moved, the state area probably cannot. It may contain pointers to stack object or point into itself (think Rust's pinning)

- you already mention recursion, compilation

- ...

> 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

It doesn't even make sense to use strchr for determining the position of 'r', when the code checks that the position of '-' is at index 0.

Your solution is perfectly fine. Even if you don't have access to strchr for some reason, the original snippet is really convoluted.

You could just write (strlen(argv[1]) > 1 && argv[1][0] == '-' && argv[1][0] == 'r') if you really want to.

Not to mention the potential signed integer overflow in (*right - *left) and (*left - *right), which is undefined behavior. And even if you rely on common two's complement wraparound, the result may be wrong; for example, (INT_MAX-(-1)) should mathematically yield a positive value, but the function will produce INT_MIN, which is negative.

And then we have this "modern" way of spelling pointers, "const int* right" (note the space). In C, declaration syntax mirrors use, so it should be "const int *right", because "*right" is a "const int".

I feel too old for this shit. :(

I suspect it was adopted from a bigger snippet that had support for parsing things like "-abc" as "-a -b -c", etc.

Isn't this basically the same as passing the function to std::bind_front and storing it in a std::function or std::function_ref?

That's all there is to it. I don't understand the whole obsession with closures.

I've used lambdas extensively in modern C++. I hate them with a passion.

I've also used OCaml. An awesome language where this stuff is super natural and beautiful.

I don't understand why people want to shoehorn functional programming into C. C++ was terrible already, and is now worse for it.

> we’re going to be focusing on and looking specifically at Closures in C and C++, since this is going to be about trying to work with and – eventually – standardize something for ISO C that works for everyone.

Sigh. My heart sinks.

Yeah, Rust closures that capture data are fat pointers { fn*, data* }, so you need an awkward dance to make them thin pointers for C.

    let mut state = 1;
    let mut fat_closure = || state += 1;
    let (fnptr, userdata) = make_trampoline(&mut &mut fat_closure);

    unsafe {
        fnptr(userdata);
    }

    assert_eq!(state, 2);

    use std::ffi::c_void;
    fn make_trampoline<C: FnMut()>(closure: &mut &mut C) -> (unsafe fn(*mut c_void), *mut c_void) {
        let fnptr = |userdata: *mut c_void| {
            let closure: *mut &mut C = userdata.cast();
            (unsafe { &mut *closure })()
        };
        (fnptr, closure as *mut _ as *mut c_void)
    }
    

In Rust, could you instead use a templated struct wrapping a function pointer along with #[repr(C)]?

Yep. Thread locals are probably faster than the other solutions shown too.

It’s confusing to me that thread locals are “not the best idea outside small snippets” meanwhile the top solution is templating on recursion depth with a constexpr limit of 11.

reentrancy.

Given a Sufficiently Good™ compiler, yes, after devirtualization and heap elision all variants should generate exactly the same code. In practice is more complicated. Devirtualization needs to runs after (potentially interprocedural) constant propagation, which might be too late to take advantage of other optimization opportunities, unless the compiler keeps rerunning the optimization pipeline.

In a simple test I see that GCC14 has no problems completely removing the overhead of std::function_ref, but plain std::function is a huge mess.

Eventually we will get there [1], but in the meantime I prefer not to rely on devirtualization, and heap elision is more of a party trick.

edit: to compare early vs late inlining: while gcc 14 can remove one layer of function_ref, it seems that it cannot remove two layers, as apparently doesn't rerun the required passes to take advantage of the new opportunity. It has no problem of course removing an arbitrary large (but finite) layers of plain lambdas.

edit2: GCC15 can remove trivial uses of std::function, but this is very fragile. It still can't remove two function_ref.

[1] for example 25 years ago compilers were terrible at removing abstraction overhead of the STL, today there is very little cost.

This.