I agree, that it can be a big deal and one must think about ownership and lifetimes whereas in Javascript there is no need to. Especially in code that will exit the surrounding function before the callback is executed, I do not use &, and explicitly specify the captured variables so I can think about what type of capture.
However, C++ is improving in this regard. I think lambda capture initializers with C++14 help in this regard so that unique_ptr can be used. In addition, the memory safety tooling is improving - see Herb Sutter's CppCon 2015 keynote. Finally, C++17 should have co-routines which will make this type of callback code less used and allow one to use "normal" logic without callbacks that will also be non-blocking.
> I think lambda capture initializers with C++14 help in this regard so that unique_ptr can be used.
They're still opt-in—the burden is on the programmer to get it right.
> In addition, the memory safety tooling is improving - see Herb Sutter's CppCon 2015 keynote.
Sure. But it's not here yet, it requires a lot of annotations, and there are several key unanswered questions that I didn't see an answer to (how the static analysis deals with pointers derived from shared_ptr when it relies on all pointer function parameters being unaliased, for example).
> Finally, C++17 should have co-routines which will make this type of callback code less used and allow one to use "normal" logic without callbacks that will also be non-blocking.
And when the coroutines suspend/yield, you have the exact same issues regarding dangling pointers and use-after-free.
However, C++ is improving in this regard. I think lambda capture initializers with C++14 help in this regard so that unique_ptr can be used. In addition, the memory safety tooling is improving - see Herb Sutter's CppCon 2015 keynote. Finally, C++17 should have co-routines which will make this type of callback code less used and allow one to use "normal" logic without callbacks that will also be non-blocking.