5 ms·

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

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.
      - geezerjay 8y ago
        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.
        samnardoni 8y ago
        Having a pointer to a stack variable is fine, as long as the stack variable lives longer than the closure.
        naasking 8y ago
        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.
        geezerjay 8y ago
        > 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?
        naasking 8y ago
        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".
withoutboats 8y ago
It's C. I assume the programmer would just be responsible for dealing with dangling pointers and double frees.
- virgilp 8y ago
  ... and there's ample evidence that this is a reasonable assumption, so let's do closures based on it, too! :)
  - bonzini 8y ago
    Well, that's what C++ lambdas do. Though C++ has smart pointers to help with lifetime issues.
  - geezerjay 8y ago
    > ... 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.
    - virgilp 8y ago
      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.
geezerjay 8y ago
> 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.
- cobbzilla 8y ago
  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.
  - kjeetgill 8y ago
    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.
    - cobbzilla 8y ago
      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...
      - 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.
    - geezerjay 8y ago
      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.
      - samnardoni 8y ago
        Having a pointer to a stack variable is fine, as long as the stack variable lives longer than the closure.
        naasking 8y ago
        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.
        geezerjay 8y ago
        > 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?
        naasking 8y ago
        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".

withoutboats 8y ago

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

virgilp 8y ago
... and there's ample evidence that this is a reasonable assumption, so let's do closures based on it, too! :)
- bonzini 8y ago
  Well, that's what C++ lambdas do. Though C++ has smart pointers to help with lifetime issues.
- geezerjay 8y ago
  > ... 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.
  - virgilp 8y ago
    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.

geezerjay 8y ago

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

cobbzilla 8y ago
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.
- kjeetgill 8y ago
  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.
  - cobbzilla 8y ago
    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...
    - 8y ago