O''''Reilly Network For Information About''''s Book part 86 pot

vec.push_back(2);
vec.push_back(1);
add_prev<int> ap;
std::transform(
vec.begin(),
vec.end(),
vec.begin(),
bind(var(ap),_1));
}
The problem is the call to transform.
std::transform(vec.begin(),vec.end(),vec.begin(),bind(var(ap),_1));
When the binder is instantiated, the mechanism for return type deduction kicks
in…and fails. Thus, the program does not compile, and you must explicitly tell
bind the return type, like so:
std::transform(vec.begin(),vec.end(),vec.begin(),
bind<int>(var(ap),_1));
This is a shorthand notation for the general form of explicitly setting the return
types for lambda expression, and it's the equivalent of this code.
std::transform(vec.begin(),vec.end(),vec.begin(),
ret<int>(bind<int>(var(ap),_1)));
This problem isn't new; it's virtually the same that applies for function objects used
by the Standard Library algorithms. There, the solution is to add typedefs that
state the return type and argument type(s) of the function objects. The Standard
Library even provides helper classes for accomplishing this, through the class
templates unary_function and binary_functionour example class
add_prev could become a compliant function object by either defining the
required typedefs (argument_type and result_type for unary function
objects, first_argument_type, second_argument_type, and
result_type for binary function objects), or inheriting from
unary_function/binary_function.
template <typename T> class add_prev : public std::unary_function<T,T>

Is this good enough for lambda expressions, too? Can we simply reuse this scheme,
and thus our existing function objects, too? Alas, the answer is no. There is a
problem with this typedef approach: What happens when the result type or the
argument type(s) is dependent on a template parameter to a parameterized function
call operator? Or, when there are several overloaded function call operators? Had
there been language support for template typedefs, much of the problem would
be solved, but currently, that's not the case. That's why Boost.Lambda requires a
different approach, through a nested parameterized class called sig. To enable the
return type deduction to work with add_prev, we must define a nested type sig
like this:
template <typename T> class add_prev :
public std::unary_function<T,T> {
T prev_;
public:
template <typename Args> class sig {
public:
typedef T type;
};
// Rest of definition
The template parameter Args is actually a tuple containing the function object
(first element) and the types of the arguments to the function call operator. In our
case, we have no need for this information, as the return type and the argument
type are always T. Using this improved version of add_prev, there's no need to
short-circuit the return type deduction in a lambda expression, so our original
version of the code now compiles cleanly.
std::transform(vec.begin(),vec.end(),vec.begin(),bind(var(ap),_1));
To see how the tuple in the template parameter to sig works, consider another
function object with two function call operators, one version accepting an int
argument, the other accepting a reference to const std::string. The
problem that we need to solve can be expressed as, "if the second element of the

tuple passed to the sig template is of type int, set the return type to
std::string; if the second element of the tuple passed to the sig template is
of type std::string, set the return type to double." To do this, we'll add
another class template that we can specialize and then use in add_prev::sig.
template <typename T> class sig_helper {};
// The version for the overload on int
template<> class sig_helper<int> {
public:
typedef std::string type;
};
// The version for the overload on std::string
template<> class sig_helper<std::string> {
public:
typedef double type;
};
// The function object
class some_function_object {
template <typename Args> class sig {
typedef typename boost::tuples::element<1,Args>::type
cv_first_argument_type;
typedef typename
boost::remove_cv<cv_first_argument_type>::type
first_argument_type;
public:
// The first argument helps us decide the correct version
typedef typename
sig_helper<first_argument_type>::type type;
};
std::string operator()(int i) const {
std::cout << i << '\n';

return "Hello!";
}
double operator()(const std::string& s) const {
std::cout << s << '\n';
return 3.14159265353;
}
};
There are two important parts to study herefirst, the helper class sig_helper,
which is class parameterized on a type T. This type is either int or
std::string, depending on which of the overloaded versions of the function
call operator is requested. By fully specializing this template, the correct
typedef, type, is defined. The next interesting part is the sig class, where the
first argument type (the second element of the tuple) is retrieved, any const or
volatile qualifiers are removed, and the resulting type is used to instantiate the
correct version of the sig_helper class, which has the correct typedef
type. This is a rather complex (but necessary!) way of defining the return types
for our classes, but most of the time, there's only one version of the function call
operator; and then it's a trivial task to correctly add the nested sig class.
It's important that our function objects work without hassle in lambda expressions,
and defining the nested sig class where it's needed is definitely a good idea; it
helps a lot.
Control Structures in Lambda Expressions
We have seen that powerful lambda expressions can be created with ease, but
many programming problems require that we be able to express conditions, which
we do in C++ using if-then-else, for, while, and so on. There are lambda
versions of all C++ control structures in Boost.Lambda. To use the selection
statements, if and switch, include the files "boost/lambda/if.hpp" and
"boost/lambda/switch.hpp", respectively. For the iteration statements,
while, do, and for, include "boost/lambda/loops.hpp". It's not
possible to overload keywords, so the syntax is slightly different than what you're

used to, but the correlation is obvious. As a first example, we'll see how to create a
simple if-then-else construct in a lambda expression. The form is
if_then_else(condition, then-statements, else-statements). There is also another
syntactic form, which has the form if_(condition)[then-statements].else_[else-
statements].
#include <iostream>
#include <algorithm>
#include <vector>
#include <string>
#include "boost/lambda/lambda.hpp"
#include "boost/lambda/bind.hpp"
#include "boost/lambda/if.hpp"
int main() {
using namespace boost::lambda;
std::vector<std::string> vec;
vec.push_back("Lambda");
vec.push_back("expressions");
vec.push_back("really");
vec.push_back("rock");
std::for_each(vec.begin(),vec.end(),if_then_else(
bind(&std::string::size,_1)<=6u,
std::cout << _1 << '\n',
std::cout << constant("Skip.\n")));
std::for_each(vec.begin(),vec.end(),
if_(bind(&std::string::size,_1)<=6u) [
std::cout << _1 << '\n'
]
.else_[
std::cout << constant("Skip.\n")
] );

}
If you've read the whole chapter up to now, you probably find the preceding
example quite readable; if you're jumping right in, this is probably a scary read.
Control structures immediately add to the complexity of reading lambda
expressions, so it does take a little longer to get used to. After you get the hang of
it, it comes naturally (the same goes for writing them!). Deciding which syntactic
form to use is merely a matter of taste; they do exactly the same thing.
In the preceding example, we have a vector of strings and, if their size is less
than or equal to 6, they are printed to std::cout; otherwise, the string "Skip"
is printed. There are a few things worth noting in the if_then_else expression.
if_then_else(
bind(&std::string::size,_1)<=6u,
std::cout << _1 << '\n',
std::cout << constant("Skip.\n")));
First, the condition is a predicate, and it must be a lambda expression! Second, the
then-statement must be a lambda expression! Third, the else-statement must beget
readya lambda expression! The first two come naturally in this case, but it's easy to
forget the constant to make the string literal ("Skip\n") a lambda expression.
The observant reader notices that the example uses 6u, and not simply 6, to make
sure that the comparison is performed using two unsigned types. The reason for
this is that we're dealing with deeply nested templates, which means that when a
lambda expression like this happens to trigger a compiler warning, the output is
really, really long-winded. Try removing the u in the example and see how your
compiler likes it! You should see a warning about comparing signed and unsigned
types because std::string::size returns an unsigned type.
The return type of the control structures is void, with the exception of