1 | <html> |
---|
2 | <head> |
---|
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> |
---|
4 | <title>Lambda expressions in details</title> |
---|
5 | <link rel="stylesheet" href="../boostbook.css" type="text/css"> |
---|
6 | <meta name="generator" content="DocBook XSL Stylesheets V1.69.1"> |
---|
7 | <link rel="start" href="../index.html" title="The Boost C++ Libraries"> |
---|
8 | <link rel="up" href="../lambda.html" title="Chapter 6. Boost.Lambda"> |
---|
9 | <link rel="prev" href="using_library.html" title="Using the library"> |
---|
10 | <link rel="next" href="extending.html" title="Extending return type deduction system"> |
---|
11 | </head> |
---|
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> |
---|
13 | <table cellpadding="2" width="100%"> |
---|
14 | <td valign="top"><img alt="boost.png (6897 bytes)" width="277" height="86" src="../../../boost.png"></td> |
---|
15 | <td align="center"><a href="../../../index.htm">Home</a></td> |
---|
16 | <td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td> |
---|
17 | <td align="center"><a href="../../../people/people.htm">People</a></td> |
---|
18 | <td align="center"><a href="../../../more/faq.htm">FAQ</a></td> |
---|
19 | <td align="center"><a href="../../../more/index.htm">More</a></td> |
---|
20 | </table> |
---|
21 | <hr> |
---|
22 | <div class="spirit-nav"> |
---|
23 | <a accesskey="p" href="using_library.html"><img src="../images/prev.png" alt="Prev"></a><a accesskey="u" href="../lambda.html"><img src="../images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="extending.html"><img src="../images/next.png" alt="Next"></a> |
---|
24 | </div> |
---|
25 | <div class="section" lang="en"> |
---|
26 | <div class="titlepage"><div><div><h3 class="title"> |
---|
27 | <a name="lambda.le_in_details"></a>Lambda expressions in details</h3></div></div></div> |
---|
28 | <div class="toc"><dl> |
---|
29 | <dt><span class="section"><a href="le_in_details.html#lambda.placeholders">Placeholders</a></span></dt> |
---|
30 | <dt><span class="section"><a href="le_in_details.html#lambda.operator_expressions">Operator expressions</a></span></dt> |
---|
31 | <dt><span class="section"><a href="le_in_details.html#lambda.bind_expressions">Bind expressions</a></span></dt> |
---|
32 | <dt><span class="section"><a href="le_in_details.html#lambda.overriding_deduced_return_type">Overriding the deduced return type</a></span></dt> |
---|
33 | <dt><span class="section"><a href="le_in_details.html#lambda.delaying_constants_and_variables">Delaying constants and variables</a></span></dt> |
---|
34 | <dt><span class="section"><a href="le_in_details.html#lambda.lambda_expressions_for_control_structures">Lambda expressions for control structures</a></span></dt> |
---|
35 | <dt><span class="section"><a href="le_in_details.html#lambda.exceptions">Exceptions</a></span></dt> |
---|
36 | <dt><span class="section"><a href="le_in_details.html#lambda.construction_and_destruction">Construction and destruction</a></span></dt> |
---|
37 | <dt><span class="section"><a href="le_in_details.html#id2711160">Special lambda expressions</a></span></dt> |
---|
38 | <dt><span class="section"><a href="le_in_details.html#id2711604">Casts, sizeof and typeid</a></span></dt> |
---|
39 | <dt><span class="section"><a href="le_in_details.html#lambda.nested_stl_algorithms">Nesting STL algorithm invocations</a></span></dt> |
---|
40 | </dl></div> |
---|
41 | <p> |
---|
42 | This section describes different categories of lambda expressions in details. |
---|
43 | We devote a separate section for each of the possible forms of a lambda expression. |
---|
44 | |
---|
45 | |
---|
46 | </p> |
---|
47 | <div class="section" lang="en"> |
---|
48 | <div class="titlepage"><div><div><h4 class="title"> |
---|
49 | <a name="lambda.placeholders"></a>Placeholders</h4></div></div></div> |
---|
50 | <p> |
---|
51 | The BLL defines three placeholder types: <code class="literal">placeholder1_type</code>, <code class="literal">placeholder2_type</code> and <code class="literal">placeholder3_type</code>. |
---|
52 | BLL has a predefined placeholder variable for each placeholder type: <code class="literal">_1</code>, <code class="literal">_2</code> and <code class="literal">_3</code>. |
---|
53 | However, the user is not forced to use these placeholders. |
---|
54 | It is easy to define placeholders with alternative names. |
---|
55 | This is done by defining new variables of placeholder types. |
---|
56 | For example: |
---|
57 | |
---|
58 | </p> |
---|
59 | <pre class="programlisting">boost::lambda::placeholder1_type X; |
---|
60 | boost::lambda::placeholder2_type Y; |
---|
61 | boost::lambda::placeholder3_type Z; |
---|
62 | </pre> |
---|
63 | <p> |
---|
64 | |
---|
65 | With these variables defined, <code class="literal">X += Y * Z</code> is equivalent to <code class="literal">_1 += _2 * _3</code>. |
---|
66 | </p> |
---|
67 | <p> |
---|
68 | The use of placeholders in the lambda expression determines whether the resulting function is nullary, unary, binary or 3-ary. |
---|
69 | The highest placeholder index is decisive. For example: |
---|
70 | |
---|
71 | </p> |
---|
72 | <pre class="programlisting"> |
---|
73 | _1 + 5 // unary |
---|
74 | _1 * _1 + _1 // unary |
---|
75 | _1 + _2 // binary |
---|
76 | bind(f, _1, _2, _3) // 3-ary |
---|
77 | _3 + 10 // 3-ary |
---|
78 | </pre> |
---|
79 | <p> |
---|
80 | |
---|
81 | Note that the last line creates a 3-ary function, which adds <code class="literal">10</code> to its <span class="emphasis"><em>third</em></span> argument. |
---|
82 | The first two arguments are discarded. |
---|
83 | Furthermore, lambda functors only have a minimum arity. |
---|
84 | One can always provide more arguments (up the number of supported placeholders) |
---|
85 | that is really needed. |
---|
86 | The remaining arguments are just discarded. |
---|
87 | For example: |
---|
88 | |
---|
89 | </p> |
---|
90 | <pre class="programlisting"> |
---|
91 | int i, j, k; |
---|
92 | _1(i, j, k) // returns i, discards j and k |
---|
93 | (_2 + _2)(i, j, k) // returns j+j, discards i and k |
---|
94 | </pre> |
---|
95 | <p> |
---|
96 | |
---|
97 | See |
---|
98 | <a href="../apa.html#lambda.why_weak_arity" title=" |
---|
99 | Lambda functor arity |
---|
100 | ">the section called “ |
---|
101 | Lambda functor arity |
---|
102 | ”</a> for the design rationale behind this |
---|
103 | functionality. |
---|
104 | |
---|
105 | </p> |
---|
106 | <p> |
---|
107 | In addition to these three placeholder types, there is also a fourth placeholder type <code class="literal">placeholderE_type</code>. |
---|
108 | The use of this placeholder is defined in <a href="le_in_details.html#lambda.exceptions" title="Exceptions">the section called “Exceptions”</a> describing exception handling in lambda expressions. |
---|
109 | </p> |
---|
110 | <p>When an actual argument is supplied for a placeholder, the parameter passing mode is always by reference. |
---|
111 | This means that any side-effects to the placeholder are reflected to the actual argument. |
---|
112 | For example: |
---|
113 | |
---|
114 | |
---|
115 | </p> |
---|
116 | <pre class="programlisting"> |
---|
117 | int i = 1; |
---|
118 | (_1 += 2)(i); // i is now 3 |
---|
119 | (++_1, cout << _1)(i) // i is now 4, outputs 4 |
---|
120 | </pre> |
---|
121 | </div> |
---|
122 | <div class="section" lang="en"> |
---|
123 | <div class="titlepage"><div><div><h4 class="title"> |
---|
124 | <a name="lambda.operator_expressions"></a>Operator expressions</h4></div></div></div> |
---|
125 | <div class="toc"><dl> |
---|
126 | <dt><span class="section"><a href="le_in_details.html#id2708718">Operators that cannot be overloaded</a></span></dt> |
---|
127 | <dt><span class="section"><a href="le_in_details.html#lambda.assignment_and_subscript">Assignment and subscript operators</a></span></dt> |
---|
128 | <dt><span class="section"><a href="le_in_details.html#lambda.logical_operators">Logical operators</a></span></dt> |
---|
129 | <dt><span class="section"><a href="le_in_details.html#lambda.comma_operator">Comma operator</a></span></dt> |
---|
130 | <dt><span class="section"><a href="le_in_details.html#lambda.function_call_operator">Function call operator</a></span></dt> |
---|
131 | <dt><span class="section"><a href="le_in_details.html#lambda.member_pointer_operator">Member pointer operator</a></span></dt> |
---|
132 | </dl></div> |
---|
133 | <p> |
---|
134 | The basic rule is that any C++ operator invocation with at least one argument being a lambda expression is itself a lambda expression. |
---|
135 | Almost all overloadable operators are supported. |
---|
136 | For example, the following is a valid lambda expression: |
---|
137 | |
---|
138 | </p> |
---|
139 | <pre class="programlisting">cout << _1, _2[_3] = _1 && false</pre> |
---|
140 | <p> |
---|
141 | However, there are some restrictions that originate from the C++ operator overloading rules, and some special cases. |
---|
142 | </p> |
---|
143 | <div class="section" lang="en"> |
---|
144 | <div class="titlepage"><div><div><h5 class="title"> |
---|
145 | <a name="id2708718"></a>Operators that cannot be overloaded</h5></div></div></div> |
---|
146 | <p> |
---|
147 | Some operators cannot be overloaded at all (<code class="literal">::</code>, <code class="literal">.</code>, <code class="literal">.*</code>). |
---|
148 | For some operators, the requirements on return types prevent them to be overloaded to create lambda functors. |
---|
149 | These operators are <code class="literal">->.</code>, <code class="literal">-></code>, <code class="literal">new</code>, <code class="literal">new[]</code>, <code class="literal">delete</code>, <code class="literal">delete[]</code> and <code class="literal">?:</code> (the conditional operator). |
---|
150 | </p> |
---|
151 | </div> |
---|
152 | <div class="section" lang="en"> |
---|
153 | <div class="titlepage"><div><div><h5 class="title"> |
---|
154 | <a name="lambda.assignment_and_subscript"></a>Assignment and subscript operators</h5></div></div></div> |
---|
155 | <p> |
---|
156 | These operators must be implemented as class members. |
---|
157 | Consequently, the left operand must be a lambda expression. For example: |
---|
158 | |
---|
159 | </p> |
---|
160 | <pre class="programlisting"> |
---|
161 | int i; |
---|
162 | _1 = i; // ok |
---|
163 | i = _1; // not ok. i is not a lambda expression |
---|
164 | </pre> |
---|
165 | <p> |
---|
166 | |
---|
167 | There is a simple solution around this limitation, described in <a href="le_in_details.html#lambda.delaying_constants_and_variables" title="Delaying constants and variables">the section called “Delaying constants and variables”</a>. |
---|
168 | In short, |
---|
169 | the left hand argument can be explicitly turned into a lambda functor by wrapping it with a special <code class="literal">var</code> function: |
---|
170 | </p> |
---|
171 | <pre class="programlisting"> |
---|
172 | var(i) = _1; // ok |
---|
173 | </pre> |
---|
174 | </div> |
---|
175 | <div class="section" lang="en"> |
---|
176 | <div class="titlepage"><div><div><h5 class="title"> |
---|
177 | <a name="lambda.logical_operators"></a>Logical operators</h5></div></div></div> |
---|
178 | <p> |
---|
179 | Logical operators obey the short-circuiting evaluation rules. For example, in the following code, <code class="literal">i</code> is never incremented: |
---|
180 | </p> |
---|
181 | <pre class="programlisting"> |
---|
182 | bool flag = true; int i = 0; |
---|
183 | (_1 || ++_2)(flag, i); |
---|
184 | </pre> |
---|
185 | </div> |
---|
186 | <div class="section" lang="en"> |
---|
187 | <div class="titlepage"><div><div><h5 class="title"> |
---|
188 | <a name="lambda.comma_operator"></a>Comma operator</h5></div></div></div> |
---|
189 | <p> |
---|
190 | Comma operator is the “<span class="quote">statement separator</span>” in lambda expressions. |
---|
191 | Since comma is also the separator between arguments in a function call, extra parenthesis are sometimes needed: |
---|
192 | |
---|
193 | </p> |
---|
194 | <pre class="programlisting"> |
---|
195 | for_each(a.begin(), a.end(), (++_1, cout << _1)); |
---|
196 | </pre> |
---|
197 | <p> |
---|
198 | |
---|
199 | Without the extra parenthesis around <code class="literal">++_1, cout << _1</code>, the code would be interpreted as an attempt to call <code class="literal">for_each</code> with four arguments. |
---|
200 | </p> |
---|
201 | <p> |
---|
202 | The lambda functor created by the comma operator adheres to the C++ rule of always evaluating the left operand before the right one. |
---|
203 | In the above example, each element of <code class="literal">a</code> is first incremented, then written to the stream. |
---|
204 | </p> |
---|
205 | </div> |
---|
206 | <div class="section" lang="en"> |
---|
207 | <div class="titlepage"><div><div><h5 class="title"> |
---|
208 | <a name="lambda.function_call_operator"></a>Function call operator</h5></div></div></div> |
---|
209 | <p> |
---|
210 | The function call operators have the effect of evaluating the lambda |
---|
211 | functor. |
---|
212 | Calls with too few arguments lead to a compile time error. |
---|
213 | </p> |
---|
214 | </div> |
---|
215 | <div class="section" lang="en"> |
---|
216 | <div class="titlepage"><div><div><h5 class="title"> |
---|
217 | <a name="lambda.member_pointer_operator"></a>Member pointer operator</h5></div></div></div> |
---|
218 | <p> |
---|
219 | The member pointer operator <code class="literal">operator->*</code> can be overloaded freely. |
---|
220 | Hence, for user defined types, member pointer operator is no special case. |
---|
221 | The built-in meaning, however, is a somewhat more complicated case. |
---|
222 | The built-in member pointer operator is applied if the left argument is a pointer to an object of some class <code class="literal">A</code>, and the right hand argument is a pointer to a member of <code class="literal">A</code>, or a pointer to a member of a class from which <code class="literal">A</code> derives. |
---|
223 | We must separate two cases: |
---|
224 | |
---|
225 | </p> |
---|
226 | <div class="itemizedlist"><ul type="disc"> |
---|
227 | <li> |
---|
228 | <p>The right hand argument is a pointer to a data member. |
---|
229 | 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. |
---|
230 | For example: |
---|
231 | </p> |
---|
232 | <pre class="programlisting"> |
---|
233 | struct A { int d; }; |
---|
234 | A* a = new A(); |
---|
235 | ... |
---|
236 | (a ->* &A::d); // returns a reference to a->d |
---|
237 | (_1 ->* &A::d)(a); // likewise |
---|
238 | </pre> |
---|
239 | </li> |
---|
240 | <li> |
---|
241 | <p> |
---|
242 | The right hand argument is a pointer to a member function. |
---|
243 | For a built-in call like this, the result is kind of a delayed member function call. |
---|
244 | Such an expression must be followed by a function argument list, with which the delayed member function call is performed. |
---|
245 | For example: |
---|
246 | </p> |
---|
247 | <pre class="programlisting"> |
---|
248 | struct B { int foo(int); }; |
---|
249 | B* b = new B(); |
---|
250 | ... |
---|
251 | (b ->* &B::foo) // returns a delayed call to b->foo |
---|
252 | // a function argument list must follow |
---|
253 | (b ->* &B::foo)(1) // ok, calls b->foo(1) |
---|
254 | |
---|
255 | (_1 ->* &B::foo)(b); // returns a delayed call to b->foo, |
---|
256 | // no effect as such |
---|
257 | (_1 ->* &B::foo)(b)(1); // calls b->foo(1) |
---|
258 | </pre> |
---|
259 | </li> |
---|
260 | </ul></div> |
---|
261 | </div> |
---|
262 | </div> |
---|
263 | <div class="section" lang="en"> |
---|
264 | <div class="titlepage"><div><div><h4 class="title"> |
---|
265 | <a name="lambda.bind_expressions"></a>Bind expressions</h4></div></div></div> |
---|
266 | <div class="toc"><dl> |
---|
267 | <dt><span class="section"><a href="le_in_details.html#lambda.function_pointers_as_targets">Function pointers or references as targets</a></span></dt> |
---|
268 | <dt><span class="section"><a href="le_in_details.html#member_functions_as_targets">Member functions as targets</a></span></dt> |
---|
269 | <dt><span class="section"><a href="le_in_details.html#lambda.members_variables_as_targets">Member variables as targets</a></span></dt> |
---|
270 | <dt><span class="section"><a href="le_in_details.html#lambda.function_objects_as_targets">Function objects as targets</a></span></dt> |
---|
271 | </dl></div> |
---|
272 | <p> |
---|
273 | Bind expressions can have two forms: |
---|
274 | |
---|
275 | </p> |
---|
276 | <pre class="programlisting"> |
---|
277 | bind(<em class="parameter"><code>target-function</code></em>, <em class="parameter"><code>bind-argument-list</code></em>) |
---|
278 | bind(<em class="parameter"><code>target-member-function</code></em>, <em class="parameter"><code>object-argument</code></em>, <em class="parameter"><code>bind-argument-list</code></em>) |
---|
279 | </pre> |
---|
280 | <p> |
---|
281 | |
---|
282 | A bind expression delays the call of a function. |
---|
283 | If this <span class="emphasis"><em>target function</em></span> is <span class="emphasis"><em>n</em></span>-ary, then the <code class="literal"><span class="emphasis"><em>bind-argument-list</em></span></code> must contain <span class="emphasis"><em>n</em></span> arguments as well. |
---|
284 | In the current version of the BLL, 0 <= n <= 9 must hold. |
---|
285 | For member functions, the number of arguments must be at most 8, as the object argument takes one argument position. |
---|
286 | |
---|
287 | Basically, the |
---|
288 | <span class="emphasis"><em><code class="literal">bind-argument-list</code></em></span> 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. |
---|
289 | Note that also the target function can be a lambda expression. |
---|
290 | |
---|
291 | 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 <span class="emphasis"><em><code class="literal">bind-argument-list</code></em></span> (see <a href="le_in_details.html#lambda.placeholders" title="Placeholders">the section called “Placeholders”</a>). |
---|
292 | </p> |
---|
293 | <p> |
---|
294 | 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: |
---|
295 | </p> |
---|
296 | <pre class="programlisting"> |
---|
297 | bind<<span class="emphasis"><em>RET</em></span>>(<span class="emphasis"><em>target-function</em></span>, <span class="emphasis"><em>bind-argument-list</em></span>) |
---|
298 | </pre> |
---|
299 | <p> |
---|
300 | This is only necessary if the return type of the target function cannot be deduced. |
---|
301 | </p> |
---|
302 | <p> |
---|
303 | The following sections describe the different types of bind expressions. |
---|
304 | </p> |
---|
305 | <div class="section" lang="en"> |
---|
306 | <div class="titlepage"><div><div><h5 class="title"> |
---|
307 | <a name="lambda.function_pointers_as_targets"></a>Function pointers or references as targets</h5></div></div></div> |
---|
308 | <p>The target function can be a pointer or a reference to a function and it can be either bound or unbound. For example: |
---|
309 | </p> |
---|
310 | <pre class="programlisting"> |
---|
311 | X foo(A, B, C); A a; B b; C c; |
---|
312 | bind(foo, _1, _2, c)(a, b); |
---|
313 | bind(&foo, _1, _2, c)(a, b); |
---|
314 | bind(_1, a, b, c)(foo); |
---|
315 | </pre> |
---|
316 | <p> |
---|
317 | |
---|
318 | The return type deduction always succeeds with this type of bind expressions. |
---|
319 | </p> |
---|
320 | <p> |
---|
321 | 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. |
---|
322 | This means that overloaded functions cannot be used in bind expressions directly, e.g.: |
---|
323 | </p> |
---|
324 | <pre class="programlisting"> |
---|
325 | void foo(int); |
---|
326 | void foo(float); |
---|
327 | int i; |
---|
328 | ... |
---|
329 | bind(&foo, _1)(i); // error |
---|
330 | ... |
---|
331 | void (*pf1)(int) = &foo; |
---|
332 | bind(pf1, _1)(i); // ok |
---|
333 | bind(static_cast<void(*)(int)>(&foo), _1)(i); // ok |
---|
334 | </pre> |
---|
335 | </div> |
---|
336 | <div class="section" lang="en"> |
---|
337 | <div class="titlepage"><div><div><h5 class="title"> |
---|
338 | <a name="member_functions_as_targets"></a>Member functions as targets</h5></div></div></div> |
---|
339 | <p> |
---|
340 | The syntax for using pointers to member function in bind expression is: |
---|
341 | </p> |
---|
342 | <pre class="programlisting"> |
---|
343 | bind(<em class="parameter"><code>target-member-function</code></em>, <em class="parameter"><code>object-argument</code></em>, <em class="parameter"><code>bind-argument-list</code></em>) |
---|
344 | </pre> |
---|
345 | <p> |
---|
346 | |
---|
347 | The object argument can be a reference or pointer to the object, the BLL supports both cases with a uniform interface: |
---|
348 | |
---|
349 | </p> |
---|
350 | <pre class="programlisting"> |
---|
351 | bool A::foo(int) const; |
---|
352 | A a; |
---|
353 | vector<int> ints; |
---|
354 | ... |
---|
355 | find_if(ints.begin(), ints.end(), bind(&A::foo, a, _1)); |
---|
356 | find_if(ints.begin(), ints.end(), bind(&A::foo, &a, _1)); |
---|
357 | </pre> |
---|
358 | <p> |
---|
359 | |
---|
360 | Similarly, if the object argument is unbound, the resulting lambda functor can be called both via a pointer or a reference: |
---|
361 | |
---|
362 | </p> |
---|
363 | <pre class="programlisting"> |
---|
364 | bool A::foo(int); |
---|
365 | list<A> refs; |
---|
366 | list<A*> pointers; |
---|
367 | ... |
---|
368 | find_if(refs.begin(), refs.end(), bind(&A::foo, _1, 1)); |
---|
369 | find_if(pointers.begin(), pointers.end(), bind(&A::foo, _1, 1)); |
---|
370 | </pre> |
---|
371 | <p> |
---|
372 | Even though the interfaces are the same, there are important semantic differences between using a pointer or a reference as the object argument. |
---|
373 | The differences stem from the way <code class="literal">bind</code>-functions take their parameters, and how the bound parameters are stored within the lambda functor. |
---|
374 | The object argument has the same parameter passing and storing mechanism as any other bind argument slot (see <a href="using_library.html#lambda.storing_bound_arguments" title="Storing bound arguments in lambda functions">the section called “Storing bound arguments in lambda functions”</a>); it is passed as a const reference and stored as a const copy in the lambda functor. |
---|
375 | This creates some asymmetry between the lambda functor and the original member function, and between seemingly similar lambda functors. For example: |
---|
376 | </p> |
---|
377 | <pre class="programlisting"> |
---|
378 | class A { |
---|
379 | int i; mutable int j; |
---|
380 | public: |
---|
381 | |
---|
382 | A(int ii, int jj) : i(ii), j(jj) {}; |
---|
383 | void set_i(int x) { i = x; }; |
---|
384 | void set_j(int x) const { j = x; }; |
---|
385 | }; |
---|
386 | </pre> |
---|
387 | <p> |
---|
388 | |
---|
389 | When a pointer is used, the behavior is what the programmer might expect: |
---|
390 | |
---|
391 | </p> |
---|
392 | <pre class="programlisting"> |
---|
393 | A a(0,0); int k = 1; |
---|
394 | bind(&A::set_i, &a, _1)(k); // a.i == 1 |
---|
395 | bind(&A::set_j, &a, _1)(k); // a.j == 1 |
---|
396 | </pre> |
---|
397 | <p> |
---|
398 | |
---|
399 | Even though a const copy of the object argument is stored, the original object <code class="literal">a</code> is still modified. |
---|
400 | This is since the object argument is a pointer, and the pointer is copied, not the object it points to. |
---|
401 | When we use a reference, the behaviour is different: |
---|
402 | |
---|
403 | </p> |
---|
404 | <pre class="programlisting"> |
---|
405 | A a(0,0); int k = 1; |
---|
406 | bind(&A::set_i, a, _1)(k); // error; a const copy of a is stored. |
---|
407 | // Cannot call a non-const function set_i |
---|
408 | bind(&A::set_j, a, _1)(k); // a.j == 0, as a copy of a is modified |
---|
409 | </pre> |
---|
410 | <p> |
---|
411 | To prevent the copying from taking place, one can use the <code class="literal">ref</code> or <code class="literal">cref</code> wrappers (<code class="literal">var</code> and <code class="literal">constant_ref</code> would do as well): |
---|
412 | </p> |
---|
413 | <pre class="programlisting"> |
---|
414 | bind(&A::set_i, ref(a), _1)(k); // a.j == 1 |
---|
415 | bind(&A::set_j, cref(a), _1)(k); // a.j == 1 |
---|
416 | </pre> |
---|
417 | <p>Note that the preceding discussion is relevant only for bound arguments. |
---|
418 | If the object argument is unbound, the parameter passing mode is always by reference. |
---|
419 | Hence, the argument <code class="literal">a</code> is not copied in the calls to the two lambda functors below: |
---|
420 | </p> |
---|
421 | <pre class="programlisting"> |
---|
422 | A a(0,0); |
---|
423 | bind(&A::set_i, _1, 1)(a); // a.i == 1 |
---|
424 | bind(&A::set_j, _1, 1)(a); // a.j == 1 |
---|
425 | </pre> |
---|
426 | </div> |
---|
427 | <div class="section" lang="en"> |
---|
428 | <div class="titlepage"><div><div><h5 class="title"> |
---|
429 | <a name="lambda.members_variables_as_targets"></a>Member variables as targets</h5></div></div></div> |
---|
430 | <p> |
---|
431 | A pointer to a member variable is not really a function, but |
---|
432 | the first argument to the <code class="literal">bind</code> function can nevertheless |
---|
433 | be a pointer to a member variable. |
---|
434 | Invoking such a bind expression returns a reference to the data member. |
---|
435 | For example: |
---|
436 | |
---|
437 | </p> |
---|
438 | <pre class="programlisting"> |
---|
439 | struct A { int data; }; |
---|
440 | A a; |
---|
441 | bind(&A::data, _1)(a) = 1; // a.data == 1 |
---|
442 | </pre> |
---|
443 | <p> |
---|
444 | |
---|
445 | The cv-qualifiers of the object whose member is accessed are respected. |
---|
446 | For example, the following tries to write into a const location: |
---|
447 | </p> |
---|
448 | <pre class="programlisting"> |
---|
449 | const A ca = a; |
---|
450 | bind(&A::data, _1)(ca) = 1; // error |
---|
451 | </pre> |
---|
452 | </div> |
---|
453 | <div class="section" lang="en"> |
---|
454 | <div class="titlepage"><div><div><h5 class="title"> |
---|
455 | <a name="lambda.function_objects_as_targets"></a>Function objects as targets</h5></div></div></div> |
---|
456 | <p> |
---|
457 | |
---|
458 | Function objects, that is, class objects which have the function call |
---|
459 | operator defined, can be used as target functions. |
---|
460 | |
---|
461 | In general, BLL cannot deduce the return type of an arbitrary function object. |
---|
462 | |
---|
463 | However, there are two methods for giving BLL this capability for a certain |
---|
464 | function object class. |
---|
465 | |
---|
466 | </p> |
---|
467 | <div class="simplesect" lang="en"> |
---|
468 | <div class="titlepage"><div><div><h6 class="title"> |
---|
469 | <a name="id2709396"></a>The result_type typedef</h6></div></div></div> |
---|
470 | <p> |
---|
471 | |
---|
472 | The BLL supports the standard library convention of declaring the return type |
---|
473 | of a function object with a member typedef named <code class="literal">result_type</code> in the |
---|
474 | function object class. |
---|
475 | |
---|
476 | Here is a simple example: |
---|
477 | </p> |
---|
478 | <pre class="programlisting"> |
---|
479 | struct A { |
---|
480 | typedef B result_type; |
---|
481 | B operator()(X, Y, Z); |
---|
482 | }; |
---|
483 | </pre> |
---|
484 | <p> |
---|
485 | |
---|
486 | If a function object does not define a <code class="literal">result_type</code> typedef, |
---|
487 | the method described below (<code class="literal">sig</code> template) |
---|
488 | is attempted to resolve the return type of the |
---|
489 | function object. If a function object defines both <code class="literal">result_type</code> |
---|
490 | and <code class="literal">sig</code>, <code class="literal">result_type</code> takes precedence. |
---|
491 | |
---|
492 | </p> |
---|
493 | </div> |
---|
494 | <div class="simplesect" lang="en"> |
---|
495 | <div class="titlepage"><div><div><h6 class="title"> |
---|
496 | <a name="id2709451"></a>The sig template</h6></div></div></div> |
---|
497 | <p> |
---|
498 | Another mechanism that make BLL aware of the return type(s) of a function object is defining |
---|
499 | member template struct |
---|
500 | <code class="literal">sig<Args></code> with a typedef |
---|
501 | <code class="literal">type</code> that specifies the return type. |
---|
502 | |
---|
503 | Here is a simple example: |
---|
504 | </p> |
---|
505 | <pre class="programlisting"> |
---|
506 | struct A { |
---|
507 | template <class Args> struct sig { typedef B type; } |
---|
508 | B operator()(X, Y, Z); |
---|
509 | }; |
---|
510 | </pre> |
---|
511 | <p> |
---|
512 | |
---|
513 | The template argument <code class="literal">Args</code> is a |
---|
514 | <code class="literal">tuple</code> (or more precisely a <code class="literal">cons</code> list) |
---|
515 | type [<a href="../lambda.html#cit:boost::tuple" title="[tuple]"><span class="abbrev">tuple</span></a>], where the first element |
---|
516 | is the function |
---|
517 | object type itself, and the remaining elements are the types of |
---|
518 | the arguments, with which the function object is being called. |
---|
519 | |
---|
520 | This may seem overly complex compared to defining the <code class="literal">result_type</code> typedef. |
---|
521 | Howver, there are two significant restrictions with using just a simple |
---|
522 | typedef to express the return type: |
---|
523 | </p> |
---|
524 | <div class="orderedlist"><ol type="1"> |
---|
525 | <li><p> |
---|
526 | If the function object defines several function call operators, there is no way to specify different result types for them. |
---|
527 | </p></li> |
---|
528 | <li><p> |
---|
529 | If the function call operator is a template, the result type may |
---|
530 | depend on the template parameters. |
---|
531 | Hence, the typedef ought to be a template too, which the C++ language |
---|
532 | does not support. |
---|
533 | </p></li> |
---|
534 | </ol></div> |
---|
535 | <p> |
---|
536 | |
---|
537 | The following code shows an example, where the return type depends on the type |
---|
538 | of one of the arguments, and how that dependency can be expressed with the |
---|
539 | <code class="literal">sig</code> template: |
---|
540 | |
---|
541 | </p> |
---|
542 | <pre class="programlisting"> |
---|
543 | struct A { |
---|
544 | |
---|
545 | // the return type equals the third argument type: |
---|
546 | template<class T1, class T2, class T3> |
---|
547 | T3 operator()(const T1& t1, const T2& t2, const T3& t3) const; |
---|
548 | |
---|
549 | template <class Args> |
---|
550 | class sig { |
---|
551 | // get the third argument type (4th element) |
---|
552 | typedef typename |
---|
553 | boost::tuples::element<3, Args>::type T3; |
---|
554 | public: |
---|
555 | typedef typename |
---|
556 | boost::remove_cv<T3>::type type; |
---|
557 | }; |
---|
558 | }; |
---|
559 | </pre> |
---|
560 | <p> |
---|
561 | |
---|
562 | |
---|
563 | The elements of the <code class="literal">Args</code> tuple are always |
---|
564 | non-reference types. |
---|
565 | |
---|
566 | Moreover, the element types can have a const or volatile qualifier |
---|
567 | (jointly referred to as <span class="emphasis"><em>cv-qualifiers</em></span>), or both. |
---|
568 | This is since the cv-qualifiers in the arguments can affect the return type. |
---|
569 | The reason for including the potentially cv-qualified function object |
---|
570 | type itself into the <code class="literal">Args</code> tuple, is that the function |
---|
571 | object class can contain both const and non-const (or volatile, even |
---|
572 | const volatile) function call operators, and they can each have a different |
---|
573 | return type. |
---|
574 | </p> |
---|
575 | <p> |
---|
576 | The <code class="literal">sig</code> template can be seen as a |
---|
577 | <span class="emphasis"><em>meta-function</em></span> that maps the argument type tuple to |
---|
578 | the result type of the call made with arguments of the types in the tuple. |
---|
579 | |
---|
580 | As the example above demonstrates, the template can end up being somewhat |
---|
581 | complex. |
---|
582 | Typical tasks to be performed are the extraction of the relevant types |
---|
583 | from the tuple, removing cv-qualifiers etc. |
---|
584 | See the Boost type_traits [<a href="../lambda.html#cit:boost::type_traits" title="[type_traits]"><span class="abbrev">type_traits</span></a>] and |
---|
585 | Tuple [<a href="../lambda.html#cit:boost::type_traits" title="[type_traits]"><span class="abbrev">type_traits</span></a>] libraries |
---|
586 | for tools that can aid in these tasks. |
---|
587 | The <code class="literal">sig</code> templates are a refined version of a similar |
---|
588 | mechanism first introduced in the FC++ library |
---|
589 | [<a href="../lambda.html#cit:fc++" title="[fc++]"><span class="abbrev">fc++</span></a>]. |
---|
590 | </p> |
---|
591 | </div> |
---|
592 | </div> |
---|
593 | </div> |
---|
594 | <div class="section" lang="en"> |
---|
595 | <div class="titlepage"><div><div><h4 class="title"> |
---|
596 | <a name="lambda.overriding_deduced_return_type"></a>Overriding the deduced return type</h4></div></div></div> |
---|
597 | <div class="toc"><dl><dt><span class="section"><a href="le_in_details.html#lambda.nullary_functors_and_ret">Nullary lambda functors and ret</a></span></dt></dl></div> |
---|
598 | <p> |
---|
599 | 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. |
---|
600 | |
---|
601 | A special lambda expression type is provided for stating the return type explicitly and overriding the deduction system. |
---|
602 | To state that the return type of the lambda functor defined by the lambda expression <code class="literal">e</code> is <code class="literal">T</code>, you can write: |
---|
603 | |
---|
604 | </p> |
---|
605 | <pre class="programlisting">ret<T>(e);</pre> |
---|
606 | <p> |
---|
607 | |
---|
608 | The effect is that the return type deduction is not performed for the lambda expression <code class="literal">e</code> at all, but instead, <code class="literal">T</code> is used as the return type. |
---|
609 | Obviously <code class="literal">T</code> cannot be an arbitrary type, the true result of the lambda functor must be implicitly convertible to <code class="literal">T</code>. |
---|
610 | For example: |
---|
611 | |
---|
612 | </p> |
---|
613 | <pre class="programlisting"> |
---|
614 | A a; B b; |
---|
615 | C operator+(A, B); |
---|
616 | int operator*(A, B); |
---|
617 | ... |
---|
618 | ret<D>(_1 + _2)(a, b); // error (C cannot be converted to D) |
---|
619 | ret<C>(_1 + _2)(a, b); // ok |
---|
620 | ret<float>(_1 * _2)(a, b); // ok (int can be converted to float) |
---|
621 | ... |
---|
622 | struct X { |
---|
623 | Y operator(int)(); |
---|
624 | }; |
---|
625 | ... |
---|
626 | X x; int i; |
---|
627 | bind(x, _1)(i); // error, return type cannot be deduced |
---|
628 | ret<Y>(bind(x, _1))(i); // ok |
---|
629 | </pre> |
---|
630 | <p> |
---|
631 | For bind expressions, there is a short-hand notation that can be used instead of <code class="literal">ret</code>. |
---|
632 | The last line could alternatively be written as: |
---|
633 | |
---|
634 | </p> |
---|
635 | <pre class="programlisting">bind<Z>(x, _1)(i);</pre> |
---|
636 | <p> |
---|
637 | This feature is modeled after the Boost Bind library [<a href="../lambda.html#cit:boost::bind" title="[bind]"><span class="abbrev">bind</span></a>]. |
---|
638 | |
---|
639 | </p> |
---|
640 | <p>Note that within nested lambda expressions, |
---|
641 | the <code class="literal">ret</code> must be used at each subexpression where |
---|
642 | the deduction would otherwise fail. |
---|
643 | For example: |
---|
644 | </p> |
---|
645 | <pre class="programlisting"> |
---|
646 | A a; B b; |
---|
647 | C operator+(A, B); D operator-(C); |
---|
648 | ... |
---|
649 | ret<D>( - (_1 + _2))(a, b); // error |
---|
650 | ret<D>( - ret<C>(_1 + _2))(a, b); // ok |
---|
651 | </pre> |
---|
652 | <p>If you find yourself using <code class="literal">ret</code> repeatedly with the same types, it is worth while extending the return type deduction (see <a href="extending.html" title="Extending return type deduction system">the section called “Extending return type deduction system”</a>). |
---|
653 | </p> |
---|
654 | <div class="section" lang="en"> |
---|
655 | <div class="titlepage"><div><div><h5 class="title"> |
---|
656 | <a name="lambda.nullary_functors_and_ret"></a>Nullary lambda functors and ret</h5></div></div></div> |
---|
657 | <p> |
---|
658 | As stated above, the effect of <code class="literal">ret</code> is to prevent the return type deduction to be performed. |
---|
659 | However, there is an exception. |
---|
660 | 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. |
---|
661 | This introduces a slight problem with <code class="literal">ret</code>, best described with an example: |
---|
662 | |
---|
663 | </p> |
---|
664 | <pre class="programlisting"> |
---|
665 | struct F { int operator()(int i) const; }; |
---|
666 | F f; |
---|
667 | ... |
---|
668 | bind(f, _1); // fails, cannot deduce the return type |
---|
669 | ret<int>(bind(f, _1)); // ok |
---|
670 | ... |
---|
671 | bind(f, 1); // fails, cannot deduce the return type |
---|
672 | ret<int>(bind(f, 1)); // fails as well! |
---|
673 | </pre> |
---|
674 | <p> |
---|
675 | The BLL cannot deduce the return types of the above bind calls, as <code class="literal">F</code> does not define the typedef <code class="literal">result_type</code>. |
---|
676 | One would expect <code class="literal">ret</code> to fix this, but for the nullary lambda functor that results from a bind expression (last line above) this does not work. |
---|
677 | The return type deduction templates are instantiated, even though it would not be necessary and the result is a compilation error. |
---|
678 | </p> |
---|
679 | <p>The solution to this is not to use the <code class="literal">ret</code> function, but rather define the return type as an explicitly specified template parameter in the <code class="literal">bind</code> call: |
---|
680 | </p> |
---|
681 | <pre class="programlisting"> |
---|
682 | bind<int>(f, 1); // ok |
---|
683 | </pre> |
---|
684 | <p> |
---|
685 | |
---|
686 | The lambda functors created with |
---|
687 | <code class="literal">ret<<em class="parameter"><code>T</code></em>>(bind(<em class="parameter"><code>arg-list</code></em>))</code> and |
---|
688 | <code class="literal">bind<<em class="parameter"><code>T</code></em>>(<em class="parameter"><code>arg-list</code></em>)</code> have the exact same functionality — |
---|
689 | apart from the fact that for some nullary lambda functors the former does not work while the latter does. |
---|
690 | </p> |
---|
691 | </div> |
---|
692 | </div> |
---|
693 | <div class="section" lang="en"> |
---|
694 | <div class="titlepage"><div><div><h4 class="title"> |
---|
695 | <a name="lambda.delaying_constants_and_variables"></a>Delaying constants and variables</h4></div></div></div> |
---|
696 | <p> |
---|
697 | The unary functions <code class="literal">constant</code>, |
---|
698 | <code class="literal">constant_ref</code> and <code class="literal">var</code> turn their argument into a lambda functor, that implements an identity mapping. |
---|
699 | The former two are for constants, the latter for variables. |
---|
700 | The use of these <span class="emphasis"><em>delayed</em></span> constants and variables is sometimes necessary due to the lack of explicit syntax for lambda expressions. |
---|
701 | For example: |
---|
702 | </p> |
---|
703 | <pre class="programlisting"> |
---|
704 | for_each(a.begin(), a.end(), cout << _1 << ' '); |
---|
705 | for_each(a.begin(), a.end(), cout << ' ' << _1); |
---|
706 | </pre> |
---|
707 | <p> |
---|
708 | The first line outputs the elements of <code class="literal">a</code> separated by spaces, while the second line outputs a space followed by the elements of <code class="literal">a</code> without any separators. |
---|
709 | The reason for this is that neither of the operands of |
---|
710 | <code class="literal">cout << ' '</code> is a lambda expression, hence <code class="literal">cout << ' '</code> is evaluated immediately. |
---|
711 | |
---|
712 | To delay the evaluation of <code class="literal">cout << ' '</code>, one of the operands must be explicitly marked as a lambda expression. |
---|
713 | This is accomplished with the <code class="literal">constant</code> function: |
---|
714 | </p> |
---|
715 | <pre class="programlisting"> |
---|
716 | for_each(a.begin(), a.end(), cout << constant(' ') << _1); |
---|
717 | </pre> |
---|
718 | <p> |
---|
719 | |
---|
720 | The call <code class="literal">constant(' ')</code> creates a nullary lambda functor which stores the character constant <code class="literal">' '</code> |
---|
721 | and returns a reference to it when invoked. |
---|
722 | The function <code class="literal">constant_ref</code> is similar, except that it |
---|
723 | stores a constant reference to its argument. |
---|
724 | |
---|
725 | The <code class="literal">constant</code> and <code class="literal">consant_ref</code> are only |
---|
726 | needed when the operator call has side effects, like in the above example. |
---|
727 | </p> |
---|
728 | <p> |
---|
729 | Sometimes we need to delay the evaluation of a variable. |
---|
730 | Suppose we wanted to output the elements of a container in a numbered list: |
---|
731 | |
---|
732 | </p> |
---|
733 | <pre class="programlisting"> |
---|
734 | int index = 0; |
---|
735 | for_each(a.begin(), a.end(), cout << ++index << ':' << _1 << '\n'); |
---|
736 | for_each(a.begin(), a.end(), cout << ++var(index) << ':' << _1 << '\n'); |
---|
737 | </pre> |
---|
738 | <p> |
---|
739 | |
---|
740 | The first <code class="literal">for_each</code> invocation does not do what we want; <code class="literal">index</code> is incremented only once, and its value is written into the output stream only once. |
---|
741 | By using <code class="literal">var</code> to make <code class="literal">index</code> a lambda expression, we get the desired effect. |
---|
742 | </p> |
---|
743 | <p> |
---|
744 | In sum, <code class="literal">var(x)</code> creates a nullary lambda functor, |
---|
745 | which stores a reference to the variable <code class="literal">x</code>. |
---|
746 | When the lambda functor is invoked, a reference to <code class="literal">x</code> is returned. |
---|
747 | </p> |
---|
748 | <div class="simplesect" lang="en"> |
---|
749 | <div class="titlepage"><div><div><h5 class="title"> |
---|
750 | <a name="id2710093"></a>Naming delayed constants and variables</h5></div></div></div> |
---|
751 | <p> |
---|
752 | It is possible to predefine and name a delayed variable or constant outside a lambda expression. |
---|
753 | The templates <code class="literal">var_type</code>, <code class="literal">constant_type</code> |
---|
754 | and <code class="literal">constant_ref_type</code> serve for this purpose. |
---|
755 | They are used as: |
---|
756 | </p> |
---|
757 | <pre class="programlisting"> |
---|
758 | var_type<T>::type delayed_i(var(i)); |
---|
759 | constant_type<T>::type delayed_c(constant(c)); |
---|
760 | </pre> |
---|
761 | <p> |
---|
762 | The first line defines the variable <code class="literal">delayed_i</code> which is a delayed version of the variable <code class="literal">i</code> of type <code class="literal">T</code>. |
---|
763 | Analogously, the second line defines the constant <code class="literal">delayed_c</code> as a delayed version of the constant <code class="literal">c</code>. |
---|
764 | For example: |
---|
765 | |
---|
766 | </p> |
---|
767 | <pre class="programlisting"> |
---|
768 | int i = 0; int j; |
---|
769 | for_each(a.begin(), a.end(), (var(j) = _1, _1 = var(i), var(i) = var(j))); |
---|
770 | </pre> |
---|
771 | <p> |
---|
772 | is equivalent to: |
---|
773 | </p> |
---|
774 | <pre class="programlisting"> |
---|
775 | int i = 0; int j; |
---|
776 | var_type<int>::type vi(var(i)), vj(var(j)); |
---|
777 | for_each(a.begin(), a.end(), (vj = _1, _1 = vi, vi = vj)); |
---|
778 | </pre> |
---|
779 | <p> |
---|
780 | Here is an example of naming a delayed constant: |
---|
781 | </p> |
---|
782 | <pre class="programlisting"> |
---|
783 | constant_type<char>::type space(constant(' ')); |
---|
784 | for_each(a.begin(),a.end(), cout << space << _1); |
---|
785 | </pre> |
---|
786 | </div> |
---|
787 | <div class="simplesect" lang="en"> |
---|
788 | <div class="titlepage"><div><div><h5 class="title"> |
---|
789 | <a name="id2710189"></a>About assignment and subscript operators</h5></div></div></div> |
---|
790 | <p> |
---|
791 | As described in <a href="le_in_details.html#lambda.assignment_and_subscript" title="Assignment and subscript operators">the section called “Assignment and subscript operators”</a>, assignment and subscripting operators are always defined as member functions. |
---|
792 | This means, that for expressions of the form |
---|
793 | <code class="literal">x = y</code> or <code class="literal">x[y]</code> to be interpreted as lambda expressions, the left-hand operand <code class="literal">x</code> must be a lambda expression. |
---|
794 | Consequently, it is sometimes necessary to use <code class="literal">var</code> for this purpose. |
---|
795 | We repeat the example from <a href="le_in_details.html#lambda.assignment_and_subscript" title="Assignment and subscript operators">the section called “Assignment and subscript operators”</a>: |
---|
796 | |
---|
797 | </p> |
---|
798 | <pre class="programlisting"> |
---|
799 | int i; |
---|
800 | i = _1; // error |
---|
801 | var(i) = _1; // ok |
---|
802 | </pre> |
---|
803 | <p> |
---|
804 | |
---|
805 | Note that the compound assignment operators <code class="literal">+=</code>, <code class="literal">-=</code> 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. |
---|
806 | Nevertheless, it is perfectly ok to delay the left operand explicitly. |
---|
807 | For example, <code class="literal">i += _1</code> is equivalent to <code class="literal">var(i) += _1</code>. |
---|
808 | </p> |
---|
809 | </div> |
---|
810 | </div> |
---|
811 | <div class="section" lang="en"> |
---|
812 | <div class="titlepage"><div><div><h4 class="title"> |
---|
813 | <a name="lambda.lambda_expressions_for_control_structures"></a>Lambda expressions for control structures</h4></div></div></div> |
---|
814 | <div class="toc"><dl><dt><span class="section"><a href="le_in_details.html#lambda.switch_statement">Switch statement</a></span></dt></dl></div> |
---|
815 | <p> |
---|
816 | BLL defines several functions to create lambda functors that represent control structures. |
---|
817 | They all take lambda functors as parameters and return <code class="literal">void</code>. |
---|
818 | To start with an example, the following code outputs all even elements of some container <code class="literal">a</code>: |
---|
819 | |
---|
820 | </p> |
---|
821 | <pre class="programlisting"> |
---|
822 | for_each(a.begin(), a.end(), |
---|
823 | if_then(_1 % 2 == 0, cout << _1)); |
---|
824 | </pre> |
---|
825 | <p> |
---|
826 | The BLL supports the following function templates for control structures: |
---|
827 | |
---|
828 | </p> |
---|
829 | <pre class="programlisting"> |
---|
830 | if_then(condition, then_part) |
---|
831 | if_then_else(condition, then_part, else_part) |
---|
832 | if_then_else_return(condition, then_part, else_part) |
---|
833 | while_loop(condition, body) |
---|
834 | while_loop(condition) // no body case |
---|
835 | do_while_loop(condition, body) |
---|
836 | do_while_loop(condition) // no body case |
---|
837 | for_loop(init, condition, increment, body) |
---|
838 | for_loop(init, condition, increment) // no body case |
---|
839 | switch_statement(...) |
---|
840 | </pre> |
---|
841 | <p> |
---|
842 | |
---|
843 | The return types of all control construct lambda functor is |
---|
844 | <code class="literal">void</code>, except for <code class="literal">if_then_else_return</code>, |
---|
845 | which wraps a call to the conditional operator |
---|
846 | </p> |
---|
847 | <pre class="programlisting"> |
---|
848 | condition ? then_part : else_part |
---|
849 | </pre> |
---|
850 | <p> |
---|
851 | The return type rules for this operator are somewhat complex. |
---|
852 | Basically, if the branches have the same type, this type is the return type. |
---|
853 | If the type of the branches differ, one branch, say of type |
---|
854 | <code class="literal">A</code>, must be convertible to the other branch, |
---|
855 | say of type <code class="literal">B</code>. |
---|
856 | In this situation, the result type is <code class="literal">B</code>. |
---|
857 | Further, if the common type is an lvalue, the return type will be an lvalue |
---|
858 | too. |
---|
859 | </p> |
---|
860 | <p> |
---|
861 | Delayed variables tend to be commonplace in control structure lambda expressions. |
---|
862 | For instance, here we use the <code class="literal">var</code> function to turn the arguments of <code class="literal">for_loop</code> into lambda expressions. |
---|
863 | The effect of the code is to add 1 to each element of a two-dimensional array: |
---|
864 | |
---|
865 | </p> |
---|
866 | <pre class="programlisting"> |
---|
867 | int a[5][10]; int i; |
---|
868 | for_each(a, a+5, |
---|
869 | for_loop(var(i)=0, var(i)<10, ++var(i), |
---|
870 | _1[var(i)] += 1)); |
---|
871 | </pre> |
---|
872 | <p> |
---|
873 | The BLL supports an alternative syntax for control expressions, suggested |
---|
874 | by Joel de Guzmann. |
---|
875 | By overloading the <code class="literal">operator[]</code> we can |
---|
876 | get a closer resemblance with the built-in control structures: |
---|
877 | |
---|
878 | </p> |
---|
879 | <pre class="programlisting"> |
---|
880 | if_(condition)[then_part] |
---|
881 | if_(condition)[then_part].else_[else_part] |
---|
882 | while_(condition)[body] |
---|
883 | do_[body].while_(condition) |
---|
884 | for_(init, condition, increment)[body] |
---|
885 | </pre> |
---|
886 | <p> |
---|
887 | |
---|
888 | For example, using this syntax the <code class="literal">if_then</code> example above |
---|
889 | can be written as: |
---|
890 | </p> |
---|
891 | <pre class="programlisting"> |
---|
892 | for_each(a.begin(), a.end(), |
---|
893 | if_(_1 % 2 == 0)[ cout << _1 ]) |
---|
894 | </pre> |
---|
895 | <p> |
---|
896 | |
---|
897 | As more experience is gained, we may end up deprecating one or the other |
---|
898 | of these syntaces. |
---|
899 | |
---|
900 | </p> |
---|
901 | <div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"> |
---|
902 | <a name="lambda.switch_statement"></a>Switch statement</h5></div></div></div></div> |
---|
903 | <p> |
---|
904 | The lambda expressions for <code class="literal">switch</code> control structures are more complex since the number of cases may vary. |
---|
905 | The general form of a switch lambda expression is: |
---|
906 | |
---|
907 | </p> |
---|
908 | <pre class="programlisting"> |
---|
909 | switch_statement(<em class="parameter"><code>condition</code></em>, |
---|
910 | case_statement<<em class="parameter"><code>label</code></em>>(<em class="parameter"><code>lambda expression</code></em>), |
---|
911 | case_statement<<em class="parameter"><code>label</code></em>>(<em class="parameter"><code>lambda expression</code></em>), |
---|
912 | ... |
---|
913 | default_statement(<em class="parameter"><code>lambda expression</code></em>) |
---|
914 | ) |
---|
915 | </pre> |
---|
916 | <p> |
---|
917 | |
---|
918 | The <code class="literal"><em class="parameter"><code>condition</code></em></code> argument must be a lambda expression that creates a lambda functor with an integral return type. |
---|
919 | The different cases are created with the <code class="literal">case_statement</code> functions, and the optional default case with the <code class="literal">default_statement</code> function. |
---|
920 | The case labels are given as explicitly specified template arguments to <code class="literal">case_statement</code> functions and |
---|
921 | <code class="literal">break</code> statements are implicitly part of each case. |
---|
922 | For example, <code class="literal">case_statement<1>(a)</code>, where <code class="literal">a</code> is some lambda functor, generates the code: |
---|
923 | |
---|
924 | </p> |
---|
925 | <pre class="programlisting"> |
---|
926 | case 1: |
---|
927 | <em class="parameter"><code>evaluate lambda functor</code></em> a; |
---|
928 | break; |
---|
929 | </pre> |
---|
930 | <p> |
---|
931 | The <code class="literal">switch_statement</code> function is specialized for up to 9 case statements. |
---|
932 | |
---|
933 | </p> |
---|
934 | <p> |
---|
935 | As a concrete example, the following code iterates over some container <code class="literal">v</code> and ouptuts “<span class="quote">zero</span>” for each <code class="literal">0</code>, “<span class="quote">one</span>” for each <code class="literal">1</code>, and “<span class="quote">other: <em class="parameter"><code>n</code></em></span>” for any other value <em class="parameter"><code>n</code></em>. |
---|
936 | Note that another lambda expression is sequenced after the <code class="literal">switch_statement</code> to output a line break after each element: |
---|
937 | |
---|
938 | </p> |
---|
939 | <pre class="programlisting"> |
---|
940 | std::for_each(v.begin(), v.end(), |
---|
941 | ( |
---|
942 | switch_statement( |
---|
943 | _1, |
---|
944 | case_statement<0>(std::cout << constant("zero")), |
---|
945 | case_statement<1>(std::cout << constant("one")), |
---|
946 | default_statement(cout << constant("other: ") << _1) |
---|
947 | ), |
---|
948 | cout << constant("\n") |
---|
949 | ) |
---|
950 | ); |
---|
951 | </pre> |
---|
952 | </div> |
---|
953 | <div class="section" lang="en"> |
---|
954 | <div class="titlepage"><div><div><h4 class="title"> |
---|
955 | <a name="lambda.exceptions"></a>Exceptions</h4></div></div></div> |
---|
956 | <p> |
---|
957 | The BLL provides lambda functors that throw and catch exceptions. |
---|
958 | Lambda functors for throwing exceptions are created with the unary function <code class="literal">throw_exception</code>. |
---|
959 | The argument to this function is the exception to be thrown, or a lambda functor which creates the exception to be thrown. |
---|
960 | A lambda functor for rethrowing exceptions is created with the nullary <code class="literal">rethrow</code> function. |
---|
961 | </p> |
---|
962 | <p> |
---|
963 | Lambda expressions for handling exceptions are somewhat more complex. |
---|
964 | The general form of a lambda expression for try catch blocks is as follows: |
---|
965 | |
---|
966 | </p> |
---|
967 | <pre class="programlisting"> |
---|
968 | try_catch( |
---|
969 | <em class="parameter"><code>lambda expression</code></em>, |
---|
970 | catch_exception<<em class="parameter"><code>type</code></em>>(<em class="parameter"><code>lambda expression</code></em>), |
---|
971 | catch_exception<<em class="parameter"><code>type</code></em>>(<em class="parameter"><code>lambda expression</code></em>), |
---|
972 | ... |
---|
973 | catch_all(<em class="parameter"><code>lambda expression</code></em>) |
---|
974 | ) |
---|
975 | </pre> |
---|
976 | <p> |
---|
977 | |
---|
978 | The first lambda expression is the try block. |
---|
979 | Each <code class="literal">catch_exception</code> defines a catch block where the |
---|
980 | explicitly specified template argument defines the type of the exception |
---|
981 | to catch. |
---|
982 | |
---|
983 | The lambda expression within the <code class="literal">catch_exception</code> defines |
---|
984 | the actions to take if the exception is caught. |
---|
985 | |
---|
986 | Note that the resulting exception handlers catch the exceptions as |
---|
987 | references, i.e., <code class="literal">catch_exception<T>(...)</code> |
---|
988 | results in the catch block: |
---|
989 | |
---|
990 | </p> |
---|
991 | <pre class="programlisting"> |
---|
992 | catch(T& e) { ... } |
---|
993 | </pre> |
---|
994 | <p> |
---|
995 | |
---|
996 | The last catch block can alternatively be a call to |
---|
997 | <code class="literal">catch_exception<<em class="parameter"><code>type</code></em>></code> |
---|
998 | or to |
---|
999 | <code class="literal">catch_all</code>, which is the lambda expression equivalent to |
---|
1000 | <code class="literal">catch(...)</code>. |
---|
1001 | |
---|
1002 | </p> |
---|
1003 | <p> |
---|
1004 | |
---|
1005 | The <a href="le_in_details.html#ex:exceptions" title="Example 6.1. Throwing and handling exceptions in lambda expressions.">Example 6.1, “Throwing and handling exceptions in lambda expressions.”</a> demonstrates the use of the BLL |
---|
1006 | exception handling tools. |
---|
1007 | The first handler catches exceptions of type <code class="literal">foo_exception</code>. |
---|
1008 | Note the use of <code class="literal">_1</code> placeholder in the body of the handler. |
---|
1009 | </p> |
---|
1010 | <p> |
---|
1011 | The second handler shows how to throw exceptions, and demonstrates the |
---|
1012 | use of the <span class="emphasis"><em>exception placeholder</em></span><code class="literal">_e</code>. |
---|
1013 | |
---|
1014 | It is a special placeholder, which refers to the caught exception object |
---|
1015 | within the handler body. |
---|
1016 | |
---|
1017 | Here we are handling an exception of type <code class="literal">std::exception</code>, |
---|
1018 | which carries a string explaining the cause of the exception. |
---|
1019 | |
---|
1020 | This explanation can be queried with the zero-argument member |
---|
1021 | function <code class="literal">what</code>. |
---|
1022 | |
---|
1023 | The expression |
---|
1024 | <code class="literal">bind(&std::exception::what, _e)</code> creates the lambda |
---|
1025 | function for making that call. |
---|
1026 | |
---|
1027 | Note that <code class="literal">_e</code> cannot be used outside of an exception handler lambda expression. |
---|
1028 | |
---|
1029 | |
---|
1030 | The last line of the second handler constructs a new exception object and |
---|
1031 | throws that with <code class="literal">throw exception</code>. |
---|
1032 | |
---|
1033 | Constructing and destructing objects within lambda expressions is |
---|
1034 | explained in <a href="le_in_details.html#lambda.construction_and_destruction" title="Construction and destruction">the section called “Construction and destruction”</a></p> |
---|
1035 | <p> |
---|
1036 | Finally, the third handler (<code class="literal">catch_all</code>) demonstrates |
---|
1037 | rethrowing exceptions. |
---|
1038 | </p> |
---|
1039 | <div class="example"> |
---|
1040 | <a name="ex:exceptions"></a><p class="title"><b>Example 6.1. Throwing and handling exceptions in lambda expressions.</b></p> |
---|
1041 | <pre class="programlisting"> |
---|
1042 | for_each( |
---|
1043 | a.begin(), a.end(), |
---|
1044 | try_catch( |
---|
1045 | bind(foo, _1), // foo may throw |
---|
1046 | catch_exception<foo_exception>( |
---|
1047 | cout << constant("Caught foo_exception: ") |
---|
1048 | << "foo was called with argument = " << _1 |
---|
1049 | ), |
---|
1050 | catch_exception<std::exception>( |
---|
1051 | cout << constant("Caught std::exception: ") |
---|
1052 | << bind(&std::exception::what, _e), |
---|
1053 | throw_exception(bind(constructor<bar_exception>(), _1))) |
---|
1054 | ), |
---|
1055 | catch_all( |
---|
1056 | (cout << constant("Unknown"), rethrow()) |
---|
1057 | ) |
---|
1058 | ) |
---|
1059 | ); |
---|
1060 | </pre> |
---|
1061 | </div> |
---|
1062 | </div> |
---|
1063 | <div class="section" lang="en"> |
---|
1064 | <div class="titlepage"><div><div><h4 class="title"> |
---|
1065 | <a name="lambda.construction_and_destruction"></a>Construction and destruction</h4></div></div></div> |
---|
1066 | <p> |
---|
1067 | Operators <code class="literal">new</code> and <code class="literal">delete</code> can be |
---|
1068 | overloaded, but their return types are fixed. |
---|
1069 | |
---|
1070 | Particularly, the return types cannot be lambda functors, |
---|
1071 | which prevents them to be overloaded for lambda expressions. |
---|
1072 | |
---|
1073 | It is not possible to take the address of a constructor, |
---|
1074 | hence constructors cannot be used as target functions in bind expressions. |
---|
1075 | |
---|
1076 | The same is true for destructors. |
---|
1077 | |
---|
1078 | As a way around these constraints, BLL defines wrapper classes for |
---|
1079 | <code class="literal">new</code> and <code class="literal">delete</code> calls, |
---|
1080 | as well as for constructors and destructors. |
---|
1081 | |
---|
1082 | Instances of these classes are function objects, that can be used as |
---|
1083 | target functions of bind expressions. |
---|
1084 | |
---|
1085 | For example: |
---|
1086 | |
---|
1087 | </p> |
---|
1088 | <pre class="programlisting"> |
---|
1089 | int* a[10]; |
---|
1090 | for_each(a, a+10, _1 = bind(new_ptr<int>())); |
---|
1091 | for_each(a, a+10, bind(delete_ptr(), _1)); |
---|
1092 | </pre> |
---|
1093 | <p> |
---|
1094 | |
---|
1095 | The <code class="literal">new_ptr<int>()</code> expression creates |
---|
1096 | a function object that calls <code class="literal">new int()</code> when invoked, |
---|
1097 | and wrapping that inside <code class="literal">bind</code> makes it a lambda functor. |
---|
1098 | |
---|
1099 | In the same way, the expression <code class="literal">delete_ptr()</code> creates |
---|
1100 | a function object that invokes <code class="literal">delete</code> on its argument. |
---|
1101 | |
---|
1102 | Note that <code class="literal">new_ptr<<em class="parameter"><code>T</code></em>>()</code> |
---|
1103 | can take arguments as well. |
---|
1104 | |
---|
1105 | They are passed directly to the constructor invocation and thus allow |
---|
1106 | calls to constructors which take arguments. |
---|
1107 | |
---|
1108 | </p> |
---|
1109 | <p> |
---|
1110 | |
---|
1111 | As an example of constructor calls in lambda expressions, |
---|
1112 | the following code reads integers from two containers <code class="literal">x</code> |
---|
1113 | and <code class="literal">y</code>, |
---|
1114 | constructs pairs out of them and inserts them into a third container: |
---|
1115 | |
---|
1116 | </p> |
---|
1117 | <pre class="programlisting"> |
---|
1118 | vector<pair<int, int> > v; |
---|
1119 | transform(x.begin(), x.end(), y.begin(), back_inserter(v), |
---|
1120 | bind(constructor<pair<int, int> >(), _1, _2)); |
---|
1121 | </pre> |
---|
1122 | <p><a href="le_in_details.html#table:constructor_destructor_fos" title="Table 6.1. Construction and destruction related function objects.">Table 6.1, “Construction and destruction related function objects.”</a> lists all the function |
---|
1123 | objects related to creating and destroying objects, |
---|
1124 | showing the expression to create and call the function object, |
---|
1125 | and the effect of evaluating that expression. |
---|
1126 | |
---|
1127 | </p> |
---|
1128 | <div class="table"> |
---|
1129 | <a name="table:constructor_destructor_fos"></a><p class="title"><b>Table 6.1. Construction and destruction related function objects.</b></p> |
---|
1130 | <table class="table" summary="Construction and destruction related function objects."> |
---|
1131 | <colgroup> |
---|
1132 | <col> |
---|
1133 | <col> |
---|
1134 | </colgroup> |
---|
1135 | <thead><tr> |
---|
1136 | <th>Function object call</th> |
---|
1137 | <th>Wrapped expression</th> |
---|
1138 | </tr></thead> |
---|
1139 | <tbody> |
---|
1140 | <tr> |
---|
1141 | <td><code class="literal">constructor<T>()(<em class="parameter"><code>arg_list</code></em>)</code></td> |
---|
1142 | <td>T(<em class="parameter"><code>arg_list</code></em>)</td> |
---|
1143 | </tr> |
---|
1144 | <tr> |
---|
1145 | <td><code class="literal">destructor()(a)</code></td> |
---|
1146 | <td> |
---|
1147 | <code class="literal">a.~A()</code>, where <code class="literal">a</code> is of type <code class="literal">A</code> |
---|
1148 | </td> |
---|
1149 | </tr> |
---|
1150 | <tr> |
---|
1151 | <td><code class="literal">destructor()(pa)</code></td> |
---|
1152 | <td> |
---|
1153 | <code class="literal">pa->~A()</code>, where <code class="literal">pa</code> is of type <code class="literal">A*</code> |
---|
1154 | </td> |
---|
1155 | </tr> |
---|
1156 | <tr> |
---|
1157 | <td><code class="literal">new_ptr<T>()(<em class="parameter"><code>arg_list</code></em>)</code></td> |
---|
1158 | <td><code class="literal">new T(<em class="parameter"><code>arg_list</code></em>)</code></td> |
---|
1159 | </tr> |
---|
1160 | <tr> |
---|
1161 | <td><code class="literal">new_array<T>()(sz)</code></td> |
---|
1162 | <td><code class="literal">new T[sz]</code></td> |
---|
1163 | </tr> |
---|
1164 | <tr> |
---|
1165 | <td><code class="literal">delete_ptr()(p)</code></td> |
---|
1166 | <td><code class="literal">delete p</code></td> |
---|
1167 | </tr> |
---|
1168 | <tr> |
---|
1169 | <td><code class="literal">delete_array()(p)</code></td> |
---|
1170 | <td><code class="literal">delete p[]</code></td> |
---|
1171 | </tr> |
---|
1172 | </tbody> |
---|
1173 | </table> |
---|
1174 | </div> |
---|
1175 | </div> |
---|
1176 | <div class="section" lang="en"> |
---|
1177 | <div class="titlepage"><div><div><h4 class="title"> |
---|
1178 | <a name="id2711160"></a>Special lambda expressions</h4></div></div></div> |
---|
1179 | <div class="toc"><dl> |
---|
1180 | <dt><span class="section"><a href="le_in_details.html#id2711164">Preventing argument substitution</a></span></dt> |
---|
1181 | <dt><span class="section"><a href="le_in_details.html#lambda.rvalues_as_actual_arguments">Rvalues as actual arguments to lambda functors</a></span></dt> |
---|
1182 | </dl></div> |
---|
1183 | <div class="section" lang="en"> |
---|
1184 | <div class="titlepage"><div><div><h5 class="title"> |
---|
1185 | <a name="id2711164"></a>Preventing argument substitution</h5></div></div></div> |
---|
1186 | <div class="toc"><dl> |
---|
1187 | <dt><span class="section"><a href="le_in_details.html#lambda.unlambda">Unlambda</a></span></dt> |
---|
1188 | <dt><span class="section"><a href="le_in_details.html#id2711372">Protect</a></span></dt> |
---|
1189 | </dl></div> |
---|
1190 | <p> |
---|
1191 | When a lambda functor is called, the default behavior is to substitute |
---|
1192 | the actual arguments for the placeholders within all subexpressions. |
---|
1193 | |
---|
1194 | This section describes the tools to prevent the substitution and |
---|
1195 | evaluation of a subexpression, and explains when these tools should be used. |
---|
1196 | </p> |
---|
1197 | <p> |
---|
1198 | The arguments to a bind expression can be arbitrary lambda expressions, |
---|
1199 | e.g., other bind expressions. |
---|
1200 | |
---|
1201 | For example: |
---|
1202 | |
---|
1203 | </p> |
---|
1204 | <pre class="programlisting"> |
---|
1205 | int foo(int); int bar(int); |
---|
1206 | ... |
---|
1207 | int i; |
---|
1208 | bind(foo, bind(bar, _1)(i); |
---|
1209 | </pre> |
---|
1210 | <p> |
---|
1211 | |
---|
1212 | The last line makes the call <code class="literal">foo(bar(i));</code> |
---|
1213 | |
---|
1214 | Note that the first argument in a bind expression, the target function, |
---|
1215 | is no exception, and can thus be a bind expression too. |
---|
1216 | |
---|
1217 | The innermost lambda functor just has to return something that can be used |
---|
1218 | as a target function: another lambda functor, function pointer, |
---|
1219 | pointer to member function etc. |
---|
1220 | |
---|
1221 | For example, in the following code the innermost lambda functor makes |
---|
1222 | a selection between two functions, and returns a pointer to one of them: |
---|
1223 | |
---|
1224 | </p> |
---|
1225 | <pre class="programlisting"> |
---|
1226 | int add(int a, int b) { return a+b; } |
---|
1227 | int mul(int a, int b) { return a*b; } |
---|
1228 | |
---|
1229 | int(*)(int, int) add_or_mul(bool x) { |
---|
1230 | return x ? add : mul; |
---|
1231 | } |
---|
1232 | |
---|
1233 | bool condition; int i; int j; |
---|
1234 | ... |
---|
1235 | bind(bind(&add_or_mul, _1), _2, _3)(condition, i, j); |
---|
1236 | </pre> |
---|
1237 | <div class="section" lang="en"> |
---|
1238 | <div class="titlepage"><div><div><h6 class="title"> |
---|
1239 | <a name="lambda.unlambda"></a>Unlambda</h6></div></div></div> |
---|
1240 | <p>A nested bind expression may occur inadvertently, |
---|
1241 | if the target function is a variable with a type that depends on a |
---|
1242 | template parameter. |
---|
1243 | |
---|
1244 | Typically the target function could be a formal parameter of a |
---|
1245 | function template. |
---|
1246 | |
---|
1247 | In such a case, the programmer may not know whether the target function is a lambda functor or not. |
---|
1248 | </p> |
---|
1249 | <p>Consider the following function template: |
---|
1250 | |
---|
1251 | </p> |
---|
1252 | <pre class="programlisting"> |
---|
1253 | template<class F> |
---|
1254 | int nested(const F& f) { |
---|
1255 | int x; |
---|
1256 | ... |
---|
1257 | bind(f, _1)(x); |
---|
1258 | ... |
---|
1259 | } |
---|
1260 | </pre> |
---|
1261 | <p> |
---|
1262 | |
---|
1263 | Somewhere inside the function the formal parameter |
---|
1264 | <code class="literal">f</code> is used as a target function in a bind expression. |
---|
1265 | |
---|
1266 | In order for this <code class="literal">bind</code> call to be valid, |
---|
1267 | <code class="literal">f</code> must be a unary function. |
---|
1268 | |
---|
1269 | Suppose the following two calls to <code class="literal">nested</code> are made: |
---|
1270 | |
---|
1271 | </p> |
---|
1272 | <pre class="programlisting"> |
---|
1273 | int foo(int); |
---|
1274 | int bar(int, int); |
---|
1275 | nested(&foo); |
---|
1276 | nested(bind(bar, 1, _1)); |
---|
1277 | </pre> |
---|
1278 | <p> |
---|
1279 | |
---|
1280 | Both are unary functions, or function objects, with appropriate argument |
---|
1281 | and return types, but the latter will not compile. |
---|
1282 | |
---|
1283 | In the latter call, the bind expression inside <code class="literal">nested</code> |
---|
1284 | will become: |
---|
1285 | |
---|
1286 | </p> |
---|
1287 | <pre class="programlisting"> |
---|
1288 | bind(bind(bar, 1, _1), _1) |
---|
1289 | </pre> |
---|
1290 | <p> |
---|
1291 | |
---|
1292 | When this is invoked with <code class="literal">x</code>, |
---|
1293 | after substituitions we end up trying to call |
---|
1294 | |
---|
1295 | </p> |
---|
1296 | <pre class="programlisting"> |
---|
1297 | bar(1, x)(x) |
---|
1298 | </pre> |
---|
1299 | <p> |
---|
1300 | |
---|
1301 | which is an error. |
---|
1302 | |
---|
1303 | The call to <code class="literal">bar</code> returns int, |
---|
1304 | not a unary function or function object. |
---|
1305 | </p> |
---|
1306 | <p> |
---|
1307 | In the example above, the intent of the bind expression in the |
---|
1308 | <code class="literal">nested</code> function is to treat <code class="literal">f</code> |
---|
1309 | as an ordinary function object, instead of a lambda functor. |
---|
1310 | |
---|
1311 | The BLL provides the function template <code class="literal">unlambda</code> to |
---|
1312 | express this: a lambda functor wrapped inside <code class="literal">unlambda</code> |
---|
1313 | is not a lambda functor anymore, and does not take part into the |
---|
1314 | argument substitution process. |
---|
1315 | |
---|
1316 | Note that for all other argument types <code class="literal">unlambda</code> is |
---|
1317 | an identity operation, except for making non-const objects const. |
---|
1318 | </p> |
---|
1319 | <p> |
---|
1320 | Using <code class="literal">unlambda</code>, the <code class="literal">nested</code> |
---|
1321 | function is written as: |
---|
1322 | |
---|
1323 | </p> |
---|
1324 | <pre class="programlisting"> |
---|
1325 | template<class F> |
---|
1326 | int nested(const F& f) { |
---|
1327 | int x; |
---|
1328 | ... |
---|
1329 | bind(unlambda(f), _1)(x); |
---|
1330 | ... |
---|
1331 | } |
---|
1332 | </pre> |
---|
1333 | </div> |
---|
1334 | <div class="section" lang="en"> |
---|
1335 | <div class="titlepage"><div><div><h6 class="title"> |
---|
1336 | <a name="id2711372"></a>Protect</h6></div></div></div> |
---|
1337 | <p> |
---|
1338 | The <code class="literal">protect</code> function is related to unlambda. |
---|
1339 | |
---|
1340 | It is also used to prevent the argument substitution taking place, |
---|
1341 | but whereas <code class="literal">unlambda</code> turns a lambda functor into |
---|
1342 | an ordinary function object for good, <code class="literal">protect</code> does |
---|
1343 | this temporarily, for just one evaluation round. |
---|
1344 | |
---|
1345 | For example: |
---|
1346 | |
---|
1347 | </p> |
---|
1348 | <pre class="programlisting"> |
---|
1349 | int x = 1, y = 10; |
---|
1350 | (_1 + protect(_1 + 2))(x)(y); |
---|
1351 | </pre> |
---|
1352 | <p> |
---|
1353 | |
---|
1354 | The first call substitutes <code class="literal">x</code> for the leftmost |
---|
1355 | <code class="literal">_1</code>, and results in another lambda functor |
---|
1356 | <code class="literal">x + (_1 + 2)</code>, which after the call with |
---|
1357 | <code class="literal">y</code> becomes <code class="literal">x + (y + 2)</code>, |
---|
1358 | and thus finally 13. |
---|
1359 | </p> |
---|
1360 | <p> |
---|
1361 | Primary motivation for including <code class="literal">protect</code> into the library, |
---|
1362 | was to allow nested STL algorithm invocations |
---|
1363 | (<a href="le_in_details.html#lambda.nested_stl_algorithms" title="Nesting STL algorithm invocations">the section called “Nesting STL algorithm invocations”</a>). |
---|
1364 | </p> |
---|
1365 | </div> |
---|
1366 | </div> |
---|
1367 | <div class="section" lang="en"> |
---|
1368 | <div class="titlepage"><div><div><h5 class="title"> |
---|
1369 | <a name="lambda.rvalues_as_actual_arguments"></a>Rvalues as actual arguments to lambda functors</h5></div></div></div> |
---|
1370 | <p> |
---|
1371 | Actual arguments to the lambda functors cannot be non-const rvalues. |
---|
1372 | This is due to a deliberate design decision: either we have this restriction, |
---|
1373 | or there can be no side-effects to the actual arguments. |
---|
1374 | |
---|
1375 | There are ways around this limitation. |
---|
1376 | |
---|
1377 | We repeat the example from section |
---|
1378 | <a href="using_library.html#lambda.actual_arguments_to_lambda_functors" title="About actual arguments to lambda functors">the section called “About actual arguments to lambda functors”</a> and list the |
---|
1379 | different solutions: |
---|
1380 | |
---|
1381 | </p> |
---|
1382 | <pre class="programlisting"> |
---|
1383 | int i = 1; int j = 2; |
---|
1384 | (_1 + _2)(i, j); // ok |
---|
1385 | (_1 + _2)(1, 2); // error (!) |
---|
1386 | </pre> |
---|
1387 | <div class="orderedlist"><ol type="1"> |
---|
1388 | <li><p> |
---|
1389 | If the rvalue is of a class type, the return type of the function that |
---|
1390 | creates the rvalue should be defined as const. |
---|
1391 | Due to an unfortunate language restriction this does not work for |
---|
1392 | built-in types, as built-in rvalues cannot be const qualified. |
---|
1393 | </p></li> |
---|
1394 | <li> |
---|
1395 | <p> |
---|
1396 | If the lambda function call is accessible, the <code class="literal">make_const</code> |
---|
1397 | function can be used to <span class="emphasis"><em>constify</em></span> the rvalue. E.g.: |
---|
1398 | |
---|
1399 | </p> |
---|
1400 | <pre class="programlisting"> |
---|
1401 | (_1 + _2)(make_const(1), make_const(2)); // ok |
---|
1402 | </pre> |
---|
1403 | <p> |
---|
1404 | |
---|
1405 | Commonly the lambda function call site is inside a standard algorithm |
---|
1406 | function template, preventing this solution to be used. |
---|
1407 | |
---|
1408 | </p> |
---|
1409 | </li> |
---|
1410 | <li> |
---|
1411 | <p> |
---|
1412 | If neither of the above is possible, the lambda expression can be wrapped |
---|
1413 | in a <code class="literal">const_parameters</code> function. |
---|
1414 | It creates another type of lambda functor, which takes its arguments as |
---|
1415 | const references. For example: |
---|
1416 | |
---|
1417 | </p> |
---|
1418 | <pre class="programlisting"> |
---|
1419 | const_parameters(_1 + _2)(1, 2); // ok |
---|
1420 | </pre> |
---|
1421 | <p> |
---|
1422 | |
---|
1423 | Note that <code class="literal">const_parameters</code> makes all arguments const. |
---|
1424 | Hence, in the case were one of the arguments is a non-const rvalue, |
---|
1425 | and another argument needs to be passed as a non-const reference, |
---|
1426 | this approach cannot be used. |
---|
1427 | </p> |
---|
1428 | </li> |
---|
1429 | <li> |
---|
1430 | <p>If none of the above is possible, there is still one solution, |
---|
1431 | which unfortunately can break const correctness. |
---|
1432 | |
---|
1433 | The solution is yet another lambda functor wrapper, which we have named |
---|
1434 | <code class="literal">break_const</code> to alert the user of the potential dangers |
---|
1435 | of this function. |
---|
1436 | |
---|
1437 | The <code class="literal">break_const</code> function creates a lambda functor that |
---|
1438 | takes its arguments as const, and casts away constness prior to the call |
---|
1439 | to the original wrapped lambda functor. |
---|
1440 | |
---|
1441 | For example: |
---|
1442 | </p> |
---|
1443 | <pre class="programlisting"> |
---|
1444 | int i; |
---|
1445 | ... |
---|
1446 | (_1 += _2)(i, 2); // error, 2 is a non-const rvalue |
---|
1447 | const_parameters(_1 += _2)(i, 2); // error, i becomes const |
---|
1448 | break_const(_1 += _2)(i, 2); // ok, but dangerous |
---|
1449 | </pre> |
---|
1450 | <p> |
---|
1451 | |
---|
1452 | Note, that the results of <code class="literal"> break_const</code> or |
---|
1453 | <code class="literal">const_parameters</code> are not lambda functors, |
---|
1454 | so they cannot be used as subexpressions of lambda expressions. For instance: |
---|
1455 | |
---|
1456 | </p> |
---|
1457 | <pre class="programlisting"> |
---|
1458 | break_const(_1 + _2) + _3; // fails. |
---|
1459 | const_parameters(_1 + _2) + _3; // fails. |
---|
1460 | </pre> |
---|
1461 | <p> |
---|
1462 | |
---|
1463 | However, this kind of code should never be necessary, |
---|
1464 | since calls to sub lambda functors are made inside the BLL, |
---|
1465 | and are not affected by the non-const rvalue problem. |
---|
1466 | </p> |
---|
1467 | </li> |
---|
1468 | </ol></div> |
---|
1469 | </div> |
---|
1470 | </div> |
---|
1471 | <div class="section" lang="en"> |
---|
1472 | <div class="titlepage"><div><div><h4 class="title"> |
---|
1473 | <a name="id2711604"></a>Casts, sizeof and typeid</h4></div></div></div> |
---|
1474 | <div class="toc"><dl> |
---|
1475 | <dt><span class="section"><a href="le_in_details.html#lambda.cast_expressions"> |
---|
1476 | Cast expressions |
---|
1477 | </a></span></dt> |
---|
1478 | <dt><span class="section"><a href="le_in_details.html#id2711683">Sizeof and typeid</a></span></dt> |
---|
1479 | </dl></div> |
---|
1480 | <div class="section" lang="en"> |
---|
1481 | <div class="titlepage"><div><div><h5 class="title"> |
---|
1482 | <a name="lambda.cast_expressions"></a> |
---|
1483 | Cast expressions |
---|
1484 | </h5></div></div></div> |
---|
1485 | <p> |
---|
1486 | The BLL defines its counterparts for the four cast expressions |
---|
1487 | <code class="literal">static_cast</code>, <code class="literal">dynamic_cast</code>, |
---|
1488 | <code class="literal">const_cast</code> and <code class="literal">reinterpret_cast</code>. |
---|
1489 | |
---|
1490 | The BLL versions of the cast expressions have the prefix |
---|
1491 | <code class="literal">ll_</code>. |
---|
1492 | |
---|
1493 | The type to cast to is given as an explicitly specified template argument, |
---|
1494 | and the sole argument is the expression from which to perform the cast. |
---|
1495 | |
---|
1496 | If the argument is a lambda functor, the lambda functor is evaluated first. |
---|
1497 | |
---|
1498 | For example, the following code uses <code class="literal">ll_dynamic_cast</code> |
---|
1499 | to count the number of <code class="literal">derived</code> instances in the container |
---|
1500 | <code class="literal">a</code>: |
---|
1501 | |
---|
1502 | </p> |
---|
1503 | <pre class="programlisting"> |
---|
1504 | class base {}; |
---|
1505 | class derived : public base {}; |
---|
1506 | |
---|
1507 | vector<base*> a; |
---|
1508 | ... |
---|
1509 | int count = 0; |
---|
1510 | for_each(a.begin(), a.end(), |
---|
1511 | if_then(ll_dynamic_cast<derived*>(_1), ++var(count))); |
---|
1512 | </pre> |
---|
1513 | </div> |
---|
1514 | <div class="section" lang="en"> |
---|
1515 | <div class="titlepage"><div><div><h5 class="title"> |
---|
1516 | <a name="id2711683"></a>Sizeof and typeid</h5></div></div></div> |
---|
1517 | <p> |
---|
1518 | The BLL counterparts for these expressions are named |
---|
1519 | <code class="literal">ll_sizeof</code> and <code class="literal">ll_typeid</code>. |
---|
1520 | |
---|
1521 | Both take one argument, which can be a lambda expression. |
---|
1522 | The lambda functor created wraps the <code class="literal">sizeof</code> or |
---|
1523 | <code class="literal">typeid</code> call, and when the lambda functor is called |
---|
1524 | the wrapped operation is performed. |
---|
1525 | |
---|
1526 | For example: |
---|
1527 | |
---|
1528 | </p> |
---|
1529 | <pre class="programlisting"> |
---|
1530 | vector<base*> a; |
---|
1531 | ... |
---|
1532 | for_each(a.begin(), a.end(), |
---|
1533 | cout << bind(&type_info::name, ll_typeid(*_1))); |
---|
1534 | </pre> |
---|
1535 | <p> |
---|
1536 | |
---|
1537 | Here <code class="literal">ll_typeid</code> creates a lambda functor for |
---|
1538 | calling <code class="literal">typeid</code> for each element. |
---|
1539 | |
---|
1540 | The result of a <code class="literal">typeid</code> call is an instance of |
---|
1541 | the <code class="literal">type_info</code> class, and the bind expression creates |
---|
1542 | a lambda functor for calling the <code class="literal">name</code> member |
---|
1543 | function of that class. |
---|
1544 | |
---|
1545 | </p> |
---|
1546 | </div> |
---|
1547 | </div> |
---|
1548 | <div class="section" lang="en"> |
---|
1549 | <div class="titlepage"><div><div><h4 class="title"> |
---|
1550 | <a name="lambda.nested_stl_algorithms"></a>Nesting STL algorithm invocations</h4></div></div></div> |
---|
1551 | <p> |
---|
1552 | The BLL defines common STL algorithms as function object classes, |
---|
1553 | instances of which can be used as target functions in bind expressions. |
---|
1554 | For example, the following code iterates over the elements of a |
---|
1555 | two-dimensional array, and computes their sum. |
---|
1556 | |
---|
1557 | </p> |
---|
1558 | <pre class="programlisting"> |
---|
1559 | int a[100][200]; |
---|
1560 | int sum = 0; |
---|
1561 | |
---|
1562 | std::for_each(a, a + 100, |
---|
1563 | bind(ll::for_each(), _1, _1 + 200, protect(sum += _1))); |
---|
1564 | </pre> |
---|
1565 | <p> |
---|
1566 | |
---|
1567 | 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 <code class="literal">std</code> namespace. |
---|
1568 | All these structs are placed in the subnamespace <code class="literal">boost::lambda:ll</code>. |
---|
1569 | </p> |
---|
1570 | <p> |
---|
1571 | Note that there is no easy way to express an overloaded member function |
---|
1572 | call in a lambda expression. |
---|
1573 | |
---|
1574 | This limits the usefulness of nested STL algorithms, as for instance |
---|
1575 | the <code class="literal">begin</code> function has more than one overloaded |
---|
1576 | definitions in container templates. |
---|
1577 | |
---|
1578 | In general, something analogous to the pseudo-code below cannot be written: |
---|
1579 | |
---|
1580 | </p> |
---|
1581 | <pre class="programlisting"> |
---|
1582 | std::for_each(a.begin(), a.end(), |
---|
1583 | bind(ll::for_each(), _1.begin(), _1.end(), protect(sum += _1))); |
---|
1584 | </pre> |
---|
1585 | <p> |
---|
1586 | |
---|
1587 | Some aid for common special cases can be provided though. |
---|
1588 | |
---|
1589 | The BLL defines two helper function object classes, |
---|
1590 | <code class="literal">call_begin</code> and <code class="literal">call_end</code>, |
---|
1591 | which wrap a call to the <code class="literal">begin</code> and, respectively, |
---|
1592 | <code class="literal">end</code> functions of a container, and return the |
---|
1593 | <code class="literal">const_iterator</code> type of the container. |
---|
1594 | |
---|
1595 | With these helper templates, the above code becomes: |
---|
1596 | </p> |
---|
1597 | <pre class="programlisting"> |
---|
1598 | std::for_each(a.begin(), a.end(), |
---|
1599 | bind(ll::for_each(), |
---|
1600 | bind(call_begin(), _1), bind(call_end(), _1), |
---|
1601 | protect(sum += _1))); |
---|
1602 | </pre> |
---|
1603 | </div> |
---|
1604 | </div> |
---|
1605 | <table width="100%"><tr> |
---|
1606 | <td align="left"></td> |
---|
1607 | <td align="right"><small>Copyright © 1999-2004 Jaakko Järvi, Gary Powell</small></td> |
---|
1608 | </tr></table> |
---|
1609 | <hr> |
---|
1610 | <div class="spirit-nav"> |
---|
1611 | <a accesskey="p" href="using_library.html"><img src="../images/prev.png" alt="Prev"></a><a accesskey="u" href="../lambda.html"><img src="../images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../images/home.png" alt="Home"></a><a accesskey="n" href="extending.html"><img src="../images/next.png" alt="Next"></a> |
---|
1612 | </div> |
---|
1613 | </body> |
---|
1614 | </html> |
---|