Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is an old version of boost. Click here for the latest version's documentation home page.

5. Lambda expressions in details

This section describes different categories of lambda expressions in details. We devote a separate section for each of the possible forms of a lambda expression.

5.1. Placeholders

The BLL defines three placeholder types: placeholder1_type, placeholder2_type and placeholder3_type. BLL has a predefined placeholder variable for each placeholder type: _1, _2 and _3. However, the user is not forced to use these placeholders. It is easy to define placeholders with alternative names. This is done by defining new variables of placeholder types. For example:

boost::lambda::placeholder1_type X;
boost::lambda::placeholder2_type Y;
boost::lambda::placeholder3_type Z;
With these variables defined, X += Y * Z is equivalent to _1 += _2 * _3.

The use of placeholders in the lambda expression determines whether the resulting function is nullary, unary, binary or 3-ary. The highest placeholder index is decisive. For example:

_1 + 5              // unary
_1 * _1 + _1        // unary
_1 + _2             // binary
bind(f, _1, _2, _3) // 3-ary
_3 + 10             // 3-ary
Note that the last line creates a 3-ary function, which adds 10 to its third argument. The first two arguments are discarded. Furthermore, lambda functors only have a minimum arity. One can always provide more arguments (up the number of supported placeholders) that is really needed. The remaining arguments are just discarded. For example:
int i, j, k; 
_1(i, j, k)        // returns i, discards j and k
(_2 + _2)(i, j, k) // returns j+j, discards i and k
See Section 1 for the design rationale behind this functionality.

In addition to these three placeholder types, there is also a fourth placeholder type placeholderE_type. The use of this placeholder is defined in Section 5.7 describing exception handling in lambda expressions.

When an actual argument is supplied for a placeholder, the parameter passing mode is always by reference. This means that any side-effects to the placeholder are reflected to the actual argument. For example:

int i = 1; 
(_1 += 2)(i);         // i is now 3
(++_1, cout << _1)(i) // i is now 4, outputs 4

5.2. Operator expressions

The basic rule is that any C++ operator invocation with at least one argument being a lambda expression is itself a lambda expression. Almost all overloadable operators are supported. For example, the following is a valid lambda expression:

cout << _1, _2[_3] = _1 && false

However, there are some restrictions that originate from the C++ operator overloading rules, and some special cases.

5.2.1. Operators that cannot be overloaded

Some operators cannot be overloaded at all (::, ., .*). For some operators, the requirements on return types prevent them to be overloaded to create lambda functors. These operators are ->., ->, new, new[], delete, delete[] and ?: (the conditional operator).

5.2.2. Assignment and subscript operators

These operators must be implemented as class members. Consequently, the left operand must be a lambda expression. For example:

int i; 
_1 = i;      // ok
i = _1;      // not ok. i is not a lambda expression
There is a simple solution around this limitation, described in Section 5.5. In short, the left hand argument can be explicitly turned into a lambda functor by wrapping it with a special var function:
var(i) = _1; // ok

5.2.3. Logical operators

Logical operators obey the short-circuiting evaluation rules. For example, in the following code, i is never incremented:

bool flag = true; int i = 0;
(_1 || ++_2)(flag, i);

5.2.4. Comma operator

Comma operator is the “statement separator” in lambda expressions. Since comma is also the separator between arguments in a function call, extra parenthesis are sometimes needed:

for_each(a.begin(), a.end(), (++_1, cout << _1));
Without the extra parenthesis around ++_1, cout << _1, the code would be interpreted as an attempt to call for_each with four arguments.

The lambda functor created by the comma operator adheres to the C++ rule of always evaluating the left operand before the right one. In the above example, each element of a is first incremented, then written to the stream.

5.2.5. Function call operator

The function call operators have the effect of evaluating the lambda functor. Calls with too few arguments lead to a compile time error.

5.2.6. Member pointer operator

The member pointer operator operator->* can be overloaded freely. Hence, for user defined types, member pointer operator is no special case. The built-in meaning, however, is a somewhat more complicated case. The built-in member pointer operator is applied if the left argument is a pointer to an object of some class A, and the right hand argument is a pointer to a member of A, or a pointer to a member of a class from which A derives. We must separate two cases:

  • The right hand argument is a pointer to a data member. In this case the lambda functor simply performs the argument substitution and calls the built-in member pointer operator, which returns a reference to the member pointed to. For example:

    struct A { int d; };
    A* a = new A();
      ...
    (a ->* &A::d);     // returns a reference to a->d 
    (_1 ->* &A::d)(a); // likewise
    

  • The right hand argument is a pointer to a member function. For a built-in call like this, the result is kind of a delayed member function call. Such an expression must be followed by a function argument list, with which the delayed member function call is performed. For example:

    struct B { int foo(int); };
    B* b = new B();
      ...
    (b ->* &B::foo)         // returns a delayed call to b->foo
                            // a function argument list must follow
    (b ->* &B::foo)(1)      // ok, calls b->foo(1)
    
    (_1 ->* &B::foo)(b);    // returns a delayed call to b->foo, 
                            // no effect as such
    (_1 ->* &B::foo)(b)(1); // calls b->foo(1)
    

5.3. Bind expressions

Bind expressions can have two forms:

bind(target-function, bind-argument-list)
bind(target-member-function, object-argument, bind-argument-list)
A bind expression delays the call of a function. If this target function is n-ary, then the bind-argument-list must contain n arguments as well. In the current version of the BLL, 0 <= n <= 9 must hold. For member functions, the number of arguments must be at most 8, as the object argument takes one argument position. Basically, the bind-argument-list must be a valid argument list for the target function, except that any argument can be replaced with a placeholder, or more generally, with a lambda expression. Note that also the target function can be a lambda expression. The result of a bind expression is either a nullary, unary, binary or 3-ary function object depending on the use of placeholders in the bind-argument-list (see Section 5.1).

The return type of the lambda functor created by the bind expression can be given as an explicitly specified template parameter, as in the following example:

bind<RET>(target-function, bind-argument-list)
This is only necessary if the return type of the target function cannot be deduced.

The following sections describe the different types of bind expressions.

5.3.1. Function pointers or references as targets

The target function can be a pointer or a reference to a function and it can be either bound or unbound. For example:

X foo(A, B, C); A a; B b; C c;
bind(foo, _1, _2, c)(a, b);
bind(&foo, _1, _2, c)(a, b);
bind(_1, a, b, c)(foo);
The return type deduction always succeeds with this type of bind expressions.

Note, that in C++ it is possible to take the address of an overloaded function only if the address is assigned to, or used as an initializer of, a variable, the type of which solves the amibiguity, or if an explicit cast expression is used. This means that overloaded functions cannot be used in bind expressions directly, e.g.:

void foo(int);
void foo(float);
int i; 
  ...
bind(&foo, _1)(i);                            // error 
  ...
void (*pf1)(int) = &foo;
bind(pf1, _1)(i);                             // ok
bind(static_cast<void(*)(int)>(&foo), _1)(i); // ok

5.3.2. Member functions as targets

The syntax for using pointers to member function in bind expression is:

bind(target-member-function, object-argument, bind-argument-list)
The object argument can be a reference or pointer to the object, the BLL supports both cases with a uniform interface:
bool A::foo(int) const; 
A a;
vector<int> ints; 
  ...
find_if(ints.begin(), ints.end(), bind(&A::foo, a, _1)); 
find_if(ints.begin(), ints.end(), bind(&A::foo, &a, _1));
Similarly, if the object argument is unbound, the resulting lambda functor can be called both via a pointer or a reference:
bool A::foo(int); 
list<A> refs; 
list<A*> pointers; 
  ...
find_if(refs.begin(), refs.end(), bind(&A::foo, _1, 1)); 
find_if(pointers.begin(), pointers.end(), bind(&A::foo, _1, 1));

Even though the interfaces are the same, there are important semantic differences between using a pointer or a reference as the object argument. The differences stem from the way bind-functions take their parameters, and how the bound parameters are stored within the lambda functor. The object argument has the same parameter passing and storing mechanism as any other bind argument slot (see Section 4.4); it is passed as a const reference and stored as a const copy in the lambda functor. This creates some asymmetry between the lambda functor and the original member function, and between seemingly similar lambda functors. For example:

class A {
  int i; mutable int j;
public:

  A(int ii, int jj) : i(ii), j(jj) {};
  void set_i(int x) { i = x; }; 
  void set_j(int x) const { j = x; }; 
};
When a pointer is used, the behavior is what the programmer might expect:
A a(0,0); int k = 1;
bind(&A::set_i, &a, _1)(k); // a.i == 1
bind(&A::set_j, &a, _1)(k); // a.j == 1
Even though a const copy of the object argument is stored, the original object a is still modified. This is since the object argument is a pointer, and the pointer is copied, not the object it points to. When we use a reference, the behaviour is different:
A a(0,0); int k = 1;
bind(&A::set_i, a, _1)(k); // error; a const copy of a is stored. 
                           // Cannot call a non-const function set_i
bind(&A::set_j, a, _1)(k); // a.j == 0, as a copy of a is modified

To prevent the copying from taking place, one can use the ref or cref wrappers (var and constant_ref would do as well):

bind(&A::set_i, ref(a), _1)(k); // a.j == 1
bind(&A::set_j, cref(a), _1)(k); // a.j == 1

Note that the preceding discussion is relevant only for bound arguments. If the object argument is unbound, the parameter passing mode is always by reference. Hence, the argument a is not copied in the calls to the two lambda functors below:

A a(0,0);
bind(&A::set_i, _1, 1)(a); // a.i == 1
bind(&A::set_j, _1, 1)(a); // a.j == 1

5.3.3. Member variables as targets

A pointer to a member variable is not really a function, but the first argument to the bind function can nevertheless be a pointer to a member variable. Invoking such a bind expression returns a reference to the data member. For example:

struct A { int data; };
A a;
bind(&A::data, _1)(a) = 1;     // a.data == 1
The cv-qualifiers of the object whose member is accessed are respected. For example, the following tries to write into a const location:
const A ca = a;
bind(&A::data, _1)(ca) = 1;     // error

5.3.4. Function objects as targets

Function objects, that is, class objects which have the function call operator defined, can be used as target functions. In general, BLL cannot deduce the return type of an arbitrary function object. However, there is a method for giving BLL this capability for a certain function object class.

The sig template

To make BLL aware of the return type(s) of a function object one needs to provide a member template struct sig<Args> with a typedef type that specifies the return type. Here is a simple example:

struct A {
  template <class Args> struct sig { typedef B type; }
  B operator()(X, Y, Z); 
};
The template argument Args is a tuple (or more precisely a cons list) type [tuple], where the first element is the function object type itself, and the remaining elements are the types of the arguments, with which the function object is being called. This may seem overly complex compared to the Standard Library convention for defining the return type of a function object with the return_type typedef. Howver, there are two significant restrictions with using just a simple typedef to express the return type:
  1. If the function object defines several function call operators, there is no way to specify different result types for them.

  2. If the function call operator is a template, the result type may depend on the template parameters. Hence, the typedef ought to be a template too, which the C++ language does not support.

The following code shows an example, where the return type depends on the type of one of the arguments, and how that dependency can be expressed with the sig template:
struct A {

  // the return type equals the third argument type:
  template<class T1, T2, T3>
  T3 operator()(const T1& t1, const T2& t2, const T3& t3);

  template <class Args> 
  class sig {
    // get the third argument type (4th element)
    typedef typename 
      boost::tuples::element<3, Args>::type T3;
  public:
    typedef typename 
      boost::remove_cv<T3>::type type;
  }
};
The elements of the Args tuple are always non-reference types. Moreover, the element types can have a const or volatile qualifier (jointly referred to as cv-qualifiers), or both. This is since the cv-qualifiers in the arguments can affect the return type. The reason for including the potentially cv-qualified function object type itself into the Args tuple, is that the function object class can contain both const and non-const (or volatile, even const volatile) function call operators, and they can each have a different return type.

The sig template can be seen as a meta-function that maps the argument type tuple to the result type of the call made with arguments of the types in the tuple. As the example above demonstrates, the template can end up being somewhat complex. Typical tasks to be performed are the extraction of the relevant types from the tuple, removing cv-qualifiers etc. See the Boost type_traits [type_traits] and Tuple [type_traits] libraries for tools that can aid in these tasks. The sig templates are a refined version of a similar mechanism first introduced in the FC++ library [fc++].

Earlier versions of the library supported the Standard Library convention as the default, and required special actions to make the library recognize the sig template. Now the BLL has that reversed. If one needs to use a functor that adheres to the Standard Library convention in a bind expression, we provide the std_functor wrapper, that gives the function object a sig template based on the result_type typedef. For example:

int i = 1;
bind(plus<int>(), _1, 1)(i);              // error, no sig template
bind(std_functor(plus<int>()), _1, 1)(i); // ok

5.4. Overriding the deduced return type

The return type deduction system may not be able to deduce the return types of some user defined operators or bind expressions with class objects. A special lambda expression type is provided for stating the return type explicitly and overriding the deduction system. To state that the return type of the lambda functor defined by the lambda expression e is T, you can write:

ret<T>(e);
The effect is that the return type deduction is not performed for the lambda expression e at all, but instead, T is used as the return type. Obviously T cannot be an arbitrary type, the true result of the lambda functor must be implicitly convertible to T. For example:
A a; B b;
C operator+(A, B);
int operator*(A, B); 
  ...
ret<D>(_1 + _2)(a, b);     // error (C cannot be converted to D)
ret<C>(_1 + _2)(a, b);     // ok
ret<float>(_1 * _2)(a, b); // ok (int can be converted to float)
  ...
struct X {
  Y operator(int)();   
};
  ...
X x; int i;
bind(x, _1)(i);            // error, return type cannot be deduced
ret<Y>(bind(x, _1))(i);    // ok
For bind expressions, there is a short-hand notation that can be used instead of ret. The last line could alternatively be written as:
bind<Z>(x, _1)(i);
This feature is modeled after the Boost Bind library [bind].

Note that within nested lambda expressions, the ret must be used at each subexpression where the deduction would otherwise fail. For example:

A a; B b;
C operator+(A, B); D operator-(C);
  ...
ret<D>( - (_1 + _2))(a, b); // error 
ret<D>( - ret<C>(_1 + _2))(a, b); // ok

If you find yourself using ret repeatedly with the same types, it is worth while extending the return type deduction (see Section 6).

5.4.1. Nullary lambda functors and ret

As stated above, the effect of ret is to prevent the return type deduction to be performed. However, there is an exception. Due to the way the C++ template instantiation works, the compiler is always forced to instantiate the return type deduction templates for zero-argument lambda functors. This introduces a slight problem with ret, best described with an example:

struct F { int operator()(int i) const; }; 
F f;
  ...
bind(f, _1);           // fails, cannot deduce the return type
ret<int>(bind(f, _1)); // ok
  ...
bind(f, 1);            // fails, cannot deduce the return type
ret<int>(bind(f, 1));  // fails as well!
The BLL cannot deduce the return types of the above bind calls, as F does not define the typedef result_type. One would expect ret to fix this, but for the nullary lambda functor that results from a bind expression (last line above) this does not work. The return type deduction templates are instantiated, even though it would not be necessary and the result is a compilation error.

The solution to this is not to use the ret function, but rather define the return type as an explicitly specified template parameter in the bind call:

bind<int>(f, 1);       // ok
The lambda functors created with ret<T>(bind(arg-list)) and bind<T>(arg-list) have the exact same functionality — apart from the fact that for some nullary lambda functors the former does not work while the latter does.

5.5. Delaying constants and variables

The unary functions constant, constant_ref and var turn their argument into a lambda functor, that implements an identity mapping. The former two are for constants, the latter for variables. The use of these delayed constants and variables is sometimes necessary due to the lack of explicit syntax for lambda expressions. For example:

for_each(a.begin(), a.end(), cout << _1 << ' ');
for_each(a.begin(), a.end(), cout << ' ' << _1);
The first line outputs the elements of a separated by spaces, while the second line outputs a space followed by the elements of a without any separators. The reason for this is that neither of the operands of cout << ' ' is a lambda expression, hence cout << ' ' is evaluated immediately. To delay the evaluation of cout << ' ', one of the operands must be explicitly marked as a lambda expression. This is accomplished with the constant function:
for_each(a.begin(), a.end(), cout << constant(' ') << _1);
The call constant(' ') creates a nullary lambda functor which stores the character constant ' ' and returns a reference to it when invoked. The function constant_ref is similar, except that it stores a constant reference to its argument. The constant and consant_ref are only needed when the operator call has side effects, like in the above example.

Sometimes we need to delay the evaluation of a variable. Suppose we wanted to output the elements of a container in a numbered list:

int index = 0; 
for_each(a.begin(), a.end(), cout << ++index << ':' << _1 << '\n');
for_each(a.begin(), a.end(), cout << ++var(index) << ':' << _1 << '\n');
The first for_each invocation does not do what we want; index is incremented only once, and its value is written into the output stream only once. By using var to make index a lambda expression, we get the desired effect.

In sum, var(x) creates a nullary lambda functor, which stores a reference to the variable x. When the lambda functor is invoked, a reference to x is returned.

Naming delayed constants and variables

It is possible to predefine and name a delayed variable or constant outside a lambda expression. The templates var_type, constant_type and constant_ref_type serve for this purpose. They are used as:

var_type<T>::type delayed_i(var(i));
constant_type<T>::type delayed_c(constant(c));
The first line defines the variable delayed_i which is a delayed version of the variable i of type T. Analogously, the second line defines the constant delayed_c as a delayed version of the constant c. For example:
int i = 0; int j;
for_each(a.begin(), a.end(), (var(j) = _1, _1 = var(i), var(i) = var(j))); 
is equivalent to:
int i = 0; int j;
var_type<int>::type vi(var(i)), vj(var(j));
for_each(a.begin(), a.end(), (vj = _1, _1 = vi, vi = vj));

Here is an example of naming a delayed constant:

constant_type<char>::type space(constant(' '));
for_each(a.begin(),a.end(), cout << space << _1);

About assignment and subscript operators

As described in Section 5.2.2, assignment and subscripting operators are always defined as member functions. This means, that for expressions of the form x = y or x[y] to be interpreted as lambda expressions, the left-hand operand x must be a lambda expression. Consequently, it is sometimes necessary to use var for this purpose. We repeat the example from Section 5.2.2:

int i; 
i = _1;       // error
var(i) = _1;  // ok

Note that the compound assignment operators +=, -= etc. can be defined as non-member functions, and thus they are interpreted as lambda expressions even if only the right-hand operand is a lambda expression. Nevertheless, it is perfectly ok to delay the left operand explicitly. For example, i += _1 is equivalent to var(i) += _1.

5.6. Lambda expressions for control structures

BLL defines several functions to create lambda functors that represent control structures. They all take lambda functors as parameters and return void. To start with an example, the following code outputs all even elements of some container a:

for_each(a.begin(), a.end(), 
         if_then(_1 % 2 == 0, cout << _1));  

The BLL supports the following function templates for control structures:

if_then(condition, then_part)
if_then_else(condition, then_part, else_part)
if_then_else_return(condition, then_part, else_part)
while_loop(condition, body)
while_loop(condition) // no body case
do_while_loop(condition, body)
do_while_loop(condition) // no body case 
for_loop(init, condition, increment, body)
for_loop(init, condition, increment) // no body case
switch_statement(...)
The return types of all control construct lambda functor is void, except for if_then_else_return, which wraps a call to the conditional operator
condition ? then_part : else_part
The return type rules for this operator are somewhat complex. Basically, if the branches have the same type, this type is the return type. If the type of the branches differ, one branch, say of type A, must be convertible to the other branch, say of type B. In this situation, the result type is B. Further, if the common type is an lvalue, the return type will be an lvalue too.

Delayed variables tend to be commonplace in control structure lambda expressions. For instance, here we use the var function to turn the arguments of for_loop into lambda expressions. The effect of the code is to add 1 to each element of a two-dimensional array:

int a[5][10]; int i;
for_each(a, a+5, 
  for_loop(var(i)=0, var(i)<10, ++var(i), 
           _1[var(i)] += 1));  

The BLL supports an alternative syntax for control expressions, suggested by Joel de Guzmann. By overloading the operator[] we can get a closer resemblance with the built-in control structures:

if_(condition)[then_part]
if_(condition)[then_part].else_[else_part]
while_(condition)[body]
do_[body].while_(condition)
for_(init, condition, increment)[body]
For example, using this syntax the if_then example above can be written as:
for_each(a.begin(), a.end(), 
         if_(_1 % 2 == 0)[ cout << _1 ])  
As more experience is gained, we may end up deprecating one or the other of these syntaces.

5.6.1. Switch statement

The lambda expressions for switch control structures are more complex since the number of cases may vary. The general form of a switch lambda expression is:

switch_statement(condition, 
  case_statement<label>(lambda expression),
  case_statement<label>(lambda expression),
  ...
  default_statement(lambda expression)
)
The condition argument must be a lambda expression that creates a lambda functor with an integral return type. The different cases are created with the case_statement functions, and the optional default case with the default_statement function. The case labels are given as explicitly specified template arguments to case_statement functions and break statements are implicitly part of each case. For example, case_statement<1>(a), where a is some lambda functor, generates the code:
case 1: 
  evaluate lambda functor a; 
  break;
The switch_statement function is specialized for up to 9 case statements.

As a concrete example, the following code iterates over some container v and ouptuts “zero” for each 0, “one” for each 1, and “other: n” for any other value n. Note that another lambda expression is sequenced after the switch_statement to output a line break after each element:

std::for_each(v.begin(), v.end(),
  ( 
    switch_statement(
      _1,
      case_statement<0>(std::cout << constant("zero")),
      case_statement<1>(std::cout << constant("one")),
      default_statement(cout << constant("other: ") << _1)
    ), 
    cout << constant("\n") 
  )
);

5.7. Exceptions

The BLL provides lambda functors that throw and catch exceptions. Lambda functors for throwing exceptions are created with the unary function throw_exception. The argument to this function is the exception to be thrown, or a lambda functor which creates the exception to be thrown. A lambda functor for rethrowing exceptions is created with the nullary rethrow function.

Lambda expressions for handling exceptions are somewhat more complex. The general form of a lambda expression for try catch blocks is as follows:

try_catch(
  lambda expression,
  catch_exception<type>(lambda expression),
  catch_exception<type>(lambda expression),
  ...
  catch_all(lambda expression)
)
The first lambda expression is the try block. Each catch_exception defines a catch block where the explicitly specified template argument defines the type of the exception to catch. The lambda expression within the catch_exception defines the actions to take if the exception is caught. Note that the resulting exception handlers catch the exceptions as references, i.e., catch_exception<T>(...) results in the catch block:
catch(T& e) { ... }
The last catch block can alternatively be a call to catch_exception<type> or to catch_all, which is the lambda expression equivalent to catch(...).

The Example 1 demonstrates the use of the BLL exception handling tools. The first handler catches exceptions of type foo_exception. Note the use of _1 placeholder in the body of the handler.

The second handler shows how to throw exceptions, and demonstrates the use of the exception placeholder _e. It is a special placeholder, which refers to the caught exception object within the handler body. Here we are handling an exception of type std::exception, which carries a string explaining the cause of the exception. This explanation can be queried with the zero-argument member function what. The expression bind(&std::exception::what, _e) creates the lambda function for making that call. Note that _e cannot be used outside of an exception handler lambda expression. The last line of the second handler constructs a new exception object and throws that with throw exception. Constructing and destructing objects within lambda expressions is explained in Section 5.8

Finally, the third handler (catch_all) demonstrates rethrowing exceptions.

Example 1. Throwing and handling exceptions in lambda expressions.

for_each(
  a.begin(), a.end(),
  try_catch(
    bind(foo, _1),                 // foo may throw
    catch_exception<foo_exception>(
      cout << constant("Caught foo_exception: ") 
           << "foo was called with argument = " << _1
    ),
    catch_exception<std::exception>(
      cout << constant("Caught std::exception: ") 
           << bind(&std::exception::what, _e),
      throw_exception(bind(constructor<bar_exception>(), _1)))
    ),      
    catch_all(
      (cout << constant("Unknown"), rethrow())
    )
  )
);

5.8. Construction and destruction

Operators new and delete can be overloaded, but their return types are fixed. Particularly, the return types cannot be lambda functors, which prevents them to be overloaded for lambda expressions. It is not possible to take the address of a constructor, hence constructors cannot be used as target functions in bind expressions. The same is true for destructors. As a way around these constraints, BLL defines wrapper classes for new and delete calls, as well as for constructors and destructors. Instances of these classes are function objects, that can be used as target functions of bind expressions. For example:

int* a[10];
for_each(a, a+10, _1 = bind(new_ptr<int>())); 
for_each(a, a+10, bind(delete_ptr(), _1));
The new_ptr<int>() expression creates a function object that calls new int() when invoked, and wrapping that inside bind makes it a lambda functor. In the same way, the expression delete_ptr() creates a function object that invokes delete on its argument. Note that new_ptr<T>() can take arguments as well. They are passed directly to the constructor invocation and thus allow calls to constructors which take arguments.

As an example of constructor calls in lambda expressions, the following code reads integers from two containers x and y, constructs pairs out of them and inserts them into a third container:

vector<pair<int, int> > v;
transform(x.begin(), x.end(), y.begin(), back_inserter(v),
          bind(constructor<pair<int, int> >(), _1, _2));
Table 1 lists all the function objects related to creating and destroying objects, showing the expression to create and call the function object, and the effect of evaluating that expression.

Table 1. Construction and destruction related function objects.

Function object callWrapped expression
constructor<T>()(arg_list)T(arg_list)
destructor()(a)a.~A(), where a is of type A
destructor()(pa)pa.->A(), where pa is of type A*
new_ptr<T>()(arg_list)new T(arg_list)
new_array<T>()(sz)new T[sz]
delete_ptr()(p)delete p
delete_array()(p)delete p[]

5.9. Special lambda expressions

5.9.1. Preventing argument substitution

When a lambda functor is called, the default behavior is to substitute the actual arguments for the placeholders within all subexpressions. This section describes the tools to prevent the substitution and evaluation of a subexpression, and explains when these tools should be used.

The arguments to a bind expression can be arbitrary lambda expressions, e.g., other bind expressions. For example:

int foo(int); int bar(int);
...
int i;
bind(foo, bind(bar, _1)(i);
The last line makes the call foo(bar(i)); Note that the first argument in a bind expression, the target function, is no exception, and can thus be a bind expression too. The innermost lambda functor just has to return something that can be used as a target function: another lambda functor, function pointer, pointer to member function etc. For example, in the following code the innermost lambda functor makes a selection between two functions, and returns a pointer to one of them:
int add(int a, int b) { return a+b; }
int mul(int a, int b) { return a*b; }

int(*)(int, int)  add_or_mul(bool x) { 
  return x ? add : mul; 
}

bool condition; int i; int j;
...
bind(bind(&add_or_mul, _1), _2, _3)(condition, i, j);

5.9.1.1. Unlambda

A nested bind expression may occur inadvertently, if the target function is a variable with a type that depends on a template parameter. Typically the target function could be a formal parameter of a function template. In such a case, the programmer may not know whether the target function is a lambda functor or not.

Consider the following function template:

template<class F>
int nested(const F& f) {
  int x;
  ...
  bind(f, _1)(x);
  ...
}
Somewhere inside the function the formal parameter f is used as a target function in a bind expression. In order for this bind call to be valid, f must be a unary function. Suppose the following two calls to nested are made:
int foo(int);
int bar(int, int);
nested(&foo);
nested(bind(bar, 1, _1));
Both are unary functions, or function objects, with appropriate argument and return types, but the latter will not compile. In the latter call, the bind expression inside nested will become:
bind(bind(bar, 1, _1), _1) 
When this is invoked with x, after substituitions we end up trying to call
bar(1, x)(x)
which is an error. The call to bar returns int, not a unary function or function object.

In the example above, the intent of the bind expression in the nested function is to treat f as an ordinary function object, instead of a lambda functor. The BLL provides the function template unlambda to express this: a lambda functor wrapped inside unlambda is not a lambda functor anymore, and does not take part into the argument substitution process. Note that for all other argument types unlambda is an identity operation, except for making non-const objects const.

Using unlambda, the nested function is written as:

template<class F>
int nested(const F& f) {
  int x;
  ...
  bind(unlambda(f), _1)(x);
  ...
}

5.9.1.2. Protect

The protect function is related to unlambda. It is also used to prevent the argument substitution taking place, but whereas unlambda turns a lambda functor into an ordinary function object for good, protect does this temporarily, for just one evaluation round. For example:

int x = 1, y = 10;
(_1 + protect(_1 + 2))(x)(y);
The first call substitutes x for the leftmost _1, and results in another lambda functor x + (_1 + 2), which after the call with y becomes x + (y + 2), and thus finally 13.

Primary motivation for including protect into the library, was to allow nested STL algorithm invocations (Section 5.11).

5.9.2. Rvalues as actual arguments to lambda functors

Actual arguments to the lambda functors cannot be non-const rvalues. This is due to a deliberate design decision: either we have this restriction, or there can be no side-effects to the actual arguments. There are ways around this limitation. We repeat the example from section Section 4.3 and list the different solutions:

int i = 1; int j = 2; 
(_1 + _2)(i, j); // ok
(_1 + _2)(1, 2); // error (!)
  1. If the rvalue is of a class type, the return type of the function that creates the rvalue should be defined as const. Due to an unfortunate language restriction this does not work for built-in types, as built-in rvalues cannot be const qualified.

  2. If the lambda function call is accessible, the make_const function can be used to constify the rvalue. E.g.:

    (_1 + _2)(make_const(1), make_const(2)); // ok
    
    Commonly the lambda function call site is inside a standard algorithm function template, preventing this solution to be used.

  3. If neither of the above is possible, the lambda expression can be wrapped in a const_parameters function. It creates another type of lambda functor, which takes its arguments as const references. For example:

    const_parameters(_1 + _2)(1, 2); // ok
    
    Note that const_parameters makes all arguments const. Hence, in the case were one of the arguments is a non-const rvalue, and another argument needs to be passed as a non-const reference, this approach cannot be used.

  4. If none of the above is possible, there is still one solution, which unfortunately can break const correctness. The solution is yet another lambda functor wrapper, which we have named break_const to alert the user of the potential dangers of this function. The break_const function creates a lambda functor that takes its arguments as const, and casts away constness prior to the call to the original wrapped lambda functor. For example:

    int i; 
    ...
    (_1 += _2)(i, 2);                 // error, 2 is a non-const rvalue
    const_parameters(_1 += _2)(i, 2); // error, i becomes const
    break_const(_1 += _2)(i, 2);      // ok, but dangerous
    
    Note, that the results of break_const or const_parameters are not lambda functors, so they cannot be used as subexpressions of lambda expressions. For instance:
    break_const(_1 + _2) + _3; // fails.
    const_parameters(_1 + _2) + _3; // fails.
    
    However, this kind of code should never be necessary, since calls to sub lambda functors are made inside the BLL, and are not affected by the non-const rvalue problem.

5.10. Casts, sizeof and typeid

5.10.1. Cast expressions

The BLL defines its counterparts for the four cast expressions static_cast, dynamic_cast, const_cast and reinterpret_cast. The BLL versions of the cast expressions have the prefix ll_. The type to cast to is given as an explicitly specified template argument, and the sole argument is the expression from which to perform the cast. If the argument is a lambda functor, the lambda functor is evaluated first. For example, the following code uses ll_dynamic_cast to count the number of derived instances in the container a:

class base {};
class derived : public base {};

vector<base*> a;
...
int count = 0;
for_each(a.begin(), a.end(), 
         if_then(ll_dynamic_cast<derived*>(_1), ++var(count)));

5.10.2. Sizeof and typeid

The BLL counterparts for these expressions are named ll_sizeof and ll_typeid. Both take one argument, which can be a lambda expression. The lambda functor created wraps the sizeof or typeid call, and when the lambda functor is called the wrapped operation is performed. For example:

vector<base*> a; 
...
for_each(a.begin(), a.end(), 
         cout << bind(&type_info::name, ll_typeid(*_1)));
Here ll_typeid creates a lambda functor for calling typeid for each element. The result of a typeid call is an instance of the type_info class, and the bind expression creates a lambda functor for calling the name member function of that class.

5.11. Nesting STL algorithm invocations

The BLL defines common STL algorithms as function object classes, instances of which can be used as target functions in bind expressions. For example, the following code iterates over the elements of a two-dimensional array, and computes their sum.

int a[100][200];
int sum = 0;

std::for_each(a, a + 100, 
	      bind(ll::for_each(), _1, _1 + 200, protect(sum += _1)));
The BLL versions of the STL algorithms are classes, which define the function call operator (or several overloaded ones) to call the corresponding function templates in the std namespace. All these structs are placed in the subnamespace boost::lambda:ll.

Note that there is no easy way to express an overloaded member function call in a lambda expression. This limits the usefulness of nested STL algorithms, as for instance the begin function has more than one overloaded definitions in container templates. In general, something analogous to the pseudo-code below cannot be written:

std::for_each(a.begin(), a.end(), 
	      bind(ll::for_each(), _1.begin(), _1.end(), protect(sum += _1)));
Some aid for common special cases can be provided though. The BLL defines two helper function object classes, call_begin and call_end, which wrap a call to the begin and, respectively, end functions of a container, and return the const_iterator type of the container. With these helper templates, the above code becomes:
std::for_each(a.begin(), a.end(), 
	      bind(ll::for_each(), 
                   bind(call_begin(), _1), bind(call_end(), _1),
                        protect(sum += _1)));