Abstract:

This Hacker News discussion focuses on the implementation and performance costs of achieving "closures" (functions with captured state) in C and C++. The consensus among commenters is that modern C++ lambdas excel due to compile-time optimization, acting as flattened structs. Conversely, type-erased containers like std::function suffer massive, persistent performance penalties because contemporary compilers (specifically GCC/libstdc++) frequently fail to perform expected optimizations (like allocation elision or inlining). The thread also addresses fundamental issues in C, correcting a critical misunderstanding about the static keyword's scope and advocating strongly for the standardization of an efficient, first-class "wide function pointer" or "stateful function" primitive in C to bypass non-portable or expensive extensions.

The Cost of a Closure in C: A Critical Discussion of Implementation and Optimization

• (hyperbolablabla) Mentions an existing custom C++ Function abstraction that aims for explicit and clean capture mechanics, avoiding the complexity and implicit type-erasure issues of standard C++ lambdas.
• (unwind, kritisch) Corrects a basic error in the article: when used at the global scope, the static keyword in C only limits visibility to the translation unit (source file). It does not ensure persistence; persistence is inherent to global scope. The persistence function of static is only relevant when used within a local function scope.
• (Rochus, Performance Analysis) Argues that modern C++ Lambdas win because the compiler sees the entire definition, allowing the closure structure to be flattened into a "compile-time calculated static link," enabling direct member access.
• (Rochus) Highlights the substantial performance gap between std::function (the owning container) and std::function_ref (the non-owning view). std::function triggers exponential overhead in recursive benchmarks (like Man-or-Boy) due to repeated copying and potential heap allocation, confirming the implementation failure of standard library types for high performance.
• (gpderetta) Critiques compiler optimization failure: GCC (14/15) often fails to elide heap allocation or properly inline std::function, even for trivial, stateless lambdas, making the overhead large and fragilely dependent on the compiler's optimization passes. As far as I can tell, relying on devirtualization for performance here is reckless.
• (nutjob2) Rejects the approach of using GNU nested (local) functions in C, as they require an inefficient and non-portable "executable stack with 'trampolines'," preferring alternative display mechanisms or explicit context management.
• (RossBencina & vintagedave) Advocates for a standardized C closure story, suggesting a state keyword that automatically bundles state variables into a defined struct. This mirrors Borland's highly efficient __closure extension, which acts as a neat fat pointer (object instance + method).
• (pornel) Explains the mechanics in Rust: captured closures are inherently "fat pointers" (fn*, data*). To interface with C, one must perform an explicit (and somewhat unsafe) trampoline technique, passing the state as a separate userdata pointer. This approach, however, is zero-cost if inlined.
• (Progge et al.) Finds the command-line argument parsing in the article's introductory C snippet unnecessarily convoluted, suggesting simple comparison checks or standard tools like getopt() should have been used. I don't care how the original author parses arguments, but the style appears unnecessarily complex.