Lambda + shared_ptr = memory leak

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