Jonathan Boccara's blog

Making code expressive with lambdas

Published January 19, 2017 - 19 Comments

Lambdas are arguably one of the most noted addition to the language in C++11. It is a useful tool, but one has to make sure to use them correctly to make code more expressive, and not more obscure.

First off, let’s make clear that lambdas do not add functionalities to the language. Everything you can do with a lambda can be done with a functor, albeit with a heavier syntax and more typing.

For instance, here is the comparative example of checking if all elements of a collection of ints are comprised between two other ints a and b:

The functor version:

The lambda version:

Clearly the lambda version is more concise and easier to type, which probably explains the hype around the arrival of lambdas in C++.

For such simple treatments as checking if a number is between two bounds, I suppose that many would agree that lambdas are to be preferred. But I want to show that this is not true for all cases.

Beyond typing and concision, the two main differences between lambdas and functors in the previous example are that:

  • the lambda doesn’t have a name,
  • the lambda doesn’t hide its code from its call site.

But taking code out of the call site by calling a function that has a meaningful name is the elementary technique for managing your levels of abstractions. However the above example is ok because the two expressions:

and

kind of read the same. They are at the same level of abstraction (although it could be argued that the first expression contains less noise).

But when the code gets more into details, the outcome can be very different, as shown in the following example.

Let’s consider the example of a class representing a box, that can be constructed from its measurements along with its material (metal, plastic, wood, etc.), and that gives access to the box’s characteristics:

We have a collection of these boxes:

And we want to select the boxes that would be solid enough to contain a certain product (water, oil, juice, etc.).

With a little bit of physical reasoning, we approximate the strength applied by the product onto the 4 sides of the box as the weight of the product, that is spread over the surfaces of those sides. The box is solid enough if the material can accept the pressure applied on it.

Let’s assume that the material can provide the maximum pressure it can sustain:

And the product provides its density in order to compute its weight:

Now to select the boxes that will be solid enough to hold the Product product, we can write the following code using the STL with lambdas:

And here would be the equivalent functor definition:

And in the main code:

Although the functor still involves more typing, the line with the algorithm should seem much clearer in the functor case than in the lambda case. And unfortunately for the lambdas version, this line matters more since it is the main code, by which you and other developers start reading to understand what the code does.

Here the lambda has the problem of showing how to perform the box checking, as opposed to just saying that the checking is performed, so it is a level of abstraction too low. And in this example it hurts the readability of the code, because it forces the reader to delve into the lambda’s body to figure out what it does, instead of just saying what it does.

Here, it is necessary to hide the code from the call site, and put a meaningful name on it. The functor does a better job in this regard.

But is it to say that we should not use lambdas in any case that is not trivial?? Surely not.

Lambdas are made to be lighter and more convenient than functors, and you can actually benefit from that, while still keeping levels of abstraction in order. The trick here is to hide the lambda’s code behind a meaningful name by using an intermediary function. Here is how to do it in C++14:

Here the lambda is encapsulated in a function that just creates it and returns it. This function has the effect of hiding the lambda behind a meaningful name.

And here is the main code, alleviated from the implementation burden:

Let’s now use ranges instead of STL iterators for the rest of this post in order to get a code even more expressive :

This necessity to hide the implementation becomes all the more important when there is other code surrounding the call to the algorithm. To illustrate this, let’s add the requirement that the boxes must be initialized from textual descriptions of measurements separated by commas (e.g. “16,12.2,5”) and a unique material for all the boxes.

If we use direct calls to on-the-fly lambdas, the result would look like this:

which becomes really difficult to read.

But by using the intermediary function to encapsulate the lambdas, the code would become:

which is — in my humble opinion — what you want your code to look like.

Note that this technique works in C++14 but not quite in C++11 where a small change is needed.

The type of the lambda is not specified by the standard and is left to the implmentation of your compiler. Here the auto as a return type lets the compiler write the return type of the function to be the type of the lambda. In C++11 though you can’t do that, so you need to specify some return type. Lambdas are implicitly convertible to std::function with the right type parameters, and those can be used in STL and range algorithms. Note that, as righlty pointed out by Antoine in the comments section, std::function incurs an additional cost related to heap allocation and virtual call indirection.

In C++11 the proposed code for the resists function would be:

Note that in both the C++11 and C++14 implementation there may not be any copy of the lambda returned by the resists function, as the return value optimization will likely optimize it away. Note also that functions returning auto must have their definition visible from their call site. So this technique works best for lambdas defined in the same file as the calling code.

Conclusion

In conclusion:

  • use anonymous lambdas defined at their call site for functions that are transparent for the level of abstraction
  • otherwise, encapsulate your lambda in an intermediary function.

Related articles:

Liked it ? Share this post ! Facebooktwittergoogle_plus    Don't want to miss out ? Follow:   twitterrss

Receive regular updates to make your code more expressive.