C++ Weekly - Ep 126 - Lambdas With Destructors

[@superscatboy]

C++ Weekly, 2029: "Concrete types deprecated, everything is a lambda now"

[@vertigo6982]

One can never have too many videos about lambdas. I'm really enjoying every one of them.

[@devluz]

Might come in handy if we ever have a "most ugly C++" competition

[@Ch1n4Sailor]

You are one of the few people I will watch, going back slowly into all of your content! (I’ve been doing C/C++ for 20+ years)

[@applicative_functor]

Lambda, which capture another lambda inline, which have structure declaration and usage. I was struck to the core of my soul by the fact that it is possible at all ! Is it possible to unsee this?! :D Why not add few levels of nesting templates, make them mutable, and mix with SFINAE, type-traits and move-semantics? :D

[@NonTwinBrothers]

I had to find this video again just to convince myself it wasn't a dream

[@goshisanniichi]

I could see it used for timing, something like function profiling. It's not that necessary anymore, but you have the lambda grab a mutex on creation and then release it on destruction, that way you don't have to worry about things like mutexes not being release in the even exceptions and things like that.

[@ukaszdrozdz6200]

This looks like it could have a use in a SCOPE_EXIT{ } implementation.

[@headlibrarian1996]

I like std::unique_ptr with a custom destruction function for that.

[@ukaszdrozdz6200]

std::unique_ptr just for a SCOPE_EXIT? What for? It's just a wasteful heap allocation ;)

[@headlibrarian1996]

Łukasz Drożdż No heap allocation. std::unique_ptr has a two argument constructor: a pointer to manage and a custom deleter function. Pass in nullptr and the function (which ignores the nullptr argument). Voila!

[@rabbitdrink]

if i were to use something like that id most likely just put together a struct with operator() or use a finally object from some utility library

[@YTonYahoo]

What's the difference between defining i in the capture clause and defining it as a local variable within the lambda function body?

[@cppweekly]

This is a great experiment for you to try yourself, but the short answer is that the object in the capture lives for the lifetime of the lambda itself (and can therefor be copied and moved), while the variable lives only for the lifetime of each lambda invocation.

[@emiliadaria]

I am amazed

[@danielrhouck]

Wouldn't a simpler lambda with a destruction be [s=std::string("Hello")](){}?

[@connorhorman]

Daniel Houck Even simpler [s=“Hello”s]{}

[@AxelStrem]

If I ever happen to have a container of mutexes, I'll make sure to use a "destructor lambda" with std::for_each to lock them all :D

[@DusanJovanovicDBJ]

That lambda has no destructor. That struct S has a destructor.

[@pdgiddie]

The destructor is called when the lambda goes out of scope, so 🤷

[@shushens]

I find the name misleading, because the destructor does not destroy the lambda.

[@X_Baron]

I'm puzzled by that struct S being in scope after the outer lambda.

[@alexeiz]

Why do these kind of programming technics remind me Javascript?

[@Ch1n4Sailor]

Nice!!

[@foomoo1088]

Not sure this is really a “destructor” for the lambda … it gets called twice . Also not clear why you’d need it

[@cppweekly]

Destructor is only called once per object. In this example there are two different lambdas created. The original, and a copy. Each must have its destructor called. In this regard lambdas are no different than any other object in C++

[@KobiCohenArazi]

Nice! didn't think about it...

[@zackyezek3760]

Or you can just write a regular, old school functor struct directly and bypass both the unnecessary extra wrapping layers AND the write only lambda code. You can still do things with those that no lambda can, like a recursive calls. And in this case it’d be faster too.

[@cppweekly]

Of course, the point is just to experiment with what is possible.

[@cmdlp4178]

I think it can be useful for debugging and optimizing. When I write functions taking a lambda function as a parameter, I always pass them by value, because in most cases the lambdas just capture a reference to all variables, this should be as fast as copying a pointer, but when other people use the functions, they might capture variables by value, this could help me to improve the code, so that lambdas are not copied all over the place. But do you think it is better to pass lambdas by value, by l-value reference or universal reference when writing functions like in the -header?

[@N00byEdge]

Imo, universal reference, the caller probably knows best what the lambda is doing

[@cmdlp4178]

N00byEdge I think, when you need to write code for yourself fast, you can use pass-by-value, and do not need to type two characters(&&), as long as the lambda just has a reference to all locals. But when others may use it, you should use universal references. However, you should also use std::forward, when the lambda is used once, this could lead to more boilerplate code. On the other hand, when a lambda is called, there is no difference, if it is called as an lvalue or rvalue, but for user-types there may be overloads to operator(), which do the most optimized thing if the callable object is lvalue or rvalue. // this object returns a string-object when called, it could also be a reference, but this directly shows the point struct get_string { std::string str; std::string operator()() const { return str; // copy }; std::string operator()() && { return std::move(str); // move }; }; template auto create_1(t_Func&& f) { return std::make_tuple( std::forward(f()) ); }; template auto create_2(t_Func&& f) { return std::tuple_concat( create_1(f), // lvalue, used again later create_2(std::forward(f)) ); }; conclusion: In the most cases use universal references. And use std::forward, when you know, it is not used again. -- Exactly as you would do with other object types.

[@alexmanea4920]

This is perfect for lambda-enabled command pattern

[@alexmanea4920]

I _command_ to you lord ! Consider it done

[@markusbock3364]

I usually use a class that is construct able with a std::function only to make a scope guard for when using a c api that requires cleanup. Or if possible I use boost scope exit

[@markusbock3364]

Red0x Because this kind of usage was the first thing that came to my mind when he asked for scenarios that this might be useful in

[@ruadeil_zabelin]

If you have a C object that requires cleanup, you can pack it in a unique_ptr with a custom cleanup: std::unique_ptr object(create_someobject_in_c(), cleanup_someobject_in_c); This will give you all the freedom and protection you need for C stuff that requires cleanup. Indeed boost scope_exit also works, but this is better if you need to keep it as a class member or whatever.

[@markusbock3364]

Kayak Fan Nice never thought of that thank you!

[@xavierthomas1980]

I "common" use case would be capturing a object with a destructor by value.

[@MatkatMusic]

i think you deserve to be fired if you ever write code like what was presented in this video on a team project. this is unmaintainable code and is complex for the sake of being complex with no useful gain.

[@schekla]

WOW! So much boilerplate. Why not just use a class?

[@cybermindable]

Наркоман что ли?