The Lambda Library: Lambda Abstraction in C++
Jaakko Järvi
Turku Centre for Computer Science (TUCS)
Lemminkäisenkatu 14-18 A
FIN-20520 Turku, Finland
jaakko.jarvi@cs.utu.fi
Abstract
The Lambda Library (LL) adds a form of lambda ab-
straction to C++. The LL is implemented as a tem-
plate library using standard C++; thus no language
extensions or preprocessing is required. The LL con-
sists of a rich set of tools for defining unnamed func-
tions. Particularly, these unnamed functions work
seamlessly with the STL algorithms. The LL offers
significant improvements, in terms of generality and
ease of use, compared to the binders and functors in
the C++ standard library.
1 Introduction
The ability to define lambda functions, i.e. unnamed
functions, is a standard feature in functional pro-
gramming languages. For some reason, this feature
does not appear in mainstream procedural or object-
oriented languages (except for Eiffel, where agents [1],
a recently added language feature provides means to
define unnamed functions). In this paper we intro-
duce the Lambda Library which fixes this ’omission’
for C++.
The Lambda Library (LL) is a C++ template li-
brary implementing a form of lambda abstraction for
C++. The library is designed to work with the Stan-
dard Template Library (STL) [2], now part of the
C++ Standard Library [3]. This article introduces
the features of the library rather than explains its
inner workings. There is an accompanying technical
report, which describes the features more thoroughly
Gary Powell
Sierra On-Line Ltd.
gwpowell@hotmail.com
and goes over the implementation details [4].
1.1 Motivation
Typically STL algorithms operate on container ele-
ments via functions and function objects passed as
arguments to the algorithms. The STL contains pre-
defined function objects for some common cases (such
as plus, less and negate). In addition, it contains
adaptors for creating function objects from function
pointers etc. Further, there are binder templates
bind1st and bind2nd for creating unary function ob-
jects from binary function objects by binding one of
the arguments to a constant value. Some STL imple-
mentations contain function composition operations
as extensions to the standard [5].
The goal of all these tools is clear: to make it possi-
ble to specify unnamed functions in a call to an STL
algorithm. However, this set of tools leaves much
room for improvement. Unnamed functors built as
compositions of standard function objects, binders,
adaptors etc. are very hard to read in all but the
simplest cases. Moreover, the ’lambda abstraction’
with the standard tools is full of restrictions. For ex-
ample, the standard binders allow only one argument
of a binary function to be bound; there are no binders
for 3-ary, 4-ary etc. functions. See [6, 7] for a more
in-depth discussions about these restrictions.
The Lambda Library solves these problems. The
syntax is intuitive and there are no (well, fewer) arbi-
trary restrictions. The concrete consequences of the
LL on the tools in the Standard Library are:
1
 • The standard functors plus, minus, less etc. The operator- replaces the call to negate, bind
become unnecessary. Instead, the corresponding function replaces the compose1 call, ptr_fun be-
operators are used directly. comes unnecessary, along with bind2nd, and the call
to multiplies is replaced with the operator*. The
• The binders bind1st and bind2nd are replaced argument _1 is a placeholder representing the param-
by a more general bind function template. Us- eter of the function object. At each iteration, it will
ing bind, arbitrary arguments of practically any be substituted by the element from the container of
C++ function can be bound. Furthermore, angles.
bind makes ptr_fun, mem_fun and mem_fun_ref
adaptors unnecessary.
1.2 Relation to other work
• No explicit function composition operators are
The LL combines, extends and generalizes the func-
needed.
tionalities of the Expression Template library (ET)
We’ll take an example to demonstrate what LL’s by Powell and Higley [8] and the Binder Library by
impact can be on code using STL algorithms. The Järvi [6]. Other related work includes the FACT [9]
following example is an extract from the documenta- and FC++ [10] libraries, both developed coevally
tion of one STL implementation: with the LL. The basic idea behind the FACT lambda
functions is quite similar to the LL counterparts, al-
... calculates the negative of the sines of the elements though the syntax is different. Compared to LL,
in a vector, where the elements are angles measured in FACT supports a smaller set of operators. FACT
degrees. Since the C library function sin takes its ar- deliberately allows no side effects in lambda func-
guments in radians, this operation is the composition tions, which means that, e.g. various assignment op-
of three operations: negation, sin, and the conversion erators are not supported. FACT lambda functions
of degrees to radians. are ’expression template aware’ (see [11]), while basic
LL lambda functions are not. Interaction with other
vector<double> angles; expression template libraries deserves some more re-
vector<double> sines; search. Further, FACT provides other features in ad-
const double pi = 3.14159265358979323846; dition to lambda functions, such as lazy lists.
... The FC++ is another library adding functional
assert(sines.size() >= angles.size()); features to C++; it more or less embeds a functional
transform(angles.begin(), angles.end(), sublanguage to C++. A notable feature of FC++ is
sines.begin(), the possibility to define variables for storing lambda
compose1( functions. This is very convenient, even though the
negate<double>(), feature comes with some cost: the lambda function
compose1( becomes dynamically bound, and the return type and
ptr_fun(sin), the argument types of the lambda function must be
bind2nd(multiplies<double>(), defined explicitly by the client. The Function Library
pi / 180.0)))); in C++ Boost [12] has a similar feature in a form that
can be combined with other libraries, e.g. with the
LL.
Using LL constructs, the transform function call can To our understanding, FACT and FC++ take the
be written as: functional features in a ’pure’ form. The LL imple-
ments lambda functions, but does some adjustments
transform(angles.begin(), angles.end(), for a better fit to C++. Our foremost goal is to pro-
sines.begin(), vide lambda functions which match perfectly with the
- bind(sin, _1 * pi / 180.0)); STL style of programming.

2
2 Basic usage
This section describes the basic rules for writing
lambda expressions consisting of operator invocations
and different types of functions and function-like con-
structs. Note that there are exceptions to these basic
rules. Some operators in C++ have special seman-
tics, which is reflected in the semantics of the corre-
sponding lambda expressions as well. We cover these
special cases in section 3.
2.1 Introductory examples
It is easiest to understand how to use the LL by look-
ing at some examples. So let’s start with some simple In lambda functions occurring in lambda calculus and
expressions and work up. First, we’ll initialize the el- in functional programming languages the formal pa-
ements of a container (e.g. a list) to the value 1:
list<int> v(10);
for_each(v.begin(), v.end(), _1 = 1);
In this example _1 = 1 creates a lambda function
which assigns the value 1 to every element in v; The
variable _1 is a placeholder, an empty slot, which will
be filled with a value at each iteration. Regarding
terminology, we call _1 = 1 a lambda expression. A
function object created by a lambda expression is a
lambda functor.
Next, we create a container of pointers and make
them point to the elements in the first container v:
list<int*> vp(10);
transform(v.begin(), v.end(),
vp.begin(), &_1);
Here we take the address of each element in v (with
&_1) and assign it to the corresponding element in vp.
Now lets change the values in v. For each element we
call some function foo passing the original value of
the element as an argument to foo:
int foo(int);
for_each(v.begin(), v.end(),
_1 = bind(foo, _1));
Next we’ll sort the elements of vp:
sort(vp.begin(), vp.end(), *_1 > *_2);
In this call to sort, we are sorting the elements by
their contents in descending order. Note that the
lambda expression *_1 > *_2 contains two different
placeholders, _1 and _2. Consequently, it creates a
binary lambda functor. When this functor is called,
the first argument is substituted for _1 and the sec-
ond argument for _2. Finally we’ll output the sorted
content of vp separated by line breaks:
for_each(vp.begin(), vp.end(),
cout << *_1 << endl);
2.2 Placeholders
rameters are commonly named within the lambda ex-
pression with some explicit syntax. For example, the
following definition gives the names x and y to the
formal parameters of an addition function:
λxy.x + y
The LL counterpart of the above expression is written
as:
_1 + _2
In this version the formal parameters, i.e. the place-
holder variables, have predefined names. There is
no explicit syntactic construct for C++ lambda ex-
pressions; the use of a placeholder variable in an ex-
pression implicitly turns the expression into a lambda
expression.1
So far we have used the placeholders _1 and _2.
The LL supports one more: _3. This means that
lambda functors can take one, two or three arguments
passed in by the STL algorithm; zero parameters is
possible too. It would be straightforward to support
higher arities, but no STL algorithm accepts a func-
tor with the number of arguments greater than two,
so the three placeholders should be enough. In fact,
the third placeholder is a necessity in order to im-
plement all the features of the current library (see
section 3.6, which introduces _E, another incarnation
of _3).
1 This doesn’t hold for all expressions, see section 2.3
3
 The placeholders are variables defined by the li-
brary. The variables themselves are not important
but rather their types are. The types serve as tags,
which allow us to spot the placeholders from the argu-
ments stored in a lambda functor, and later replace
them with the actual arguments that are passed in
when the lambda functor gets called. The LL pro-
vides typedefs for the placeholder types, so it is easy
to define the placeholder names to your own liking.
Veldhuizen [13] was the first to introduce the con-
cept of using placeholders in expression templates.
The LL placeholders are somewhat different from the
original ones. You may have noticed from the previ-
ous examples that we do not specify any types for the
arguments that the placeholders stand for. A place-
holder leaves the argument totally open, including
the type. This means that the lambda functor can
be called with arguments of any type for which the
underlying function makes sense.
Consider again the first example we showed in sec-
tion 2:
for_each(v.begin(), v.end(), _1 = 1);
The lambda expression _1 = 1 creates a unary
lambda functor, which can be called with any ob-
ject x, for which x = 1 is a valid expression. The
for_each algorithm iterates over a container of inte-
gers, thus the lambda functor is called with an argu-
ment of type int.
Since the type of the placeholder argument is left
open, the return type of the lambda functor is not
known either. The LL has a type deduction system
that figures out the return type when the lambda
functor is called. It covers operators of built-in types
and ’well-behaved’ operators of user-defined types;
and for your user-defined operators with unorthodox
return types, the deduction system is easy to extend.
2.3 Functions as lambda expressions
The use of a placeholder as one of the operands turns
an operator invocation into a lambda expression im-
plicitly. For ordinary function calls this is not the
case; an explicit syntactic construct is needed. As
the examples above show, the bind function template
4
serves for this purpose. The syntax of a lambda ex-
pression created with the bind function is:
bind(target-function, bind-argument-list)
We use the term bind expression to refer to this
type of lambda expressions. In a bind expression,
the bind-argument-list must be a valid argument
list for target-function, except that any argument
can be replaced with a placeholder, or more gener-
ally, with another lambda expression. Where a place-
holder is used in place of an actual argument, we say
that the argument is unbound.
The target function can be a pointer to function,
a reference to function or a function object. More-
over, it can be a pointer to a member function or
even a placeholder, or again more generally, a lambda
expression. In the last case the result of evalu-
ating the corresponding lambda functor must ob-
viously be a function that can be called with the
bind-argument-list after substitutions. Note that
we use the term target function with all types of
lambda expressions to denote the underlying oper-
ation of the lambda expression.
2.3.1 Function pointers as targets
The target function can be a pointer or a reference to
a non-member function (or a static member function)
and it can be either bound or unbound. For example,
suppose A, B, C and X are some types:
X foo(A, B, C); A a; B b; C c;
...
bind(foo, _1, _2, c)
bind(&foo, _1, _2, c)
bind(foo, _1, _1, _1)
bind(_1, a, b, c)
The first bind expression returns a binary lambda
functor. The second bind expression has an equiv-
alent functionality, it just uses a function pointer
instead of a reference. The third bind expression
demonstrates that a certain placeholder can be used
multiple times in a lambda expression. The argument
will be duplicated in each place that the placeholder is
used. For this bind expression to make sense, and to
compile, the argument to the resulting unary lambda
functor must be implicitly convertible to A, B and C. can handle only one return type per function object
The fourth bind expression shows the case where the class. Consequently, all the overloaded function call
target function is left unbound; the resulting lambda operators within one class must have the same return
functor takes one parameter, the function to be called type if you want to be able to use them as target
with the arguments a, b and c. functions (there is a way around this, see the technical
In C++, it is possible to take the address of an report [4]).
overloaded function only if the address is assigned to
or used to initialize a properly typed variable. This 2.3.3 Member functions as targets
means that overloaded functions cannot be used in
bind expressions directly: The form of the bind expression with member func-
tion targets is slightly different. By convention, we
void foo(int); void foo(float); int i; have chosen to declare the bind functions with the
... following format:
bind(&foo, _1)(i); // error
... bind(target-member-function, target-object,
void (*pf1)(int) = &foo; bind-argument-list)
bind(pf1, _1)(i); // ok
... If the first argument is a pointer to a member func-
bind(static_cast<void(*)(int)>(&foo), tion of some class A, the second argument is the target
_1)(i); // ok as well object, that is, an object of type A for which the mem-
ber function is to be called. A bound target object
2.3.2 Function objects as targets can be either a reference or pointer to the object; the
LL supports both cases with the same interface:
Function objects can also be used as target functions.
The return type deduction system requires that the bool A::foo(int); A a; A* ap;
function object class defines the return type of the vector<int> ints;
function call operator as the typedef result_type. ...
This is the convention used with adaptable function // reference is ok:
objects in the STL. For example: find_if(ints.begin(), ints.end(),
bind(&A::foo, a, _1));
class A {
...
// pointer is ok:
public:
find_if(ints.begin(), ints.end(),
typedef B result_type;
bind(&A::foo, ap, _1));
B operator()(X, Y, Z);
}; The functionality is identical in both cases. Similarly,
The above function object can be used as: if the target object is unbound, the resulting functor
can be called both via a pointer or a reference:
A a; X x; Y y; Z z; list<A> la; list<Z> lz;
list<A> refs; list<A*> ptrs;
for_each(lz.begin(), lz.end(), find_if(refs.begin(), refs.end(),
bind(a, x, y, _1)); bind(&A::foo, _1, 1));
for_each(la.begin(), la.end(), find_if(ptrs.begin(), ptrs.end(),
bind(_1, x, y, z)); bind(&A::foo, _1, 1));

The function call operator can be overloaded within Analogously to other types of bind expressions, the
a class. However, the return type deduction system target-member-function can be left open as well.

5
2.4 Operators as lambda expressions wanted to output a space separated list of the ele-
ments in some container a. Our first attempt might
We have overloaded almost every operator for lambda
be:
expressions. Hence, the basic rule is that any operand
of any operator can be replaced with a placeholder, for_each(a.begin(), a.end(),
or with a lambda expression. All the preceding code cout << " " << _1);
examples follow this rule. However, there are some
special cases and restrictions: However, this piece of code outputs a single space,
followed by the elements of a without any delimiters.
• The return types cannot be chosen freely while The subexpression cout << " " is evaluated first,
overloading operators ->, new, delete, new[] and it is not a lambda expression. It merely out-
and delete[]. Consequently, we can’t overload puts a space and returns a reference to cout, rather
them directly for lambda expressions. than creates a lambda functor.
To get the effect we want, the constant " " must
• It is not possible to overload the ., .*, and ?:
be turned into a lambda functor with the constant
operators in C++.
function:
• The assignment and subscript operators must be
for_each(a.begin(), a.end(),
defined as member functions, which creates some
cout << constant(" ") << _1);
asymmetry to lambda expressions. For example:
Now rather than writing to the stream immediately,
int i; the operator<< call with cout and a lambda functor
_1 = 1; // a valid lambda expression builds another lambda functor. This lambda functor
i = _1; // error, no assignment from will be evaluated later at each iteration and we get
// placeholder type to int the desired result.
A delayed variable is simply a lambda functor con-
A workaround for this situation is explained in taining a reference to a regular C++ variable and
section 2.5. is created with the function template var. A call
var(i) turns some variable i into a lambda expres-
• As stated in section 2.2, the return type deduc-
sion. A somewhat artificial, but hopefully illustrative
tion system may not handle all user-defined op-
example is to compute the number of elements in a
erators. For example, the return type of all com-
container using the for_each algorithm:
parison operators is expected to be bool. If this
is not true for some user-defined comparison op- int count = 0;
erator, return type deduction fails. In such cases for_each(a.begin(), a.end(), var(count)++);
the deduction system can either be extended, or
temporarily overridden by explicit type informa- The variable count is delayed. Hence, the expres-
tion (see the technical report [4]). sion count++ is evaluated at each iteration within
the body of the for_each function.
2.5 Delayed constants and variables A delayed variable, or a constant, can be created
outside the lambda expression as well. The template
It is sometimes necessary to turn a variable, or a con- classes var_type and constant_type serve for this
stant, into a lambda functor. We call such lambda purpose. Using var_type the previous example be-
functors delayed variables, or delayed constants, re- comes:
spectively. The need for delayed variables and con-
stants arises when we want to write lambda expres- int count = 0;
sions that are operator invocations, but none of the var_type<int>::type vcount(var(count));
operands is a placeholder. For example, suppose we for_each(a.begin(), a.end(), vcount++);

6
This feature is useful if the same variable appears
repeatedly in a lambda expression.
In section 2.4 we brought up the asymmetry within
lambda assignment and subscript operators. As be-
comes clear from the above examples, delaying the
evaluation of a variable with var is a solution to this
problem:
int i;
i = _1; // error
var(i) = _1; // ok
2.6 About bound arguments
Bound arguments of a lambda expression are stored
in the lambda functor object. There are few alterna-
tive ways of doing this, and the choices have conse-
quences on whether side effects to the bound argu-
ments are allowed or not. Basically the lambda func-
tors can store temporary copies of the arguments, or
hold const or non-const references to them. The de-
fault is temporary copies. This means that the value
of a bound argument is fixed when the lambda func-
tor is created and remains constant during its life-
time. For example, the result of the lambda functor
invocation below is 11, not 20:
int i = 1; (_1 + i)(i = 10);
In other words, the lambda expression _1 + i creates
a lambda function λx.x + 1 rather than λx.x + i.
As said, this is the default, and for some expres-
sions it makes more sense to store the arguments as
references and allow side effects to the arguments. As
an example, consider the lambda expression i += _1.
The obvious intention is that calls to the lambda
functor affect the value of the variable i, rather than
some temporary copy of it. The LL has this behav-
ior: the left argument of the compound assignment
operators (+=, *=, etc.) are stored as references to
non-const. Further, to make the streaming operators
(<< and >>) work, the stream argument is stored as
a reference. Also, as array types cannot be copied,
lambda functors store references to arguments that
are of array types. In lambda functors created with
bind expressions, the default is to store temporary
7
copies, except for the target object, which is stored
as a reference.
For all cases, LL provides means for overriding the
default storing mechanism. For example, any bound
argument in a lambda expression can be wrapped
with a function named ref to state that the lambda
functor should store a reference to the argument. Re-
garding the preceding example, the lambda expres-
sion λx.x + i can be created with the aid of the ref
function as _1 + ref(i). For an in depth discussion
about this issue, see [14].
3 Advanced features
Our goal has been to make the LL as complete as
possible in the sense that any C++ expression could
be turned into a lambda expression. This section de-
scribes how to use some of the C++ specific operators
in lambda expressions, how to write control struc-
tures as lambda expressions and how to construct and
destruct objects in lambda expressions; we even show
how to do exception handling in lambda expressions.
3.1 Comma and logical operators
The LL overloads the comma operator for sequenc-
ing lambda expressions together, as did the ET li-
brary [8]. The character ”;” is reserved by the C++
language to mean ’end of statement’. For this library
we would like to have it mean, ’end of this lambda
expression’. Unfortunately it just isn’t possible, so
we are left with operator,.
Since comma is also the separator between func-
tion arguments, extra parenthesis are sometimes nec-
essary to write syntactically correct lambda expres-
sions:
for_each(a.begin(), a.end(),
(cout << _1 << endl,
clog << _1 << endl));
Here the parenthesis are used to group the two
lambda expressions into one expression, as opposed
to trying to call the for_each function with four ar-
guments.
 The LL follows the C++ rule for always evaluating for_loop(init, test, increment, body)
the left-hand operand of a comma expression before
Again, the arguments to the for_loop function are
the right-hand operand. In the above example, this
lambda functors.
means that each element of a is guaranteed to be first
Let’s take a concrete example. The following code
written to cout and then to clog.
adds 6 to each element of a two-dimensional array:
Note that the short circuiting rules for the opera-
tors &&, and || are respected as well. For example, int a[5][10]; int i;
the following code sets all negative elements of some for_each(a, a+5,
container a to zero: for_loop(var(i)=0, var(i)<10, ++var(i),
_1[var(i)] += 6));
for_each(a.begin(), a.end(),
_1 < 0 && _1 = 0); Note the use of delayed variables to turn the argu-
ments of for_loop into lambda expressions.
As stated in section 2.5, we can avoid the repeated
3.2 Other special operators wrapping of a variable with var if we create the de-
Since the ?: operator cannot be overloaded, we have layed variable beforehand using the var_type tem-
created the function if_then_else_return to dupli- plate. Using var_type the above example becomes:
cate the ?: operator’s functionality.
int i;
The function call operator is overloaded for place-
var_type<int>::type vi(var(i));
holders only, since other lambda functions already
for_each(a, a+5,
define operator().
for_loop(vi=0, vi<10, ++vi, _1[vi] += 6));
The pointer to member function (operator->*) is
a special case in the sense, that it can refer either to Other loop structures are analogous to for_loop.
a member object or a member function. The return type of all control lambda functors is
void.
3.3 Control lambda expressions
The idea of providing lambda expression variants
3.4 Switch
for control structures originates from the ET Li- The lambda expressions for switch control struc-
brary [8]. The LL implements the control lambda tures, as well as for do_once, are more complex since
expressions of the ET library and adds more. the number of cases may vary. The general form of a
In addition to if_then, if_then_else, for_loop, switch lambda expression is:
while_loop, and do_while_loop, the LL also pro-
vides switch_statement and do_once2 . switch_statement(condition,
case_statement<label >(lambda expression),
Control lambda expressions create lambda functors
case_statement<label >(lambda expression),
that implement the behavior of some control struc-
...
ture. The arguments to these function templates are
default_statement(lambda expression)
lambda functors. For example, the following code
)
outputs all even elements of some container a:
The condition argument must be a lambda expres-
for_each(a.begin(), a.end(), sion that creates a lambda functor with an integral
if_then(_1 % 2 == 0, cout << _1)); return type. The different cases are created with the
case_statement functions, and the optional default
As an example of a loop control lambda expression, case with the default_statement function. The case
the pseudo code definition of for_loop is: labels are given as explicitly specified template argu-
2 A special kind of do while construct, see [4]. ments to case_statement functions and the break

8
statements are implicitly part of each case. For exam- creates a lambda function which wraps the construc-
ple, case_statement<1>(a), where a is some lambda tor call type(args) and returns the resulting object.
functor, generates the code:
case 1:
evaluate lambda functor a;
break;
We have specialized the switch_statement function transform(x.begin(), x.end(), y.begin(),
for up to 9 case statements.
3.5 Constructors and destructors as
lambda expressions 3.6
Operators new and delete can be overloaded, but
their return types are fixed. Particularly, the return
types cannot be lambda functors. As in the case of
the conditional operator, we have defined function
templates to circumvent this restriction. The func-
tion template new_ptr creates a lambda functor that
wraps a new invocation, delete_ptr respectively a
lambda functor that wraps a deletion. For example:
int* a[10];
for_each(a, a+10, _1 = new_ptr<int>());
for_each(a, a+10, delete_ptr(_1));
The new_ptr function takes the type of the object
to be constructed as an explicitly specified template
argument. Note that new_ptr can take arguments
as well. They are passed directly to the construc-
tor invocation and thus allow calls to constructors
which take arguments. The lambda functor created
with delete_ptr first evaluates its argument (which
is a lambda functor as well) and then calls delete
on the result of this evaluation. We have also de-
fined new_array and delete_array for new[] and
delete[].
To be able to write constructors as lambda expres-
sions, we have to resort to a set of function templates
again. We cannot use bind, since it is not possi-
ble to take the address of a constructor. Instead, we
have defined a set of constructor functions which
create lambda functors for constructing objects. The
lambda expression
constructor<type>(args)
The complementary function destructor exists as
well. The following example 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;
back_inserter(v),
constructor<pair<int, int> >(_1, _2));
Exception handling in lambda ex-
pressions
The LL allows you to create lambda functors that
throw and catch exceptions. The 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; the type of
the exception to catch is specified with the explicit
template argument. The resulting lambda functors
catch the exceptions as references. The lambda ex-
pression within the catch_exception defines the ac-
tions to take if the exception is caught.
The last catch block can alternatively be a call to
catch_exception<type> or to catch_all. We have
used catch_all to mean catch(...), since it is not
possible to write catch_exception<...>.
Lambda functors for throwing exceptions are cre-
ated with the unary function throw_exception. The
argument to this function is the exception to be
thrown, or a lambda functor which creates the ex-
ception to be thrown. A lambda functor for rethrow-
ing exceptions is created with the nullary rethrow
function.
The figure 1. demonstrates the use of the LL ex-
ception handling tools. The first catch block is for
9
for_each( expression. Illegal use of placeholders is caught by
a.begin(), a.end(), the compiler. The last handler (catch_all) demon-
try_catch( strates rethrowing exceptions.
bind(foo, _1), //foo may throw
catch_exception<foo_ex>( 3.7 Nesting STL algorithms
cout << constant("foo_ex: ")
<< "foo argument = " << _1 This section describes work in progress and the ex-
), act syntax for nesting STL algorithms may change
catch_exception<std::exception>( in the future versions of the library. In section 3.3
cout << constant("std::exception: ") we showed an example using for_loop as the func-
<< bind(&std::exception::what, tion object passed to the for_each algorithm. We’ll
_E), repeat the example here:
throw_exception(
constructor<bar_ex>(_1)) int a[5][10]; int i;
), for_each(a, a+5,
catch_all( for_loop(var(i)=0, var(i)<10, ++var(i),
(cout << constant("Unknown"), _1[var(i)] += 6));
rethrow())
We could do better: the inner loop should really be
)
another for_each invocation. However, for_each is
)
a function template, and thus cannot be passed as a
);
parameter. To circumvent this, we have copied the
interface of all the STL algorithms into a subnames-
pace LL, where the names of the standard algorithms
Figure 1: Throwing and handling exceptions. refer to our own lambda functors, which implement
the functionality of the corresponding algorithms (by
calling the standard function template). Using a
handling exceptions of type foo_ex. Note the use nested for_each, the above example becomes:
of the _1 placeholder in the lambda expression that
defines the body of the handler. for_each(a, a+5,
LL::for_each(_1, _1 + 10, _1 += 6));
The second handler catches exceptions from the
standard library, writes an informative message to Notice the reuse of _1. In the first two arguments
the cout stream and constructs and throws an ex- of the inner for_each it refers to the elements over
ception of another type, bar_ex. An object of which the outer for_each iterates. In the third ar-
type std::exception carries a string explaining gument, the same placeholder refers to the elements
the cause of the exception. This explanation can in the inner for_each.
be queried with the zero-argument what member
function; bind(&std::exception::what, _E) is the
lambda expression for creating the lambda functor for 4 About implementation
calling what. Note the use of _E as the argument. It
is a special placeholder, which refers to the caught The LL implementation is based on expression tem-
exception object within the handler body. _E is not plates [13]. The basic idea behind expression tem-
a full-fledged placeholder, but rather a special case of plates is to overload operators to create expression
_3. As a consequence, _E cannot be used outside of objects to represent the expression and its arguments
an exception handler lambda expression, and _3 can- instead of evaluating the operator instantly. As a re-
not be used inside of an exception handler lambda sult, the type of an expression object can describe

10
a parse tree of the underlying expression. This ex-
pression object can be manipulated in various ways
(also at compile time) prior to actually evaluating it,
for example to yield better performance by prevent-
ing the creation of unnecessary temporary objects.
In the LL case, this manipulation means passing the
expression object as a parameter to a function, and
substituting the actual arguments for the placeholder
objects.
As we said in section 2.2, LL placeholders do not
carry information about the types of the open ar-
guments. This leaves another task, return type de-
duction, to be performed by the expression template
machinery. This is accomplished with a set of traits
templates. As input, these templates take the under-
lying operator, i.e. the target function, of the lambda
functor together with the types of the arguments this
operator will be called with. The return type deduc-
tion templates are specialized with respect to the type
of the target function (different templates for arith-
metic operators, assignment operators, etc.). Each
such specialization provides a mapping from the ar-
gument types to the return type. If the argument
types are lambda functor instantiations as well, the
compiler has to resort to the return type deduction
system recursively to figure out the actual argument
types.
The LL attempts to cover a fairly complete set of
expression types. This means that there are many
sources of variability: the arity of the lambda func-
tors, the arity of the target functions, the call syn-
tax of the target functions (member functions, non-
member functions, operators), boundedness of argu-
ments etc. To be able to cope with the variability
with a linear, rather than a combinatorial number of
template definitions, the LL consists of several layers.
Each layer implements a certain task orthogonal to
the tasks of the other layers. Within each layer, it is
enough to write template specializations with respect
to a single varying factor.
The LL implementation is far from trivial. Espe-
cially, the return type deduction templates, as well
as the argument substitution code are rather com-
plicated. (The proposed language extension typeof
would simplify the return type deduction code.) Fur-
ther, allowing side effects via bound arguments, in
11
other words passing and storing bound arguments as
non-const references, requires quite some trickery. An
interested reader should read the technical report [4]
and take a look at the code. The library can be down-
loaded at lambda.cs.utu.fi.
5 About performance and use
In theory, all overhead of using STL algorithms and
lambda functors compared to hand written loops can
be optimized away, just as the overhead from stan-
dard STL function objects and binders. Depending
on the compiler, this can also be true in practice. Our
tests suggest that the LL does not introduce a loss
of performance compared to STL function objects.
Hence, with a reasonable optimizing compiler, using
simple lambda expressions you are no worse off than
using classic STL. Further, with a great optimizing
compiler there is no penalty at all.
Another issue is the impact the LL has on compile
times. Expression templates usually involve recursive
template instantiations and can slow down compila-
tion considerably. The LL is no exception, especially
deeply nested lambda expressions can be very slow to
compile.
As another downside, compilation error messages
that result from invalid lambda expressions can be
very hard to comprehend. Even a very simple lambda
functor has a type that spans several lines in an error
message.
6 Conclusion
With the Lambda Library we hope to provide a valu-
able set of tools for working with STL algorithms.
The LL removes several restrictions and simplifies the
use of the STL in many ways. The users of the LL
have a natural way to write simple functors cleanly.
Teachers of STL algorithms can have students writ-
ing clear code quickly: it is easier to explain how to
use the LL than the current alternative of ptr_fun,
mem_fun, bind1st, etc. and it extends better to the
more complex problems (cf. bind3rdAnd4th). Fur-
ther, the LL introduces a set of entirely new possibil-
ities for STL algorithm reuse: The LL makes it pos- [7] V. Simonis. Adapters and binders - overcoming
sible to loop through multiple nested containers. Ex- problems in the design and implementation of
ceptions can be thrown, caught and handled within the C++-STL. ACM SIGPLAN Notices, Jan-
the functor, and the looping in the STL algorithm can uary 2000.
be continued. All the above features are built with
standard C++ templates and do not change the de- [8] G. Powell and P. Higley. Expression templates as
sign model of the language or require an additional a replacement for simple functors. C++ Report,
preprocessing step. 12(5), May 2000.
We are aware of the downsides of the library: com- [9] The FACT! library home page, 2000. http://
plexity, increased compile times and difficult error www.fz-juelich.de/zam/FACT.
messages. These are problems with classic STL as
well, albeit harder in the LL. Despite the problems, [10] B. McNamara and Y. Smaragdakis. Func-
STL became extremely popular. The extensions that tional Programming in C++. In Proceedings
the LL adds to STL have potential for being adopted of The 2000 International Conference on Func-
in wide use as well. There is always room for improve- tional Programming (ICFP). ACM, 2000. http:
ment, but we believe that in terms of generality, ease //www.cc.gatech.edu/~yannis/fc++.
of use and intuitiveness of writing function objects
for STL algorithms, the tools in LL are getting close [11] J. Striegnitz and S. A. Smith. An expression
to what can be achieved without changes to the core template aware lambda function. In First Work-
language. shop on C++ Template Programming, Erfurt,
Germany, October 2000.
[12] C++ boost community. http://www.boost.
References org, 2000.
[1] Agents, iterators and introspection, 2000. http: [13] T. L. Veldhuizen. Expression templates. C++
//www.eiffel.com (information, papers). Report, 7(5):26–31, June 1995.
[2] A. A. Stepanov and M. Lee. The standard [14] J. Järvi and G. Powell. Side effects and par-
template library. Technical Report HPL-94- tial function application in C++. In Proceed-
34(R.1), Hewlett-Packard Laboratories, April ings of the Multiparadigm Programming with OO
1994. http://www.hpl.hp.com/techreports. Languages Workshop (MPOOL’01) at ECOOP
[3] International Standard, Programming Lan- 2001, John von Neumann Institute of Comput-
guages – C++, ISO/IEC:14882, 1998. ing series, 2001.

[4] J. Järvi and G. Powell. The Lambda Library

: Lambda abstraction in C++. Technical Re-
port 378, Turku Centre for Computer Science,
November 2000.

[5] The SGI Standard Template Library. http://

www.sgi.com/tech/stl, 2000.

[6] J. Järvi. C++ function object binders made

easy. In Proceedings of the Generative and
Component-Based Software Engineering’99, vol-
ume 1799 of Lecture Notes in Computer Science,
August 2000.

12