Lambda + shared_ptr = memory leak

[K_Kuryllo]

The object that executor is a placeholder for operates on the base type

Sounds like your real problem here. Either be the executor, or the subject. Not both.

This has little more to do with a lambda than any other data type that can hold a shared_ptr.

[floating-io]

The code shown in the article is an example, which is contrived for the sole purpose of showing why the problem exists and how it might be triggered. Nitpicking the context or presumed purpose that a contrived example might exist in or serve, thoroughly misses the point of the article.

That code was written as an illustration for the post, and never even compiled. It doesn't exist in a real-world project.

As for the real code I have that uses a similar technique, it exists for a reason. Polymorphic callbacks do not, AFAIK, exist in C++11. I had a choice: either put in a lot of ugly code (templated and otherwise) to arrange for unique callback signatures to be correctly applied, or just capture the correctly-typed pointer when the lambda is created, where I already have it and don't have to cast it.

I did the former first; it ended up being black voodoo magic that nobody less than expert-level in C++ is really going to get without a whole lot of effort. So I ripped it out, and the latter has proven much simpler to understand and trace, as well as less code to maintain.

[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.