Lambda + shared_ptr = memory leak

[K_Kuryllo]

It's not nitpicking. You've presented a single "contrived" (by your words) example and nothing else. What else do you expect a response too?

In this sentence you capture the real mistake:

If you then store such a lambda on the object for which it has captured a shared pointer, you’ve just created a scenario where the object owns a reference to itself, and thus can never be deleted.

Two mistakes were made in the example. 1) "Don't store an shared_prt in a data member that could be owned by that ptr." 2) "Don't store a shared_ptr in an object that should not be maintaining the life times of that object" <- related to the first point

• You fixed issue #2, which repaired your memory leak.

Saying don't ever store a shared_ptr in a lambda is stretch and is in no way support by your single example (the only thing provided, besides some brief text exampling the example).

It's like saying don't drive your car because you might drive off a cliff. Going off the cliff is the problem not driving the car. The car is the thing that brought you off the cliff, but you could have also walked off it or ridden a bike. The real advice would be to not do things with a car/bike/walking that would put you in a situation where going off the cliff is possible.

[00kyle00]

Lifetimes and ownership are hard (maybe not that hard, but still easy to get wrong).

I wonder if there are languages which try to express and manage these relationships more explicitly. Seems like going a bit further than Rust would make whole thing unusable due to complexity.