>>39
It depends if you bind by reference or if you're binding pointers to objects.
If an object is allocated on the stack, and you bind a pointer to that object within a closure, which you then copy into the heap, once the stack object goes out of scope, it is destructed and deallocated and you have a dangling pointer in the closure.
You still need to be aware of the life times of various objects, and you need to ensure that objects bound by reference or the objects referred to by pointers remain valid for the duration of the closure's lifetime.
If you use smart pointers to objects allocated on the heap, you won't run into any problems. Unfortunately, reference-counted smart pointers have their own performance problems if you use them at to fine of a granularity.
On the other hand, if the closure is only used during the lifetime of a stack allocated object by executing the lambda, then you don't need to worry.
It's a lot to think about perhaps, but it first nature stuff for us experts. We don't even need to think about it, our idioms and ``muscle memory'' are conditioned to work around these nuances and also exploit them for maximum efficiency during execution.
But if you can't deal with it, that's why the invented garbage collection: for all of you babies who will never be
EXPERT PROGRAMMERS!