I can not think about modern C++ without lambda expressions. So my wrong assumption was that they are a lot of rules for lambda expressions. Wrong! There are less than ten rules. But as ever I learned something new.

I said I want to write about lambda functions. Maybe you are surprised that the headline is called function objects and lambdas. If you know that lambdas are just function objects automatically created by the compiler then this will not surprise you. If you don't know, read the following section because knowing this magic helps a lot for getting a deeper understanding of lambda expressions.

I will make it short because my plan is to write about lambda expression.

Lambda functions under the hood

First, a function object is an instance of a class, for which the call operator ( operator() ) is overloaded. This means that a function object is an object that behaves like a function. The main difference between a function and a function object is: a function object is an object and can, therefore, have state.

That's all! If the lambda expression captures it's environment and therefore has state, the corresponding struct AddObj gets a constructor for initialising its members. If the lambda expression caputures its argument by reference, so the constructor. The same holds for capturing by value.

With C++14 we have generic lambdas; therefore, you can define a lambda expression such as [](auto a, auto b){ return a + b; };. What does that mean for the call operator of AddObj? I assume you can already guess it. The call operator becomes a template. I want to emphasise it explicitly: a generic lambda is a function template.

I hope this section was not too concise. Let's continue with the four rules.

The function makeLambda returns a lambda expression. The lambda expression takes an int and returns an int. This is the type of the polymorph function wrapper std::function: std::function<int(int)>. (1). Invoking makeLambda(5) (2) creates a lambda expression that captures a which is in this case 5. The same argumentation holds for makeLambda(10) (3); therefore add5(10) and add10(5) are 15 (4).

The next two rules are explicitly dealing with capturing by reference. Both are quite similar; therefore, I will present them together.

For efficiency and correctness reasons, your lambda expression should capture its variables by reference if the lambda expression is locally used. Accordingly, if the lambda expression is not used locally, you should not capture the variables by reference but copy the arguments. If you break the last statement you will get undefined behaviour.

The definition of the lambda addLocal (3) and its usage (4) is fine. The same holds for the definition of the lambda expression lam (1) and its usage (2) inside the function. The undefined behaviour is that the function makeLambda returns a lambda expression with a reference to the local variable local.

Any guess what value the call add10(5) will have in line (5)? Here we are.

Each exution of the program gives a different result for the expression (5).

To be honest, I like this rule because it makes your code more robust. Why does the guidelines call the following program bad?

widget x; // should be const, but:for (auto i =2; i <= N; ++i) { // this could be some
x += some_obj.do_something_with(i); // arbitrarily long code
} // needed to initialize x// from here, x should be const, but we can't say so in code in this style

Conceptunally, you only want to initialise widget x. If it is initialised it should stay constant. This is a idea we can not express in C++. If widget x is used in a multithreading program, you have to synchronise it.

This synchronisation would not be necessary if widget x was constant. Here is the good pendant with lambda expressions.

Thanks to the in-place executed lambda, you can define the widget x as a constant. You can not change its value and ,therefore, you can use it in a multithreading program without expensive synchronisation.

What's next?

One of the key characteristics of object-orientation is inheritance. The C++ Core Guidelines has roughly 25 rules for class hierarchies. I the next post I will write about the concepts interfaces and implementations in class hierarchies.

Get your e-book at leanpub:

The C++ Standard Library

Concurrency With Modern C++

Get Both as one Bundle

With C++11 and C++14 we got a lot of new C++ libraries. In addition, the existing ones are greatly improved. The key idea of my book is to give you the necessary information to the current C++ libraries in about 200 pages.

C++11 is the first C++ standard that deals with concurrency. The story goes on with C++17 and will continue with C++20.

I'll give you a detailed insight in the current and the upcoming concurrency in C++. This insight includes the theory and a lot of practice with more the 100 source files.

Get my books "The C++ Standard Library" and "Concurrency with Modern C++" in a bundle.

In sum, you get more than 500 pages full of modern C++ and more than 100 source files presenting concurrency in practice.