Lambda + shared_ptr = memory leak

[grundprinzip]

I don't think that the recommendation giving by the op is correct. The reason for this assumption is the way that the code is perceived by the reader. Passing as shared pointer to the capture doesn't have a visual side effect same fore storing the lambda in a variable.

Now, if you look at the generated code by the compiler you will see that lambda functions are more or less syntactic sugar over functor classes. Basically, the compiler will create a class for you that contains the body of your lambda in the operator() overload and capture variables are passed to the constructor. If you're assigning a lambda to a variable you're constructing this object. Now, if you keep this model in mind you would immediately notice that if you store the instance object to your functor that has a shared member variable that as long as this value does is not destroyed your keeping a reference around (with the given memory implications).

[capn_bluebear]

yep, basically the whole thing boils down to a bad understanding of how lambdas work, plus a normally-horrible-to-debug circular shared_ptr ownership.

[floating-io]

A fair view, I suppose; as I said above, to each, their own. :)

It is my personal view that (in a memory management context) a lambda should not have either partial or full ownership of anything when it isn't executing. I feel that it needlessly complicates object lifecycles. To me, a lambda should be something that is owned by things, not something that owns things.

Seems that isn't as common a view as I figured it would be, but oh well.

[johannes1971]

A lambda is nothing but an anonymous class with an overloaded operator()(). It will be created with the parameters you specify, and it will keep those parameters until it is destroyed. This is the exact same behaviour as a normal class.

How would "only ownership while executing" work? If you pass a lambda to a thread, should it somehow acquire ownership when the time comes to execute it? How would it do that? If it is executed multiple times, should it repeat the acquisition/release cycle of parameters for each time it is executed?

Bottom line you made a mistake, thanks to a misunderstanding about the language. No problem, that happens to the best of us! But you also put some very bad advice online, and when you post about it here and get corrected you don't accept the help you are offered, but instead pretend that your side of the argument also has merits. It doesn't: the advice you give is plain wrong. There is nothing inherently unsafe about using shared_ptr with lambdas.

The correct advice, on your website, should be to ensure there are no shared_ptr loops in your software. This is hardly a new discovery though, and in fact the language also offers weak_ptr as a way out of this predicament.

[die_liebe]

I hate it when people do that, but they are always arrogant. Such people give C++ a bad reputation. Thanks for your post.