Hacker News Reader

Comment by _hardwaregeek | Hacker News Reader

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.

View on HN

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/BlocksR...

Behind the scenes it implements reference counting though.

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.

> 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?

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.

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.

You can copy the pointers, but that doesn't make it safe because you could have pointers to stack values.

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.

The problem is returning a closure that points to a stack variable that's now out of scope.

It isn't. The hypothetical problem was setting a pointer to a stack variable. That's a no-no from the start, and adding hypothetical closures to the mix changes nothing.

Having a pointer to a stack variable is fine, as long as the stack variable lives longer than the closure.

Right, so your original claim about properly cleaning up is not the only problem with closures in C. There are quite a few hazards actually.

> Right, so your original claim about properly cleaning up is not the only problem with closures in C.

Your comment makes no sense. OP stated that your hypothetical problem isn't even a problem if the developer knows what he is doing, and your take from that is that there are more problems?

The original poster said the trouble was cleaning up after the closure is no longer needed. That's clearly not the case as this thread has covered. I thought the previous poster was the original poster, so just replace "your original claim" with "the original claim".

It's C. I assume the programmer would just be responsible for dealing with dangling pointers and double frees.

... and there's ample evidence that this is a reasonable assumption, so let's do closures based on it, too! :)

> ... and there's ample evidence that this is a reasonable assumption

Actually, there is. C might be a colossal footgun but reasonably experienced developers do manage to avoid those problems.

I'd like to see that ample evidence. On the contrary, I know even fairly experienced developers who get burned with memory issues in C - and I have never ever heard of even the most junior developer to have any problem with double frees in Java :)

Plus..... even if you could do that, WHY? C is a simple language, close to the "metal". If you want a language that has every-feature-and-their-mother, and can be close to the metal when needed, and can be used to blow both your feet off, just use C++.

Adding functional closures to C is somewhat akin to adding "asm" and "volatile" in Haskell.... even if you could do it, why would you? It just breaks the very essence of the language.

Well, that's what C++ lambdas do. Though C++ has smart pointers to help with lifetime issues.

> Sure, unless your value objects contain references.

As others have already pointed out, C does not have references. It does however have pointers, and pointers are already copied by value.

> Then you’re looking at a deep copy

There is no such thing in standard C. Objects are copied by value, including pointers, and if you want to "deep copy" your custom data structures then you need to implement your custom cloning routines. However, naturally your custom cloning functions wouldn't be used directly to capture any variable.

> which can be expensive and/or very application-specific.

That's hardly specific to C.

> It’s hard to do copy by value generically.

Actually, it isn't. In fact with C it's quite trivial, and perhaps as trivial as it gets. There's no garbage collection thingy, no RAII, no deep copies, no refcounting... nothing. Just plain memcpy() from one object to another. That's it.

if that meets the semantics of what you’re trying to do, great. but often in programming it’s not. the depth of the copy you want depends on what you’re trying to do. copying pointers (or references, or whatever might point to dynamically allocated memory) by value means using a garbage collector or reference counting mechanism, or risk a memory leak.

It's C.

If you think being specific about what you want copied, freeing only when you know it's appropriate, and tracking any metadata around that yourself if a problem, don't work in C.

Get it right or risk a memory leak is the name of the game.

It’s your program. The suggestion was that copy-everything-by-value solves the closure/memory issue with respect to copies. It does not. This is also why C doesn’t have closures. Ships passing in the night...

> It’s your program.

No, it's the C programming language. It has been like that since the 70s, and lots of people have been using it to develop high availability software for decades.

Just because some people never learned its basics nor are familiar with the subject that doesn't mean they have a point.

> The suggestion was that copy-everything-by-value solves the closure/memory issue with respect to copies.

No, that's quite wrong. The suggestion was thay passing objects by value would enable capturing variables without any of the slippery slope nonsense that was pointed out.

> This is also why C doesn’t have closures.

No, that's quite wrong as well. C doesn't have closures because no one bothered to add them, which is the exact same reason why C doesn't have namespaces or generics or any other feature ever. That's it.

C has generics (within the limitations of its type system) since C11.

https://en.cppreference.com/w/c/language/generic

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?

C does not have `auto`, so you couldn't store closures in local variables.

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

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.

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

It's a language extension, not standard C.

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.

Yes: classes.

Every closure is an anonymous class in C++.

Sorta, yeah... but you can get better than nothing:

https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

Reply on news.ycombinator.com