Scott Meyers - Effective Modern C++

The key to passing a bitfield into a perfect-forwarding function, then, is to take advantage of the fact that the forwarded-to function will always receive a copy of the bitfield's value. You can thus make a copy yourself and call the forwarding function with the copy. In the case of our example with IPv4Header, this code would do the trick:

// copy bitfield value; see Item 6 for info on init. form

auto length = static_cast(h.totalLength);

fwd(length); // forward the copy

In most cases, perfect forwarding works exactly as advertised. You rarely have to think about it. But when it doesn't work — when reasonable-looking code fails to compile or, worse, compiles, but doesn't behave the way you anticipate — it's important to know about perfect forwarding's imperfections. Equally important is knowing how to work around them. In most cases, this is straightforward.

• Perfect forwarding fails when template type deduction fails or when it deduces the wrong type.

• The kinds of arguments that lead to perfect forwarding failure are braced initializers, null pointers expressed as 0or NULL, declaration-only integral const staticdata members, template and overloaded function names, and bitfields.

Lambda expressions — lambdas — are a game changer in C++ programming. That's somewhat surprising, because they bring no new expressive power to the language. Everything a lambda can do is something you can do by hand with a bit more typing. But lambdas are such a convenient way to create function objects, the impact on day-to-day C++ software development is enormous. Without lambdas, the STL “ _if” algorithms (e.g., std::find_if, std::remove_if, std::count_if, etc.) tend to be employed with only the most trivial predicates, but when lambdas are available, use of these algorithms with nontrivial conditions blossoms. The same is true of algorithms that can be customized with comparison functions (e.g., std::sort, std::nth_element, std::lower_bound, etc.). Outside the STL, lambdas make it possible to quickly create custom deleters for std::unique_ptrand std::shared_ptr(see Items 18and 19), and they make the specification of predicates for condition variables in the threading API equally straightforward (see Item 39). Beyond the Standard Library, lambdas facilitate the on-the-fly specification of callback functions, interface adaption functions, and context-specific functions for one-off calls. Lambdas really make C++ a more pleasant programming language.

The vocabulary associated with lambdas can be confusing. Here's a brief refresher:

• A lambda expression is just that: an expression. It's part of the source code. In

std::find_if( container .begin(), container .end(),

[](int val) { return 0 < val && val < 10; });

the highlighted expression is the lambda.

• A closure is the runtime object created by a lambda. Depending on the capture mode, closures hold copies of or references to the captured data. In the call to std::find_ifabove, the closure is the object that's passed at runtime as the third argument to std::find_if.

• A closure class is a class from which a closure is instantiated. Each lambda causes compilers to generate a unique closure class. The statements inside a lambda become executable instructions in the member functions of its closure class.

A lambda is often used to create a closure that's used only as an argument to a function. That's the case in the call to std::find_ifabove. However, closures may generally be copied, so it's usually possible to have multiple closures of a closure type corresponding to a single lambda. For example, in the following code,

{

int x; // x is local variable

…

auto c1 = // c1 is copy of the

[x](int y) { return x * y > 55; }; // closure produced

// by the lambda

auto c2 = c1; // c2 is copy of c1

auto c3 = c2; // c3 is copy of c2

…

}

c1, c2, and c3are all copies of the closure produced by the lambda.

Informally, it's perfectly acceptable to blur the lines between lambdas, closures, and closure classes. But in the Items that follow, it's often important to distinguish what exists during compilation (lambdas and closure classes), what exists at runtime (closures), and how they relate to one another.

There are two default capture modes in C++11: by-reference and by-value. Default by-reference capture can lead to dangling references. Default by-value capture lures you into thinking you're immune to that problem (you're not), and it lulls you into thinking your closures are self-contained (they may not be).

That's the executive summary for this Item. If you're more engineer than executive, you'll want some meat on those bones, so let's start with the danger of default by-reference capture.

A by-reference capture causes a closure to contain a reference to a local variable or to a parameter that's available in the scope where the lambda is defined. If the lifetime of a closure created from that lambda exceeds the lifetime of the local variable or parameter, the reference in the closure will dangle. For example, suppose we have a container of filtering functions, each of which takes an intand returns a boolindicating whether a passed-in value satisfies the filter:

using FilterContainer = // see Item 9 for

std::vector>; // "using", Item 2

// for std::function

FilterContainer filters; // filtering funcs

We could add a filter for multiples of 5 like this:

filters.emplace_back( // see Item 42 for

[](int value) { return value % 5 == 0; } // info on

); // emplace_back

However, it may be that we need to compute the divisor at runtime, i.e., we can't just hard-code 5 into the lambda. So adding the filter might look more like this:

void addDivisorFilter() {

auto calc1 = computeSomeValue1();

auto calc2 = computeSomeValue2();

auto divisor= computeDivisor(calc1, calc2);

filters.emplace_back( // danger!

[&](int value) { return value % divisor == 0; } // ref to

); // divisor

} // will

// dangle!

This code is a problem waiting to happen. The lambda refers to the local variable divisor, but that variable ceases to exist when addDivisorFilterreturns. That's immediately after filters.emplace_backreturns, so the function that's added to filtersis essentially dead on arrival. Using that filter yields undefined behavior from virtually the moment it's created.

Now, the same problem would exist if divisor's by-reference capture were explicit,

filters.emplace_back(

[ &divisor](int value) // danger! ref to

{ return value % divisor == 0; } // divisor will

); // still dangle!