4 ms·

In other words - he discovered gcc's ({ }) construct and decided to write a macros named lambda around it. http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#

• deleted 15y ago
  [deleted]
  • ori_b 15y ago
    You're not passing a compound statement expression as a function pointer. You are passing the result of the evaluation of that expression --which is a function pointer -- as a function pointer.
    • tjr 15y ago
      Oops, sorry, I just deleted my comment because I thought that wingo's comment covered my thoughts and more. For posterity, I had previously written: I do not find it obvious from that documentation that you can pass a compound statement expression as a function pointer. And touche', I just glanced at the contents of the macro before replying.
• wingo 15y ago
  To me it's a bit more surprising: it's a statement expression, containing a nested function, then we take the address of that nested function. Having that series of operations produce something useful is unexpected, to say the least. It's nothing I'd want to see in code that I maintain, but I think you have to give it a bit more credit. Besides that, it's cute :)
  • tjr 15y ago
    Any idea if this is now officially supported in GCC? The blog post is from nearly a year ago.
    • ori_b 15y ago
      It's been officially supported in GCC since about a decade ago, I believe. It's not part of the C language, so if you're writing this code, it's no longer C. It also requires executable stacks.
      • xilun0 15y ago
        why does it requires executable stacks?
        • fmap 15y ago
          Because of the way nested functions are implemented in GCC. If you call a nested function it has to know the frame address of the containing function in order to refer to its local variables. So if you take the address of such a function the program actually receives the address of a "trampoline": a small sequence of instructions which first loads the frame address and then calls the real function. The trampoline itself is generated dynamically and putting it on the stack turns out to be cheaper than heap allocating it.
          • ori_b 15y ago
            > and putting it on the stack turns out to be cheaper than heap allocating it. Well, more so that C has no concept of the heap. That's entirely contained within the C libraries. So, the language implementation itself can't do heap allocations (at least, not without sacrificing any chance of using it in embedded or kernel dev situations where you don't have heap allocation, or where you need to use custom allocators)
            • swdunlop 15y ago
              If you're using closures in an embedded environment with no heap, you've got bigger problems than executable stacks to worry about..
      • xerampelin 15y ago
• apgwoz 15y ago
  Right. And of course the whole idea is prone to insane amounts of fail. > Thus, if you access the enclosing environment, you > must ensure that the lifetime of this lambda is bound by the > lifetime of the enclosing environment (i.e., until the enclosing > function returns). This means that if you access local > variables, bad things will happen. If you don't access local > variables, you're fine. Might as well avoid the complications, hoist the function and pass a function pointer with some context (assuming it's needed).