The highest placeholder index in a lambda expression determines the arity of the resulting function object. diff --git a/doc/ar01s04.html b/doc/ar01s04.html index df7d71d..d3597fc 100644 --- a/doc/ar01s04.html +++ b/doc/ar01s04.html @@ -122,19 +122,18 @@ in the lambda functor. This means that the value of a bound argument is fixed at the time of the creation of the lambda function and remains constant during the lifetime of the lambda function object. - For example: -
int i = 1; -(_1 + i)(i = 2); +(_1 = 2, _1 + i)(i);- +The comma operator is overloaded to combine lambda expressions into a sequence; +the resulting unary lambda functor first assigns 2 to its argument, +then adds the value of i to it. The value of the expression in the last line is 3, not 4. - -In other words, the lambda expression _1 + i creates -a lambda function lambda x.x+1 rather than -lambda x.x+i. +In other words, the lambda expression that is created is +lambda x.(x = 2, x + 1) rather than +lambda x.(x = 2, x + i).
@@ -152,12 +151,12 @@ or as a reference to const respectively. For example, if we rewrite the previous example and wrap the variable i with ref, -we are creating the lambda expression lambda x.x+i +we are creating the lambda expression lambda x.(x = 2, x + i) and the value of the expression in the last line will be 4:
i = 1; -(_1 + ref(i))(i = 2); +(_1 = 2, _1 + ref(i))(i);Note that ref and cref are different diff --git a/doc/ar01s05.html b/doc/ar01s05.html index 5acd28f..005b3d3 100644 --- a/doc/ar01s05.html +++ b/doc/ar01s05.html @@ -77,7 +77,7 @@ 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. -
+
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). @@ -311,7 +311,7 @@ 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. -
+
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 @@ -533,7 +533,7 @@ By using var to make index a lambda expression, we get the des 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. -
+
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. @@ -562,7 +562,7 @@ Here is an example of naming a delayed constant: constant_type<char>::type space(constant(' ')); for_each(a.begin(),a.end(), cout << space << _1); -
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. @@ -850,7 +850,7 @@ 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 call | Wrapped 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[] |
+
Table 1. Construction and destruction related function objects.
| Function object call | Wrapped 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[] |
When a lambda functor is called, the default behavior is to substitute the actual arguments for the placeholders within all subexpressions. @@ -976,7 +976,7 @@ int nested(const F& f) { } -
The BLL defines its counterparts for the four cast expressions @@ -1110,7 +1110,7 @@ int count = 0; for_each(a.begin(), a.end(), if_then(ll_dynamic_cast<derived*>(_1), ++var(count))); -
The BLL counterparts for these expressions are named ll_sizeof and ll_typeid. diff --git a/doc/ar01s07.html b/doc/ar01s07.html index 780b63e..3f4aff5 100644 --- a/doc/ar01s07.html +++ b/doc/ar01s07.html @@ -5,7 +5,7 @@ The Boost Lambda Library">
In theory, all overhead of using STL algorithms and lambda functors + The Boost Lambda Library">
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 standard STL function objects and binders can. @@ -97,7 +97,7 @@ The running times are expressed in arbitrary units." border="1">
Some additional performance testing with an earlier version of the library is described [Jär00]. -
The BLL uses templates rather heavily, performing numerous recursive instantiations of the same templates. +
The BLL uses templates rather heavily, performing numerous recursive instantiations of the same templates. This has (at least) three implications:
While it is possible to write incredibly complex lambda expressions, it probably isn't a good idea. @@ -111,7 +111,7 @@ This can make the error messages very long and difficult to interpret, particula The C++ Standard suggests a template nesting level of 17 to help detect infinite recursion. Complex lambda templates can easily exceed this limit. Most compilers allow a greater number of nested templates, but commonly require the limit explicitly increased with a command line argument. -
The BLL works with the following compilers, that is, the compilers are capable of compiling the test cases that are included with the BLL:
The following list describes the test files included and the features that each file covers: +
The following list describes the test files included and the features that each file covers:
bind_tests_simple.cpp : Bind expressions of different arities and types of target functions: function pointers, function objects and member functions. diff --git a/doc/ar01s08.html b/doc/ar01s08.html index 9a564c2..493f20f 100644 --- a/doc/ar01s08.html +++ b/doc/ar01s08.html @@ -5,7 +5,7 @@ The Boost Lambda Library">
Sometimes it is convenient to store lambda functors in variables. + The Boost Lambda Library">
Sometimes it is convenient to store lambda functors in variables. However, the types of even the simplest lambda functors are long and unwieldy, and it is in general unfeasible to declare variables with lambda functor types. The Boost Function library [function] defines wrappers for arbitrary function objects, for example lambda functors; and these wrappers have types that are easy to type out. @@ -44,7 +44,7 @@ delete sum; counter(3); // error, *sum does not exist anymore -
The Boost Bind [bind] library has partially overlapping functionality with the BLL. Basically, the Boost Bind library (BB in the sequel) implements the bind expression part of BLL. There are, however, some semantical differerences. @@ -63,7 +63,7 @@ a larger set of compilers.
The following two sections describe what are the semantic differences between the bind expressions in BB and BLL. -
[STL94] The Standard Template Library. Hewlett-Packard Laboratories. 1994.
+ The Boost Lambda Library"> [STL94] The Standard Template Library. Hewlett-Packard Laboratories. 1994.
www.hpl.hp.com/techreports
. [SGI02] The SGI Standard Template Library. 2002. www.sgi.com/tech/stl/. [Jär99]
diff --git a/doc/detail/lambda_doc.xml b/doc/detail/lambda_doc.xml
index 51c7eec..545a31a 100755
--- a/doc/detail/lambda_doc.xml
+++ b/doc/detail/lambda_doc.xml
@@ -588,19 +588,18 @@ in the lambda functor.
This means that the value of a bound argument is fixed at the time of the
creation of the lambda function and remains constant during the lifetime
of the lambda function object.
-
For example:
-
Table of Contents
Table of Contents
diff --git a/doc/lambda_docs_as_one_file.html b/doc/lambda_docs_as_one_file.html index aaae03b..3f6e2e9 100644 --- a/doc/lambda_docs_as_one_file.html +++ b/doc/lambda_docs_as_one_file.html @@ -8,9 +8,9 @@ The Boost Lambda Library is free software; Permission to copy, use, modify and distribute this software and its documentation is granted, provided this copyright notice appears in all copies. -
Table of Contents
Table of Contents
The Boost Lambda Library (BLL in the sequel) is a C++ template library, which implements form of lambda abstractions for C++. @@ -356,19 +356,18 @@ in the lambda functor. This means that the value of a bound argument is fixed at the time of the creation of the lambda function and remains constant during the lifetime of the lambda function object. - For example: -
int i = 1; -(_1 + i)(i = 2); +(_1 = 2, _1 + i)(i);- +The comma operator is overloaded to combine lambda expressions into a sequence; +the resulting unary lambda functor first assigns 2 to its argument, +then adds the value of i to it. The value of the expression in the last line is 3, not 4. - -In other words, the lambda expression _1 + i creates -a lambda function lambda x.x+1 rather than -lambda x.x+i. +In other words, the lambda expression that is created is +lambda x.(x = 2, x + 1) rather than +lambda x.(x = 2, x + i).
@@ -386,12 +385,12 @@ or as a reference to const respectively. For example, if we rewrite the previous example and wrap the variable i with ref, -we are creating the lambda expression lambda x.x+i +we are creating the lambda expression lambda x.(x = 2, x + i) and the value of the expression in the last line will be 4:
i = 1; -(_1 + ref(i))(i = 2); +(_1 = 2, _1 + ref(i))(i);Note that ref and cref are different @@ -512,7 +511,7 @@ 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. -
+
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). @@ -746,7 +745,7 @@ 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. -
+
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 @@ -968,7 +967,7 @@ By using var to make index a lambda expression, we get the des 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. -
+
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. @@ -997,7 +996,7 @@ Here is an example of naming a delayed constant: constant_type<char>::type space(constant(' ')); for_each(a.begin(),a.end(), cout << space << _1); -
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. @@ -1285,7 +1284,7 @@ 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 call | Wrapped 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[] |
+
Table 1. Construction and destruction related function objects.
| Function object call | Wrapped 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[] |
When a lambda functor is called, the default behavior is to substitute the actual arguments for the placeholders within all subexpressions. @@ -1411,7 +1410,7 @@ int nested(const F& f) { } -
The BLL defines its counterparts for the four cast expressions @@ -1545,7 +1544,7 @@ int count = 0; for_each(a.begin(), a.end(), if_then(ll_dynamic_cast<derived*>(_1), ++var(count))); -
The BLL counterparts for these expressions are named ll_sizeof and ll_typeid. @@ -1818,7 +1817,7 @@ public: Note, that we are reusing the existing specializations for the BLL return_type_2 template, which require that the argument types are references. -
| + | arithmetic_action<plus_action> |
| - | arithmetic_action<minus_action> |
| * | arithmetic_action<multiply_action> |
| / | arithmetic_action<divide_action> |
| % | arithmetic_action<remainder_action> |
| + | unary_arithmetic_action<plus_action> |
| - | unary_arithmetic_action<minus_action> |
| & | bitwise_action<and_action> |
| | | bitwise_action<or_action> |
| ~ | bitwise_action<not_action> |
| ^ | bitwise_action<xor_action> |
| << | bitwise_action<leftshift_action_no_stream> |
| >> | bitwise_action<rightshift_action_no_stream> |
| && | logical_action<and_action> |
| || | logical_action<or_action> |
| ! | logical_action<not_action> |
| < | relational_action<less_action> |
| > | relational_action<greater_action> |
| <= | relational_action<lessorequal_action> |
| >= | relational_action<greaterorequal_action> |
| == | relational_action<equal_action> |
| != | relational_action<notequal_action> |
| += | arithmetic_assignment_action<plus_action> |
| -= | arithmetic_assignment_action<minus_action> |
| *= | arithmetic_assignment_action<multiply_action> |
| /= | arithmetic_assignment_action<divide_action> |
| %= | arithmetic_assignment_action<remainder_action> |
| &= | bitwise_assignment_action<and_action> |
| =| | bitwise_assignment_action<or_action> |
| ^= | bitwise_assignment_action<xor_action> |
| <<= | bitwise_assignment_action<leftshift_action> |
| >>= | bitwise_assignment_action<rightshift_action> |
| ++ | pre_increment_decrement_action<increment_action> |
| -- | pre_increment_decrement_action<decrement_action> |
| ++ | post_increment_decrement_action<increment_action> |
| -- | post_increment_decrement_action<decrement_action> |
| & | other_action<address_of_action> |
| * | other_action<contents_of_action> |
| , | other_action<comma_action> |
In theory, all overhead of using STL algorithms and lambda functors +
| + | arithmetic_action<plus_action> |
| - | arithmetic_action<minus_action> |
| * | arithmetic_action<multiply_action> |
| / | arithmetic_action<divide_action> |
| % | arithmetic_action<remainder_action> |
| + | unary_arithmetic_action<plus_action> |
| - | unary_arithmetic_action<minus_action> |
| & | bitwise_action<and_action> |
| | | bitwise_action<or_action> |
| ~ | bitwise_action<not_action> |
| ^ | bitwise_action<xor_action> |
| << | bitwise_action<leftshift_action_no_stream> |
| >> | bitwise_action<rightshift_action_no_stream> |
| && | logical_action<and_action> |
| || | logical_action<or_action> |
| ! | logical_action<not_action> |
| < | relational_action<less_action> |
| > | relational_action<greater_action> |
| <= | relational_action<lessorequal_action> |
| >= | relational_action<greaterorequal_action> |
| == | relational_action<equal_action> |
| != | relational_action<notequal_action> |
| += | arithmetic_assignment_action<plus_action> |
| -= | arithmetic_assignment_action<minus_action> |
| *= | arithmetic_assignment_action<multiply_action> |
| /= | arithmetic_assignment_action<divide_action> |
| %= | arithmetic_assignment_action<remainder_action> |
| &= | bitwise_assignment_action<and_action> |
| =| | bitwise_assignment_action<or_action> |
| ^= | bitwise_assignment_action<xor_action> |
| <<= | bitwise_assignment_action<leftshift_action> |
| >>= | bitwise_assignment_action<rightshift_action> |
| ++ | pre_increment_decrement_action<increment_action> |
| -- | pre_increment_decrement_action<decrement_action> |
| ++ | post_increment_decrement_action<increment_action> |
| -- | post_increment_decrement_action<decrement_action> |
| & | other_action<address_of_action> |
| * | other_action<contents_of_action> |
| , | other_action<comma_action> |
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 standard STL function objects and binders can. @@ -1910,7 +1909,7 @@ The running times are expressed in arbitrary units." border="1">
Some additional performance testing with an earlier version of the library is described [Jär00]. -
The BLL uses templates rather heavily, performing numerous recursive instantiations of the same templates. +
The BLL uses templates rather heavily, performing numerous recursive instantiations of the same templates. This has (at least) three implications:
While it is possible to write incredibly complex lambda expressions, it probably isn't a good idea. @@ -1924,7 +1923,7 @@ This can make the error messages very long and difficult to interpret, particula The C++ Standard suggests a template nesting level of 17 to help detect infinite recursion. Complex lambda templates can easily exceed this limit. Most compilers allow a greater number of nested templates, but commonly require the limit explicitly increased with a command line argument. -
The BLL works with the following compilers, that is, the compilers are capable of compiling the test cases that are included with the BLL:
The following list describes the test files included and the features that each file covers: +
The following list describes the test files included and the features that each file covers:
bind_tests_simple.cpp : Bind expressions of different arities and types of target functions: function pointers, function objects and member functions. @@ -1979,7 +1978,7 @@ Contains several user defined operators and the corresponding specializations fo Contains tests for using boost::function together with lambda functors.
Sometimes it is convenient to store lambda functors in variables. However, the types of even the simplest lambda functors are long and unwieldy, and it is in general unfeasible to declare variables with lambda functor types. The Boost Function library [function] defines wrappers for arbitrary function objects, for example lambda functors; and these wrappers have types that are easy to type out. @@ -2018,7 +2017,7 @@ delete sum; counter(3); // error, *sum does not exist anymore -
The Boost Bind [bind] library has partially overlapping functionality with the BLL. Basically, the Boost Bind library (BB in the sequel) implements the bind expression part of BLL. There are, however, some semantical differerences. @@ -2037,7 +2036,7 @@ a larger set of compilers.
The following two sections describe what are the semantic differences between the bind expressions in BB and BLL. -
The highest placeholder index in a lambda expression determines the arity of the resulting function object. @@ -2156,7 +2155,7 @@ the error would go unnoticed. Furthermore, weak arity checking simplifies the implementation a bit. Following the recommendation of the Boost review, strict arity checking was dropped. -
[STL94] The Standard Template Library. Hewlett-Packard Laboratories. 1994. www.hpl.hp.com/techreports .
[SGI02] The SGI Standard Template Library. 2002. www.sgi.com/tech/stl/.