6 ms·

I always find it funny when people propose adding closures to C. Because the moment you add closures (in the way most languages implement them, not Rust's imple

I always find it funny when people propose adding closures to C. Because the moment you add closures (in the way most languages implement them, not Rust's implementation), you're adding automatic boxing, which implies garbage collection and a runtime. Which basically means you've added objects. Which...sure you could do, but at that point, you're not adding to C, you're just making a new language.

saghm 8y ago
Would it be possible to add C++'s implementation to C, or does it rely on other C++ features that C doesn't already support?
- whyever 8y ago
  C does not have `auto`, so you couldn't store closures in local variables.
  - v_lisivka 8y ago
    In C, you can use typeof(). #define max(a,b) \ ({ typeof (a) _a = (a); \ typeof (b) _b = (b); \ _a > _b ? _a : _b; }) https://gcc.gnu.org/onlinedocs/gcc/Typeof.html https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
    - wahern 8y ago
      typeof is supported by everything[1] except the C standard. It was rejected in the 1990s and nobody on the committee seems to want to revisit the decision. To be fair, typeof is not as useful without statement expressions (`({ ... })`), and statement expressions aren't as widely supported. [1] All the major compilers support it (clang, GCC, IBM, Intel, Microsoft, Solaris, etc), plus or minus underscores in the identifier.
  - Longhanks 8y ago
    You’re not wrong, but C has __auto_type (at least GCC and clang support it, no idea about MSVC): https://gcc.gnu.org/onlinedocs/gcc/Typeof.html https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
    - int_19h 8y ago
      It's a language extension, not standard C.
- aaaaaaaaaab 8y ago
  Yes: classes. Every closure is an anonymous class in C++.
- calebh 8y ago
  C++ closures are a bit weird in that you have to specify how the captured data needs to be captured (either by reference or by copy). How the data is handled also depends on the implementation of std::function (if you decide to wrap your lambdas in that). It's possible that the implementation for std::function actually makes a reference-counted heap allocation every time a new closure is created. Anyway, the result is a lot of complexity that would be impossible to shoe-horn into C.
pavlov 8y ago
Apple’s block extensions added a closure syntax to C. The runtime’s public API is very small: https://github.com/mackyle/blocksruntime/blob/master/BlocksRuntime/Block.h https://github.com/mackyle/blocksruntime/blob/master/BlocksR... Behind the scenes it implements reference counting though.
- mikeash 8y ago
  Should be able to do it without refcounting if you wanted to go even more minimal, too. Make a call to copy the storage, and another one to destroy it. Then the user can use whatever lifetime management they already use for other things.
geezerjay 8y ago
> Because the moment you add closures (in the way most languages implement them, not Rust's implementation), you're adding automatic boxing, which implies garbage collection and a runtime. Isn't it possible to avoid the whole slippery slope by capturing objects by value?
- cobbzilla 8y ago
  Sure, unless your value objects contain references. Then you’re looking at a deep copy, which can be expensive and/or very application-specific. It’s hard to do copy by value generically.
  - yorwba 8y ago
    References in C are implemented by pointers, which can be copied very easily. The trouble is with properly cleaning up when the closure isn't needed anymore, but that problem already exists when you copy pointers explicitly.
    - naasking 8y ago
      You can copy the pointers, but that doesn't make it safe because you could have pointers to stack values.
      - geezerjay 8y ago
        I don't see how that's relevant. If a developer sets a pointer to point to a stack object then copying the pointer, whether manually or through a hypothetical closure, doesn't change nor create the problem.
        naasking 8y ago
        The problem is returning a closure that points to a stack variable that's now out of scope.
mehrdadn 8y ago
Sorta, yeah... but you can get better than nothing: https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
deleted 8y ago
[deleted]

saghm 8y ago

Would it be possible to add C++'s implementation to C, or does it rely on other C++ features that C doesn't already support?

whyever 8y ago
C does not have `auto`, so you couldn't store closures in local variables.
- v_lisivka 8y ago
  In C, you can use typeof(). #define max(a,b) \ ({ typeof (a) _a = (a); \ typeof (b) _b = (b); \ _a > _b ? _a : _b; }) https://gcc.gnu.org/onlinedocs/gcc/Typeof.html https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
  - wahern 8y ago
    typeof is supported by everything[1] except the C standard. It was rejected in the 1990s and nobody on the committee seems to want to revisit the decision. To be fair, typeof is not as useful without statement expressions (`({ ... })`), and statement expressions aren't as widely supported. [1] All the major compilers support it (clang, GCC, IBM, Intel, Microsoft, Solaris, etc), plus or minus underscores in the identifier.
- Longhanks 8y ago
  You’re not wrong, but C has __auto_type (at least GCC and clang support it, no idea about MSVC): https://gcc.gnu.org/onlinedocs/gcc/Typeof.html https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
  - int_19h 8y ago
    It's a language extension, not standard C.
aaaaaaaaaab 8y ago
Yes: classes. Every closure is an anonymous class in C++.
calebh 8y ago
C++ closures are a bit weird in that you have to specify how the captured data needs to be captured (either by reference or by copy). How the data is handled also depends on the implementation of std::function (if you decide to wrap your lambdas in that). It's possible that the implementation for std::function actually makes a reference-counted heap allocation every time a new closure is created. Anyway, the result is a lot of complexity that would be impossible to shoe-horn into C.

pavlov 8y ago

Apple’s block extensions added a closure syntax to C. The runtime’s public API is very small: https://github.com/mackyle/blocksruntime/blob/master/BlocksRuntime/Block.h https://github.com/mackyle/blocksruntime/blob/master/BlocksR... Behind the scenes it implements reference counting though.

mikeash 8y ago
Should be able to do it without refcounting if you wanted to go even more minimal, too. Make a call to copy the storage, and another one to destroy it. Then the user can use whatever lifetime management they already use for other things.

geezerjay 8y ago

> Because the moment you add closures (in the way most languages implement them, not Rust's implementation), you're adding automatic boxing, which implies garbage collection and a runtime. Isn't it possible to avoid the whole slippery slope by capturing objects by value?

cobbzilla 8y ago
Sure, unless your value objects contain references. Then you’re looking at a deep copy, which can be expensive and/or very application-specific. It’s hard to do copy by value generically.
- yorwba 8y ago
  References in C are implemented by pointers, which can be copied very easily. The trouble is with properly cleaning up when the closure isn't needed anymore, but that problem already exists when you copy pointers explicitly.
  - naasking 8y ago
    You can copy the pointers, but that doesn't make it safe because you could have pointers to stack values.
    - geezerjay 8y ago
      I don't see how that's relevant. If a developer sets a pointer to point to a stack object then copying the pointer, whether manually or through a hypothetical closure, doesn't change nor create the problem.
      - naasking 8y ago
        The problem is returning a closure that points to a stack variable that's now out of scope.

mehrdadn 8y ago

Sorta, yeah... but you can get better than nothing: https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

deleted 8y ago

[deleted]