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