Under the hood of C++ lambdas and std::function

[doomrobo]

If anyone is curious, as of C++14 you can `move` variables into a lambda scope (like Rust's move ||) as follows

    Foo foo; // Foo implements a move constructor
    auto l = [cap = std::move(foo)](){ do_stuff(cap);} // Make the lambda
    do_stuff(foo); // ILLEGAL. Cannot use moved value
    l(); // Run the lambda

[svalorzen]

Note that `do_stuff` may not necessarily be illegal, since a moved value is required to be valid but in an unknown state. So maybe the result of `do_stuff` will be unspecified and unknowable (unless it requires some specific assumptions about the data), but any operations on `foo` should not give rise to obvious errors.

[Kristine1975]

>// ILLEGAL. Cannot use moved value

Actually that depends on the implementation of "Foo". After all "foo" has not been destroyed yet.

Edit: An instance of std::unique_ptr for example points to nullptr after having been moved to another instance (C++14 Standard §20.8.1p4.2).

[rjeli]

At this time, what can Rust accomplish with the borrow checker that C++ can't accomplish with move semantics?

[hellofunk]

>Lambdas are also awesome when it comes to performance. Because they are objects rather than pointers they can be inlined very easily by the compiler, much like functors. This means that calling a lambda many times (such as with std::sort or std::copy_if) is much better than using a global function. This is one example of where C++ is actually faster than C.

That's insight I've never seen anywhere before.

[Kristine1975]

It's also wrong. If the compiler inlines e.g. std::sort, it doesn't matter whether the comparator is a lambda or a pointer to a function: The compiler knows what it is and can inline it as well. The only exception is when the function is defined in a different compilation unit. Then the compiler has no access to its definition and thus cannot inline it into std::sort.

The "C++ with lambda is faster than C with function" comes from C's qsort function that takes a function pointer to a comparator and is not inlined by the compiler. This can result in it being slower than std::sort.

BTW since lambdas without capture decay to function pointers, you can pass such a lambda to qsort.

[stinos]

I think there's truth in it but I'd still take it with a grain of salt, more like can be faster under the right circumstances. Inlining can not only be faster because there's no need for the function call prologue/epilogue etc but, probably more important, because the compiler sees all of the code and this opens doors for more optimizations. That's really important to realize; I recommend looking at the assembly generated by the compiler for loops etc from time to time. It's simply amazing what can be done. So if in similar code C++ can take advantage of it while C can't because it has to do an actual function call then the C++ version has advantages and might very well be faster (whereas otherwise both would produce roughly the same result and speed I guess, unless C++-only features like virtual functions etc used).

[sebastic]

His logic is wrong. It's not because they are objects, it's because std::sort and friends are function templates. They know what they are calling at compile time. Templates allow for compile-time polymorphism like this.

Because of compile-time polymorphism, you can pass in prvalue function pointers and objects alike and the compiler will be able to inline.

C doesn't have templates, therefore it doesn't have compile-time polymorphism, therefore it's much harder for the compiler to inline.

Compilers like GCC and Clang can inline in some runtime-polymorphism circumstances. See -flto and -fdevirtualize.

[sebastic]

Also C++ is generally as fast as C. If anything, it's faster thanks to increased opportunities for inlining.

Whoever says C++ is slower than C is misinformed and/or overgeneralizing.

Professional C++ programmers know this already though.

[thelema314]

I kind of wish this article had gotten into some details of how various compilers implement std::function; while it was nice to see some details of clang++'s 32-byte size of all std::function to remove the need for dynamic memory for many function objects, I'm still wishing I had more details on efficiency/cost of using std::function vs. plain lambdas or function pointers or other solutions.

[Animats]

From the article: "My favorite expression in C++ is [](){}();, which declares an empty lambda and immediately executes it."

Sigh.

[tomjakubowski]

If you'll excuse me while I golf line noise, you can just write it as []{}(), too; the parameter list may be omitted for a lambda that takes no arguments.

[igravious]

Come on. What's wrong with that? That tickles me pink both aesthetically and logically? Expand on "sigh" sir!

[Too]

In JavaScript it's quite common to see self executing lambdas like this (not empty though), because there variables have function scope rather than block scope so it's a way to limit the scope and capture closures. Does it have any practical use in c++?

[BudVVeezer]

You are forgetting attributes, which can be empty and are grammatical sequences (so you can add them infinitely).

[[]][[]][]()[[]][[]]{}();