3 ms·

C++ lambdas do not use the heap. As I wrote, they are stack allocated.

by klmr 8y ago

chrisseaton 8y ago
You're talking about undefined behaviour - this is a badly broken feature of C++ because it does not move the local variable it references onto the heap or some other alternate data structure. Look up the upwards funarg problem. > The upwards funarg problem arises when the calling function refers to the called/exited function's state after that function has returned. Therefore, the stack frame containing the called function's state variables must not be deallocated when the function returns, violating the stack-based function call paradigm. C++ violates the constraint we're talking about.
- klmr 8y ago
  No, I’m not talking about UB. Although you’re right that if you use references rather than copies and return a lambda then, yes, you’ll run into UB. The solution to this is to use copies, as mentioned. > Look up the upwards funarg problem. I’m well aware of upward funargs and what I’ve described specifically implements upward funargs in C++. See https://godbolt.org/z/KZiBNB https://godbolt.org/z/KZiBNB. Note that this code does not perform any heap allocation, and the closed-over variable `i` is saved from the local scope and made available to the caller via the lambda.
  - chrisseaton 8y ago
    > Although you’re right that if you use references rather than copies and return a lambda then, yes, you’ll run into UB. The solution to this is to use copies, as mentioned. That was the context I thought we were having the conversation in - capturing local variables. I'd describe what you mean as capturing local values. If you're copying the value from a variable then you're not capturing the variable. I can see why you're arguing it your way now.
- kccqzy 8y ago
  > it does not move the local variable it references onto the heap C++ doesn't do such thing automatically, but there's nothing preventing you to do it yourself. If you intend to use a local variable whose lifetime would not normally outlast the closure, feel free to use std::move and a move constructor. In general C++ gives you the tools to manage memory manually or semi-automatically, but not totally automatically. And it also doesn't, unlike Rust, force you to use memory correctly.

C++ lambdas do not use the heap. As I wrote, they are stack allocated.

by klmr 8y ago

C++ lambdas do not use the heap. As I wrote, they are stack allocated.

You're talking about undefined behaviour - this is a badly broken feature of C++ because it does not move the local variable it references onto the heap or some other alternate data structure. Look up the upwards funarg problem. > The upwards funarg problem arises when the calling function refers to the called/exited function's state after that function has returned. Therefore, the stack frame containing the called function's state variables must not be deallocated when the function returns, violating the stack-based function call paradigm. C++ violates the constraint we're talking about.

klmr 8y ago
No, I’m not talking about UB. Although you’re right that if you use references rather than copies and return a lambda then, yes, you’ll run into UB. The solution to this is to use copies, as mentioned. > Look up the upwards funarg problem. I’m well aware of upward funargs and what I’ve described specifically implements upward funargs in C++. See https://godbolt.org/z/KZiBNB https://godbolt.org/z/KZiBNB. Note that this code does not perform any heap allocation, and the closed-over variable `i` is saved from the local scope and made available to the caller via the lambda.
- chrisseaton 8y ago
  > Although you’re right that if you use references rather than copies and return a lambda then, yes, you’ll run into UB. The solution to this is to use copies, as mentioned. That was the context I thought we were having the conversation in - capturing local variables. I'd describe what you mean as capturing local values. If you're copying the value from a variable then you're not capturing the variable. I can see why you're arguing it your way now.
kccqzy 8y ago
> it does not move the local variable it references onto the heap C++ doesn't do such thing automatically, but there's nothing preventing you to do it yourself. If you intend to use a local variable whose lifetime would not normally outlast the closure, feel free to use std::move and a move constructor. In general C++ gives you the tools to manage memory manually or semi-automatically, but not totally automatically. And it also doesn't, unlike Rust, force you to use memory correctly.