summaryrefslogtreecommitdiff
path: root/libstdc++-v3/doc/html/ext/lwg-defects.html
blob: c1a3c780b6b1840f6a6527573234f322de677034 (plain) 
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
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392
5393
5394
5395
5396
5397
5398
5399
5400
5401
5402
5403
5404
5405
5406
5407
5408
5409
5410
5411
5412
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
5431
5432
5433
5434
5435
5436
5437
5438
5439
5440
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
5468
5469
5470
5471
5472
5473
5474
5475
5476
5477
5478
5479
5480
5481
5482
5483
5484
5485
5486
5487
5488
5489
5490
5491
5492
5493
5494
5495
5496
5497
5498
5499
5500
5501
5502
5503
5504
5505
5506
5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
5529
5530
5531
5532
5533
5534
5535
5536
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
5570
5571
5572
5573
5574
5575
5576
5577
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
5638
5639
5640
5641
5642
5643
5644
5645
5646
5647
5648
5649
5650
5651
5652
5653
5654
5655
5656
5657
5658
5659
5660
5661
5662
5663
5664
5665
5666
5667
5668
5669
5670
5671
5672
5673
5674
5675
5676
5677
5678
5679
5680
5681
5682
5683
5684
5685
5686
5687
5688
5689
5690
5691
5692
5693
5694
5695
5696
5697
5698
5699
5700
5701
5702
5703
5704
5705
5706
5707
5708
5709
5710
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
5723
5724
5725
5726
5727
5728
5729
5730
5731
5732
5733
5734
5735
5736
5737
5738
5739
5740
5741
5742
5743
5744
5745
5746
5747
5748
5749
5750
5751
5752
5753
5754
5755
5756
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
5767
5768
5769
5770
5771
5772
5773
5774
5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
5788
5789
5790
5791
5792
5793
5794
5795
5796
5797
5798
5799
5800
5801
5802
5803
5804
5805
5806
5807
5808
5809
5810
5811
5812
5813
5814
5815
5816
5817
5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
5837
5838
5839
5840
5841
5842
5843
5844
5845
5846
5847
5848
5849
5850
5851
5852
5853
5854
5855
5856
5857
5858
5859
5860
5861
5862
5863
5864
5865
5866
5867
5868
5869
5870
5871
5872
5873
5874
5875
5876
5877
5878
5879
5880
5881
5882
5883
5884
5885
5886
5887
5888
5889
5890
5891
5892
5893
5894
5895
5896
5897
5898
5899
5900
5901
5902
5903
5904
5905
5906
5907
5908
5909
5910
5911
5912
5913
5914
5915
5916
5917
5918
5919
5920
5921
5922
5923
5924
5925
5926
5927
5928
5929
5930
5931
5932
5933
5934
5935
5936
5937
5938
5939
5940
5941
5942
5943
5944
5945
5946
5947
5948
5949
5950
5951
5952
5953
5954
5955
5956
5957
5958
5959
5960
5961
5962
5963
5964
5965
5966
5967
5968
5969
5970
5971
5972
5973
5974
5975
5976
5977
5978
5979
5980
5981
5982
5983
5984
5985
5986
5987
5988
5989
5990
5991
5992
5993
5994
5995
5996
5997
5998
5999
6000
6001
6002
6003
6004
6005
6006
6007
6008
6009
6010
6011
6012
6013
6014
6015
6016
6017
6018
6019
6020
6021
6022
6023
6024
6025
6026
6027
6028
6029
6030
6031
6032
6033
6034
6035
6036
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049
6050
6051
6052
6053
6054
6055
6056
6057
6058
6059
6060
6061
6062
6063
6064
6065
6066
6067
6068
6069
6070
6071
6072
6073
6074
6075
6076
6077
6078
6079
6080
6081
6082
6083
6084
6085
6086
6087
6088
6089
6090
6091
6092
6093
6094
6095
6096
6097
6098
6099
6100
6101
6102
6103
6104
6105
6106
6107
6108
6109
6110
6111
6112
6113
6114
6115
6116
6117
6118
6119
6120
6121
6122
6123
6124
6125
6126
6127
6128
6129
6130
6131
6132
6133
6134
6135
6136
6137
6138
6139
6140
6141
6142
6143
6144
6145
6146
6147
6148
6149
6150
6151
6152
6153
6154
6155
6156
6157
6158
6159
6160
6161
6162
6163
6164
6165
6166
6167
6168
6169
6170
6171
6172
6173
6174
6175
6176
6177
6178
6179
6180
6181
6182
6183
6184
6185
6186
6187
6188
6189
6190
6191
6192
6193
6194
6195
6196
6197
6198
6199
6200
6201
6202
6203
6204
6205
6206
6207
6208
6209
6210
6211
6212
6213
6214
6215
6216
6217
6218
6219
6220
6221
6222
6223
6224
6225
6226
6227
6228
6229
6230
6231
6232
6233
6234
6235
6236
6237
6238
6239
6240
6241
6242
6243
6244
6245
6246
6247
6248
6249
6250
6251
6252
6253
6254
6255
6256
6257
6258
6259
6260
6261
6262
6263
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274
6275
6276
6277
6278
6279
6280
6281
6282
6283
6284
6285
6286
6287
6288
6289
6290
6291
6292
6293
6294
6295
6296
6297
6298
6299
6300
6301
6302
6303
6304
6305
6306
6307
6308
6309
6310
6311
6312
6313
6314
6315
6316
6317
6318
6319
6320
6321
6322
6323
6324
6325
6326
6327
6328
6329
6330
6331
6332
6333
6334
6335
6336
6337
6338
6339
6340
6341
6342
6343
6344
6345
6346
6347
6348
6349
6350
6351
6352
6353
6354
6355
6356
6357
6358
6359
6360
6361
6362
6363
6364
6365
6366
6367
6368
6369
6370
6371
6372
6373
6374
6375
6376
6377
6378
6379
6380
6381
6382
6383
6384
6385
6386
6387
6388
6389
6390
6391
6392
6393
6394
6395
6396
6397
6398
6399
6400
6401
6402
6403
6404
6405
6406
6407
6408
6409
6410
6411
6412
6413
6414
6415
6416
6417
6418
6419
6420
6421
6422
6423
6424
6425
6426
6427
6428
6429
6430
6431
6432
6433
6434
6435
6436
6437
6438
6439
6440
6441
6442
6443
6444
6445
6446
6447
6448
6449
6450
6451
6452
6453
6454
6455
6456
6457
6458
6459
6460
6461
6462
6463
6464
6465
6466
6467
6468
6469
6470
6471
6472
6473
6474
6475
6476
6477
6478
6479
6480
6481
6482
6483
6484
6485
6486
6487
6488
6489
6490
6491
6492
6493
6494
6495
6496
6497
6498
6499
6500
6501
6502
6503
6504
6505
6506
6507
6508
6509
6510
6511
6512
6513
6514
6515
6516
6517
6518
6519
6520
6521
6522
6523
6524
6525
6526
6527
6528
6529
6530
6531
6532
6533
6534
6535
6536
6537
6538
6539
6540
6541
6542
6543
6544
6545
6546
6547
6548
6549
6550
6551
6552
6553
6554
6555
6556
6557
6558
6559
6560
6561
6562
6563
6564
6565
6566
6567
6568
6569
6570
6571
6572
6573
6574
6575
6576
6577
6578
6579
6580
6581
6582
6583
6584
6585
6586
6587
6588
6589
6590
6591
6592
6593
6594
6595
6596
6597
6598
6599
6600
6601
6602
6603
6604
6605
6606
6607
6608
6609
6610
6611
6612
6613
6614
6615
6616
6617
6618
6619
6620
6621
6622
6623
6624
6625
6626
6627
6628
6629
6630
6631
6632
6633
6634
6635
6636
6637
6638
6639
6640
6641
6642
6643
6644
6645
6646
6647
6648
6649
6650
6651
6652
6653
6654
6655
6656
6657
6658
6659
6660
6661
6662
6663
6664
6665
6666
6667
6668
6669
6670
6671
6672
6673
6674
6675
6676
6677
6678
6679
6680
6681
6682
6683
6684
6685
6686
6687
6688
6689
6690
6691
6692
6693
6694
6695
6696
6697
6698
6699
6700
6701
6702
6703
6704
6705
6706
6707
6708
6709
6710
6711
6712
6713
6714
6715
6716
6717
6718
6719
6720
6721
6722
6723
6724
6725
6726
6727
6728
6729
6730
6731
6732
6733
6734
6735
6736
6737
6738
6739
6740
6741
6742
6743
6744
6745
6746
6747
6748
6749
6750
6751
6752
6753
6754
6755
6756
6757
6758
6759
6760
6761
6762
6763
6764
6765
6766
6767
6768
6769
6770
6771
6772
6773
6774
6775
6776
6777
6778
6779
6780
6781
6782
6783
6784
6785
6786
6787
6788
6789
6790
6791
6792
6793
6794
6795
6796
6797
6798
6799
6800
6801
6802
6803
6804
6805
6806
6807
6808
6809
6810
6811
6812
6813
6814
6815
6816
6817
6818
6819
6820
6821
6822
6823
6824
6825
6826
6827
6828
6829
6830
6831
6832
6833
6834
6835
6836
6837
6838
6839
6840
6841
6842
6843
6844
6845
6846
6847
6848
6849
6850
6851
6852
6853
6854
6855
6856
6857
6858
6859
6860
6861
6862
6863
6864
6865
6866
6867
6868
6869
6870
6871
6872
6873
6874
6875
6876
6877
6878
6879
6880
6881
6882
6883
6884
6885
6886
6887
6888
6889
6890
6891
6892
6893
6894
6895
6896
6897
6898
6899
6900
6901
6902
6903
6904
6905
6906
6907
6908
6909
6910
6911
6912
6913
6914
6915
6916
6917
6918
6919
6920
6921
6922
6923
6924
6925
6926
6927
6928
6929
6930
6931
6932
6933
6934
6935
6936
6937
6938
6939
6940
6941
6942
6943
6944
6945
6946
6947
6948
6949
6950
6951
6952
6953
6954
6955
6956
6957
6958
6959
6960
6961
6962
6963
6964
6965
6966
6967
6968
6969
6970
6971
6972
6973
6974
6975
6976
6977
6978
6979
6980
6981
6982
6983
6984
6985
6986
6987
6988
6989
6990
6991
6992
6993
6994
6995
6996
6997
6998
6999
7000
7001
7002
7003
7004
7005
7006
7007
7008
7009
7010
7011
7012
7013
7014
7015
7016
7017
7018
7019
7020
7021
7022
7023
7024
7025
7026
7027
7028
7029
7030
7031
7032
7033
7034
7035
7036
7037
7038
7039
7040
7041
7042
7043
7044
7045
7046
7047
7048
7049
7050
7051
7052
7053
7054
7055
7056
7057
7058
7059
7060
7061
7062
7063
7064
7065
7066
7067
7068
7069
7070
7071
7072
7073
7074
7075
7076
7077
7078
7079
7080
7081
7082
7083
7084
7085
7086
7087
7088
7089
7090
7091
7092
7093
7094
7095
7096
7097
7098
7099
7100
7101
7102
7103
7104
7105
7106
7107
7108
7109
7110
7111
7112
7113
7114
7115
7116
7117
7118
7119
7120
7121
7122
7123
7124
7125
7126
7127
7128
7129
7130
7131
7132
7133
7134
7135
7136
7137
7138
7139
7140
7141
7142
7143
7144
7145
7146
7147
7148
7149
7150
7151
7152
7153
7154
7155
7156
7157
7158
7159
7160
7161
7162
7163
7164
7165
7166
7167
7168
7169
7170
7171
7172
7173
7174
7175
7176
7177
7178
7179
7180
7181
7182
7183
7184
7185
7186
7187
7188
7189
7190
7191
7192
7193
7194
7195
7196
7197
7198
7199
7200
7201
7202
7203
7204
7205
7206
7207
7208
7209
7210
7211
7212
7213
7214
7215
7216
7217
7218
7219
7220
7221
7222
7223
7224
7225
7226
7227
7228
7229
7230
7231
7232
7233
7234
7235
7236
7237
7238
7239
7240
7241
7242
7243
7244
7245
7246
7247
7248
7249
7250
7251
7252
7253
7254
7255
7256
7257
7258
7259
7260
7261
7262
7263
7264
7265
7266
7267
7268
7269
7270
7271
7272
7273
7274
7275
7276
7277
7278
7279
7280
7281
7282
7283
7284
7285
7286
7287
7288
7289
7290
7291
7292
7293
7294
7295
7296
7297
7298
7299
7300
7301
7302
7303
7304
7305
7306
7307
7308
7309
7310
7311
7312
7313
7314
7315
7316
7317
7318
7319
7320
7321
7322
7323
7324
7325
7326
7327
7328
7329
7330
7331
7332
7333
7334
7335
7336
7337
7338
7339
7340
7341
7342
7343
7344
7345
7346
7347
7348
7349
7350
7351
7352
7353
7354
7355
7356
7357
7358
7359
7360
7361
7362
7363
7364
7365
7366
7367
7368
7369
7370
7371
7372
7373
7374
7375
7376
7377
7378
7379
7380
7381
7382
7383
7384
7385
7386
7387
7388
7389
7390
7391
7392
7393
7394
7395
7396
7397
7398
7399
7400
7401
7402
7403
7404
7405
7406
7407
7408
7409
7410
7411
7412
7413
7414
7415
7416
7417
7418
7419
7420
7421
7422
7423
7424
7425
7426
7427
7428
7429
7430
7431
7432
7433
7434
7435
7436
7437
7438
7439
7440
7441
7442
7443
7444
7445
7446
7447
7448
7449
7450
7451
7452
7453
7454
7455
7456
7457
7458
7459
7460
7461
7462
7463
7464
7465
7466
7467
7468
7469
7470
7471
7472
7473
7474
7475
7476
7477
7478
7479
7480
7481
7482
7483
7484
7485
7486
7487
7488
7489
7490
7491
7492
7493
7494
7495
7496
7497
7498
7499
7500
7501
7502
7503
7504
7505
7506
7507
7508
7509
7510
7511
7512
7513
7514
7515
7516
7517
7518
7519
7520
7521
7522
7523
7524
7525
7526
7527
7528
7529
7530
7531
7532
7533
7534
7535
7536
7537
7538
7539
7540
7541
7542
7543
7544
7545
7546
7547
7548
7549
7550
7551
7552
7553
7554
7555
7556
7557
7558
7559
7560
7561
7562
7563
7564
7565
7566
7567
7568
7569
7570
7571
7572
7573
7574
7575
7576
7577
7578
7579
7580
7581
7582
7583
7584
7585
7586
7587
7588
7589
7590
7591
7592
7593
7594
7595
7596
7597
7598
7599
7600
7601
7602
7603
7604
7605
7606
7607
7608
7609
7610
7611
7612
7613
7614
7615
7616
7617
7618
7619
7620
7621
7622
7623
7624
7625
7626
7627
7628
7629
7630
7631
7632
7633
7634
7635
7636
7637
7638
7639
7640
7641
7642
7643
7644
7645
7646
7647
7648
7649
7650
7651
7652
7653
7654
7655
7656
7657
7658
7659
7660
7661
7662
7663
7664
7665
7666
7667
7668
7669
7670
7671
7672
7673
7674
7675
7676
7677
7678
7679
7680
7681
7682
7683
7684
7685
7686
7687
7688
7689
7690
7691
7692
7693
7694
7695
7696
7697
7698
7699
7700
7701
7702
7703
7704
7705
7706
7707
7708
7709
7710
7711
7712
7713
7714
7715
7716
7717
7718
7719
7720
7721
7722
7723
7724
7725
7726
7727
7728
7729
7730
7731
7732
7733
7734
7735
7736
7737
7738
7739
7740
7741
7742
7743
7744
7745
7746
7747
7748
7749
7750
7751
7752
7753
7754
7755
7756
7757
7758
7759
7760
7761
7762
7763
7764
7765
7766
7767
7768
7769
7770
7771
7772
7773
7774
7775
7776
7777
7778
7779
7780
7781
7782
7783
7784
7785
7786
7787
7788
7789
7790
7791
7792
7793
7794
7795
7796
7797
7798
7799
7800
7801
7802
7803
7804
7805
7806
7807
7808
7809
7810
7811
7812
7813
7814
7815
7816
7817
7818
7819
7820
7821
7822
7823
7824
7825
7826
7827
7828
7829
7830
7831
7832
7833
7834
7835
7836
7837
7838
7839
7840
7841
7842
7843
7844
7845
7846
7847
7848
7849
7850
7851
7852
7853
7854
7855
7856
7857
7858
7859
7860
7861
7862
7863
7864
7865
7866
7867
7868
7869
7870
7871
7872
7873
7874
7875
7876
7877
7878
7879
7880
7881
7882
7883
7884
7885
7886
7887
7888
7889
7890
7891
7892
7893
7894
7895
7896
7897
7898
7899
7900
7901
7902
7903
7904
7905
7906
7907
7908
7909
7910
7911
7912
7913
7914
7915
7916
7917
7918
7919
7920
7921
7922
7923
7924
7925
7926
7927
7928
7929
7930
7931
7932
7933
7934
7935
7936
7937
7938
7939
7940
7941
7942
7943
7944
7945
7946
7947
7948
7949
7950
7951
7952
7953
7954
7955
7956
7957
7958
7959
7960
7961
7962
7963
7964
7965
7966
7967
7968
7969
7970
7971
7972
7973
7974
7975
7976
7977
7978
7979
7980
7981
7982
7983
7984
7985
7986
7987
7988
7989
7990
7991
7992
7993
7994
7995
7996
7997
7998
7999
8000
8001
8002
8003
8004
8005
8006
8007
8008
8009
8010
8011
8012
8013
8014
8015
8016
8017
8018
8019
8020
8021
8022
8023
8024
8025
8026
8027
8028
8029
8030
8031
8032
8033
8034
8035
8036
8037
8038
8039
8040
8041
8042
8043
8044
8045
8046
8047
8048
8049
8050
8051
8052
8053
8054
8055
8056
8057
8058
8059
8060
8061
8062
8063
8064
8065
8066
8067
8068
8069
8070
8071
8072
8073
8074
8075
8076
8077
8078
8079
8080
8081
8082
8083
8084
8085
8086
8087
8088
8089
8090
8091
8092
8093
8094
8095
8096
8097
8098
8099
8100
8101
8102
8103
8104
8105
8106
8107
8108
8109
8110
8111
8112
8113
8114
8115
8116
8117
8118
8119
8120
8121
8122
8123
8124
8125
8126
8127
8128
8129
8130
8131
8132
8133
8134
8135
8136
8137
8138
8139
8140
8141
8142
8143
8144
8145
8146
8147
8148
8149
8150
8151
8152
8153
8154
8155
8156
8157
8158
8159
8160
8161
8162
8163
8164
8165
8166
8167
8168
8169
8170
8171
8172
8173
8174
8175
8176
8177
8178
8179
8180
8181
8182
8183
8184
8185
8186
8187
8188
8189
8190
8191
8192
8193
8194
8195
8196
8197
8198
8199
8200
8201
8202
8203
8204
8205
8206
8207
8208
8209
8210
8211
8212
8213
8214
8215
8216
8217
8218
8219
8220
8221
8222
8223
8224
8225
8226
8227
8228
8229
8230
8231
8232
8233
8234
8235
8236
8237
8238
8239
8240
8241
8242
8243
8244
8245
8246
8247
8248
8249
8250
8251
8252
8253
8254
8255
8256
8257
8258
8259
8260
8261
8262
8263
8264
8265
8266
8267
8268
8269
8270
8271
8272
8273
8274
8275
8276
8277
8278
8279
8280
8281
8282
8283
8284
8285
8286
8287
8288
8289
8290
8291
8292
8293
8294
8295
8296
8297
8298
8299
8300
8301
8302
8303
8304
8305
8306
8307
8308
8309
8310
8311
8312
8313
8314
8315
8316
8317
8318
8319
8320
8321
8322
8323
8324
8325
8326
8327
8328
8329
8330
8331
8332
8333
8334
8335
8336
8337
8338
8339
8340
8341
8342
8343
8344
8345
8346
8347
8348
8349
8350
8351
8352
8353
8354
8355
8356
8357
8358
8359
8360
8361
8362
8363
8364
8365
8366
8367
8368
8369
8370
8371
8372
8373
8374
8375
8376
8377
8378
8379
8380
8381
8382
8383
8384
8385
8386
8387
8388
8389
8390
8391
8392
8393
8394
8395
8396
8397
8398
8399
8400
8401
8402
8403
8404
8405
8406
8407
8408
8409
8410
8411
8412
8413
8414
8415
8416
8417
8418
8419
8420
8421
8422
8423
8424
8425
8426
8427
8428
8429
8430
8431
8432
8433
8434
8435
8436
8437
8438
8439
8440
8441
8442
8443
8444
8445
8446
8447
8448
8449
8450
8451
8452
8453
8454
8455
8456
8457
8458
8459
8460
8461
8462
8463
8464
8465
8466
8467
8468
8469
8470
8471
8472
8473
8474
8475
8476
8477
8478
8479
8480
8481
8482
8483
8484
8485
8486
8487
8488
8489
8490
8491
8492
8493
8494
8495
8496
8497
8498
8499
8500
8501
8502
8503
8504
8505
8506
8507
8508
8509
8510
8511
8512
8513
8514
8515
8516
8517
8518
8519
8520
8521
8522
8523
8524
8525
8526
8527
8528
8529
8530
8531
8532
8533
8534
8535
8536
8537
8538
8539
8540
8541
8542
8543
8544
8545
8546
8547
8548
8549
8550
8551
8552
8553
8554
8555
8556
8557
8558
8559
8560
8561
8562
8563
8564
8565
8566
8567
8568
8569
8570
8571
8572
8573
8574
8575
8576
8577
8578
8579
8580
8581
8582
8583
8584
8585
8586
8587
8588
8589
8590
8591
8592
8593
8594
8595
8596
8597
8598
8599
8600
8601
8602
8603
8604
8605
8606
8607
8608
8609
8610
8611
8612
8613
8614
8615
8616
8617
8618
8619
8620
8621
8622
8623
8624
8625
8626
8627
8628
8629
8630
8631
8632
8633
8634
8635
8636
8637
8638
8639
8640
8641
8642
8643
8644
8645
8646
8647
8648
8649
8650
8651
8652
8653
8654
8655
8656
8657
8658
8659
8660
8661
8662
8663
8664
8665
8666
8667
8668
8669
8670
8671
8672
8673
8674
8675
8676
8677
8678
8679
8680
8681
8682
8683
8684
8685
8686
8687
8688
8689
8690
8691
8692
8693
8694
8695
8696
8697
8698
8699
8700
8701
8702
8703
8704
8705
8706
8707
8708
8709
8710
8711
8712
8713
8714
8715
8716
8717
8718
8719
8720
8721
8722
8723
8724
8725
8726
8727
8728
8729
8730
8731
8732
8733
8734
8735
8736
8737
8738
8739
8740
8741
8742
8743
8744
8745
8746
8747
8748
8749
8750
8751
8752
8753
8754
8755
8756
8757
8758
8759
8760
8761
8762
8763
8764
8765
8766
8767
8768
8769
8770
8771
8772
8773
8774
8775
8776
8777
8778
8779
8780
8781
8782
8783
8784
8785
8786
8787
8788
8789
8790
8791
8792
8793
8794
8795
8796
8797
8798
8799
8800
8801
8802
8803
8804
8805
8806
8807
8808
8809
8810
8811
8812
8813
8814
8815
8816
8817
8818
8819
8820
8821
8822
8823
8824
8825
8826
8827
8828
8829
8830
8831
8832
8833
8834
8835
8836
8837
8838
8839
8840
8841
8842
8843
8844
8845
8846
8847
8848
8849
8850
8851
8852
8853
8854
8855
8856
8857
8858
8859
8860
8861
8862
8863
8864
8865
8866
8867
8868
8869
8870
8871
8872
8873
8874
8875
8876
8877
8878
8879
8880
8881
8882
8883
8884
8885
8886
8887
8888
8889
8890
8891
8892
8893
8894
8895
8896
8897
8898
8899
8900
8901
8902
8903
8904
8905
8906
8907
8908
8909
8910
8911
8912
8913
8914
8915
8916
8917
8918
8919
8920
8921
8922
8923
8924
8925
8926
8927
8928
8929
8930
8931
8932
8933
8934
8935
8936
8937
8938
8939
8940
8941
8942
8943
8944
8945
8946
8947
8948
8949
8950
8951
8952
8953
8954
8955
8956
8957
8958
8959
8960
8961
8962
8963
8964
8965
8966
8967
8968
8969
8970
8971
8972
8973
8974
8975
8976
8977
8978
8979
8980
8981
8982
8983
8984
8985
8986
8987
8988
8989
8990
8991
8992
8993
8994
8995
8996
8997
8998
8999
9000
9001
9002
9003
9004
9005
9006
9007
9008
9009
9010
9011
9012
9013
9014
9015
9016
9017
9018
9019
9020
9021
9022
9023
9024
9025
9026
9027
9028
9029
9030
9031
9032
9033
9034
9035
9036
9037
9038
9039
9040
9041
9042
9043
9044
9045
9046
9047
9048
9049
9050
9051
9052
9053
9054
9055
9056
9057
9058
9059
9060
9061
9062
9063
9064
9065
9066
9067
9068
9069
9070
9071
9072
9073
9074
9075
9076
9077
9078
9079
9080
9081
9082
9083
9084
9085
9086
9087
9088
9089
9090
9091
9092
9093
9094
9095
9096
9097
9098
9099
9100
9101
9102
9103
9104
9105
9106
9107
9108
9109
9110
9111
9112
9113
9114
9115
9116
9117
9118
9119
9120
9121
9122
9123
9124
9125
9126
9127
9128
9129
9130
9131
9132
9133
9134
9135
9136
9137
9138
9139
9140
9141
9142
9143
9144
9145
9146
9147
9148
9149
9150
9151
9152
9153
9154
9155
9156
9157
9158
9159
9160
9161
9162
9163
9164
9165
9166
9167
9168
9169
9170
9171
9172
9173
9174
9175
9176
9177
9178
9179
9180
9181
9182
9183
9184
9185
9186
9187
9188
9189
9190
9191
9192
9193
9194
9195
9196
9197
9198
9199
9200
9201
9202
9203
9204
9205
9206
9207
9208
9209
9210
9211
9212
9213
9214
9215
9216
9217
9218
9219
9220
9221
9222
9223
9224
9225
9226
9227
9228
9229
9230
9231
9232
9233
9234
9235
9236
9237
9238
9239
9240
9241
9242
9243
9244
9245
9246
9247
9248
9249
9250
9251
9252
9253
9254
9255
9256
9257
9258
9259
9260
9261
9262
9263
9264
9265
9266
9267
9268
9269
9270
9271
9272
9273
9274
9275
9276
9277
9278
9279
9280
9281
9282
9283
9284
9285
9286
9287
9288
9289
9290
9291
9292
9293
9294
9295
9296
9297
9298
9299
9300
9301
9302
9303
9304
9305
9306
9307
9308
9309
9310
9311
9312
9313
9314
9315
9316
9317
9318
9319
9320
9321
9322
9323
9324
9325
9326
9327
9328
9329
9330
9331
9332
9333
9334
9335
9336
9337
9338
9339
9340
9341
9342
9343
9344
9345
9346
9347
9348
9349
9350
9351
9352
9353
9354
9355
9356
9357
9358
9359
9360
9361
9362
9363
9364
9365
9366
9367
9368
9369
9370
9371
9372
9373
9374
9375
9376
9377
9378
9379
9380
9381
9382
9383
9384
9385
9386
9387
9388
9389
9390
9391
9392
9393
9394
9395
9396
9397
9398
9399
9400
9401
9402
9403
9404
9405
9406
9407
9408
9409
9410
9411
9412
9413
9414
9415
9416
9417
9418
9419
9420
9421
9422
9423
9424
9425
9426
9427
9428
9429
9430
9431
9432
9433
9434
9435
9436
9437
9438
9439
9440
9441
9442
9443
9444
9445
9446
9447
9448
9449
9450
9451
9452
9453
9454
9455
9456
9457
9458
9459
9460
9461
9462
9463
9464
9465
9466
9467
9468
9469
9470
9471
9472
9473
9474
9475
9476
9477
9478
9479
9480
9481
9482
9483
9484
9485
9486
9487
9488
9489
9490
9491
9492
9493
9494
9495
9496
9497
9498
9499
9500
9501
9502
9503
9504
9505
9506
9507
9508
9509
9510
9511
9512
9513
9514
9515
9516
9517
9518
9519
9520
9521
9522
9523
9524
9525
9526
9527
9528
9529
9530
9531
9532
9533
9534
9535
9536
9537
9538
9539
9540
9541
9542
9543
9544
9545
9546
9547
9548
9549
9550
9551
9552
9553
9554
9555
9556
9557
9558
9559
9560
9561
9562
9563
9564
9565
9566
9567
9568
9569
9570
9571
9572
9573
9574
9575
9576
9577
9578
9579
9580
9581
9582
9583
9584
9585
9586
9587
9588
9589
9590
9591
9592
9593
9594
9595
9596
9597
9598
9599
9600
9601
9602
9603
9604
9605
9606
9607
9608
9609
9610
9611
9612
9613
9614
9615
9616
9617
9618
9619
9620
9621
9622
9623
9624
9625
9626
9627
9628
9629
9630
9631
9632
9633
9634
9635
9636
9637
9638
9639
9640
9641
9642
9643
9644
9645
9646
9647
9648
9649
9650
9651
9652
9653
9654
9655
9656
9657
9658
9659
9660
9661
9662
9663
9664
9665
9666
9667
9668
9669
9670
9671
9672
9673
9674
9675
9676
9677
9678
9679
9680
9681
9682
9683
9684
9685
9686
9687
9688
9689
9690
9691
9692
9693
9694
9695
9696
9697
9698
9699
9700
9701
9702
9703
9704
9705
9706
9707
9708
9709
9710
9711
9712
9713
9714
9715
9716
9717
9718
9719
9720
9721
9722
9723
9724
9725
9726
9727
9728
9729
9730
9731
9732
9733
9734
9735
9736
9737
9738
9739
9740
9741
9742
9743
9744
9745
9746
9747
9748
9749
9750
9751
9752
9753
9754
9755
9756
9757
9758
9759
9760
9761
9762
9763
9764
9765
9766
9767
9768
9769
9770
9771
9772
9773
9774
9775
9776
9777
9778
9779
9780
9781
9782
9783
9784
9785
9786
9787
9788
9789
9790
9791
9792
9793
9794
9795
9796
9797
9798
9799
9800
9801
9802
9803
9804
9805
9806
9807
9808
9809
9810
9811
9812
9813
9814
9815
9816
9817
9818
9819
9820
9821
9822
9823
9824
9825
9826
9827
9828
9829
9830
9831
9832
9833
9834
9835
9836
9837
9838
9839
9840
9841
9842
9843
9844
9845
9846
9847
9848
9849
9850
9851
9852
9853
9854
9855
9856
9857
9858
9859
9860
9861
9862
9863
9864
9865
9866
9867
9868
9869
9870
9871
9872
9873
9874
9875
9876
9877
9878
9879
9880
9881
9882
9883
9884
9885
9886
9887
9888
9889
9890
9891
9892
9893
9894
9895
9896
9897
9898
9899
9900
9901
9902
9903
9904
9905
9906
9907
9908
9909
9910
9911
9912
9913
9914
9915
9916
9917
9918
9919
9920
9921
9922
9923
9924
9925
9926
9927
9928
9929
9930
9931
9932
9933
9934
9935
9936
9937
9938
9939
9940
9941
9942
9943
9944
9945
9946
9947
9948
9949
9950
9951
9952
9953
9954
9955
9956
9957
9958
9959
9960
9961
9962
9963
9964
9965
9966
9967
9968
9969
9970
9971
9972
9973
9974
9975
9976
9977
9978
9979
9980
9981
9982
9983
9984
9985
9986
9987
9988
9989
9990
9991
9992
9993
9994
9995
9996
9997
9998
9999
10000
10001
10002
10003
10004
10005
10006
10007
10008
10009
10010
10011
10012
10013
10014
10015
10016
10017
10018
10019
10020
10021
10022
10023
10024
10025
10026
10027
10028
10029
10030
10031
10032
10033
10034
10035
10036
10037
10038
10039
10040
10041
10042
10043
10044
10045
10046
10047
10048
10049
10050
10051
10052
10053
10054
10055
10056
10057
10058
10059
10060
10061
10062
10063
10064
10065
10066
10067
10068
10069
10070
10071
10072
10073
10074
10075
10076
10077
10078
10079
10080
10081
10082
10083
10084
10085
10086
10087
10088
10089
10090
10091
10092
10093
10094
10095
10096
10097
10098
10099
10100
10101
10102
10103
10104
10105
10106
10107
10108
10109
10110
10111
10112
10113
10114
10115
10116
10117
10118
10119
10120
10121
10122
10123
10124
10125
10126
10127
10128
10129
10130
10131
10132
10133
10134
10135
10136
10137
10138
10139
10140
10141
10142
10143
10144
10145
10146
10147
10148
10149
10150
10151
10152
10153
10154
10155
10156
10157
10158
10159
10160
10161
10162
10163
10164
10165
10166
10167
10168
10169
10170
10171
10172
10173
10174
10175
10176
10177
10178
10179
10180
10181
10182
10183
10184
10185
10186
10187
10188
10189
10190
10191
10192
10193
10194
10195
10196
10197
10198
10199
10200
10201
10202
10203
10204
10205
10206
10207
10208
10209
10210
10211
10212
10213
10214
10215
10216
10217
10218
10219
10220
10221
10222
10223
10224
10225
10226
10227
10228
10229
10230
10231
10232
10233
10234
10235
10236
10237
10238
10239
10240
10241
10242
10243
10244
10245
10246
10247
10248
10249
10250
10251
10252
10253
10254
10255
10256
10257
10258
10259
10260
10261
10262
10263
10264
10265
10266
10267
10268
10269
10270
10271
10272
10273
10274
10275
10276
10277
10278
10279
10280
10281
10282
10283
10284
10285
10286
10287
10288
10289
10290
10291
10292
10293
10294
10295
10296
10297
10298
10299
10300
10301
10302
10303
10304
10305
10306
10307
10308
10309
10310
10311
10312
10313
10314
10315
10316
10317
10318
10319
10320
10321
10322
10323
10324
10325
10326
10327
10328
10329
10330
10331
10332
10333
10334
10335
10336
10337
10338
10339
10340
10341
10342
10343
10344
10345
10346
10347
10348
10349
10350
10351
10352
10353
10354
10355
10356
10357
10358
10359
10360
10361
10362
10363
10364
10365
10366
10367
10368
10369
10370
10371
10372
10373
10374
10375
10376
10377
10378
10379
10380
10381
10382
10383
10384
10385
10386
10387
10388
10389
10390
10391
10392
10393
10394
10395
10396
10397
10398
10399
10400
10401
10402
10403
10404
10405
10406
10407
10408
10409
10410
10411
10412
10413
10414
10415
10416
10417
10418
10419
10420
10421
10422
10423
10424
10425
10426
10427
10428
10429
10430
10431
10432
10433
10434
10435
10436
10437
10438
10439
10440
10441
10442
10443
10444
10445
10446
10447
10448
10449
10450
10451
10452
10453
10454
10455
10456
10457
10458
10459
10460
10461
10462
10463
10464
10465
10466
10467
10468
10469
10470
10471
10472
10473
10474
10475
10476
10477
10478
10479
10480
10481
10482
10483
10484
10485
10486
10487
10488
10489
10490
10491
10492
10493
10494
10495
10496
10497
10498
10499
10500
10501
10502
10503
10504
10505
10506
10507
10508
10509
10510
10511
10512
10513
10514
10515
10516
10517
10518
10519
10520
10521
10522
10523
10524
10525
10526
10527
10528
10529
10530
10531
10532
10533
10534
10535
10536
10537
10538
10539
10540
10541
10542
10543
10544
10545
10546
10547
10548
10549
10550
10551
10552
10553
10554
10555
10556
10557
10558
10559
10560
10561
10562
10563
10564
10565
10566
10567
10568
10569
10570
10571
10572
10573
10574
10575
10576
10577
10578
10579
10580
10581
10582
10583
10584
10585
10586
10587
10588
10589
10590
10591
10592
10593
10594
10595
10596
10597
10598
10599
10600
10601
10602
10603
10604
10605
10606
10607
10608
10609
10610
10611
10612
10613
10614
10615
10616
10617
10618
10619
10620
10621
10622
10623
10624
10625
10626
10627
10628
10629
10630
10631
10632
10633
10634
10635
10636
10637
10638
10639
10640
10641
10642
10643
10644
10645
10646
10647
10648
10649
10650
10651
10652
10653
10654
10655
10656
10657
10658
10659
10660
10661
10662
10663
10664
10665
10666
10667
10668
10669
10670
10671
10672
10673
10674
10675
10676
10677
10678
10679
10680
10681
10682
10683
10684
10685
10686
10687
10688
10689
10690
10691
10692
10693
10694
10695
10696
10697
10698
10699
10700
10701
10702
10703
10704
10705
10706
10707
10708
10709
10710
10711
10712
10713
10714
10715
10716
10717
10718
10719
10720
10721
10722
10723
10724
10725
10726
10727
10728
10729
10730
10731
10732
10733
10734
10735
10736
10737
10738
10739
10740
10741
10742
10743
10744
10745
10746
10747
10748
10749
10750
10751
10752
10753
10754
10755
10756
10757
10758
10759
10760
10761
10762
10763
10764
10765
10766
10767
10768
10769
10770
10771
10772
10773
10774
10775
10776
10777
10778
10779
10780
10781
10782
10783
10784
10785
10786
10787
10788
10789
10790
10791
10792
10793
10794
10795
10796
10797
10798
10799
10800
10801
10802
10803
10804
10805
10806
10807
10808
10809
10810
10811
10812
10813
10814
10815
10816
10817
10818
10819
10820
10821
10822
10823
10824
10825
10826
10827
10828
10829
10830
10831
10832
10833
10834
10835
10836
10837
10838
10839
10840
10841
10842
10843
10844
10845
10846
10847
10848
10849
10850
10851
10852
10853
10854
10855
10856
10857
10858
10859
10860
10861
10862
10863
10864
10865
10866
10867
10868
10869
10870
10871
10872
10873
10874
10875
10876
10877
10878
10879
10880
10881
10882
10883
10884
10885
10886
10887
10888
10889
10890
10891
10892
10893
10894
10895
10896
10897
10898
10899
10900
10901
10902
10903
10904
10905
10906
10907
10908
10909
10910
10911
10912
10913
10914
10915
10916
10917
10918
10919
10920
10921
10922
10923
10924
10925
10926
10927
10928
10929
10930
10931
10932
10933
10934
10935
10936
10937
10938
10939
10940
10941
10942
10943
10944
10945
10946
10947
10948
10949
10950
10951
10952
10953
10954
10955
10956
10957
10958
10959
10960
10961
10962
10963
10964
10965
10966
10967
10968
10969
10970
10971
10972
10973
10974
10975
10976
10977
10978
10979
10980
10981
10982
10983
10984
10985
10986
10987
10988
10989
10990
10991
10992
10993
10994
10995
10996
10997
10998
10999
11000
11001
11002
11003
11004
11005
11006
11007
11008
11009
11010
11011
11012
11013
11014
11015
11016
11017
11018
11019
11020
11021
11022
11023
11024
11025
11026
11027
11028
11029
11030
11031
11032
11033
11034
11035
11036
11037
11038
11039
11040
11041
11042
11043
11044
11045
11046
11047
11048
11049
11050
11051
11052
11053
11054
11055
11056
11057
11058
11059
11060
11061
11062
11063
11064
11065
11066
11067
11068
11069
11070
11071
11072
11073
11074
11075
11076
11077
11078
11079
11080
11081
11082
11083
11084
11085
11086
11087
11088
11089
11090
11091
11092
11093
11094
11095
11096
11097
11098
11099
11100
11101
11102
11103
11104
11105
11106
11107
11108
11109
11110
11111
11112
11113
11114
11115
11116
11117
11118
11119
11120
11121
11122
11123
11124
11125
11126
11127
11128
11129
11130
11131
11132
11133
11134
11135
11136
11137
11138
11139
11140
11141
11142
11143
11144
11145
11146
11147
11148
11149
11150
11151
11152
11153
11154
11155
11156
11157
11158
11159
11160
11161
11162
11163
11164
11165
11166
11167
11168
11169
11170
11171
11172
11173
11174
11175
11176
11177
11178
11179
11180
11181
11182
11183
11184
11185
11186
11187
11188
11189
11190
11191
11192
11193
11194
11195
11196
11197
11198
11199
11200
11201
11202
11203
11204
11205
11206
11207
11208
11209
11210
11211
11212
11213
11214
11215
11216
11217
11218
11219
11220
11221
11222
11223
11224
11225
11226
11227
11228
11229
11230
11231
11232
11233
11234
11235
11236
11237
11238
11239
11240
11241
11242
11243
11244
11245
11246
11247
11248
11249
11250
11251
11252
11253
11254
11255
11256
11257
11258
11259
11260
11261
11262
11263
11264
11265
11266
11267
11268
11269
11270
11271
11272
11273
11274
11275
11276
11277
11278
11279
11280
11281
11282
11283
11284
11285
11286
11287
11288
11289
11290
11291
11292
11293
11294
11295
11296
11297
11298
11299
11300
11301
11302
11303
11304
11305
11306
11307
11308
11309
11310
11311
11312
11313
11314
11315
11316
11317
11318
11319
11320
11321
11322
11323
11324
11325
11326
11327
11328
11329
11330
11331
11332
11333
11334
11335
11336
11337
11338
11339
11340
11341
11342
11343
11344
11345
11346
11347
11348
11349
11350
11351
11352
11353
11354
11355
11356
11357
11358
11359
11360
11361
11362
11363
11364
11365
11366
11367
11368
11369
11370
11371
11372
11373
11374
11375
11376
11377
11378
11379
11380
11381
11382
11383
11384
11385
11386
11387
11388
11389
11390
11391
11392
11393
11394
11395
11396
11397
11398
11399
11400
11401
11402
11403
11404
11405
11406
11407
11408
11409
11410
11411
11412
11413
11414
11415
11416
11417
11418
11419
11420
11421
11422
11423
11424
11425
11426
11427
11428
11429
11430
11431
11432
11433
11434
11435
11436
11437
11438
11439
11440
11441
11442
11443
11444
11445
11446
11447
11448
11449
11450
11451
11452
11453
11454
11455
11456
11457
11458
11459
11460
11461
11462
11463
11464
11465
11466
11467
11468
11469
11470
11471
11472
11473
11474
11475
11476
11477
11478
11479
11480
11481
11482
11483
11484
11485
11486
11487
11488
11489
11490
11491
11492
11493
11494
11495
11496
11497
11498
11499
11500
11501
11502
11503
11504
11505
11506
11507
11508
11509
11510
11511
11512
11513
11514
11515
11516
11517
11518
11519
11520
11521
11522
11523
11524
11525
11526
11527
11528
11529
11530
11531
11532
11533
11534
11535
11536
11537
11538
11539
11540
11541
11542
11543
11544
11545
11546
11547
11548
11549
11550
11551
11552
11553
11554
11555
11556
11557
11558
11559
11560
11561
11562
11563
11564
11565
11566
11567
11568
11569
11570
11571
11572
11573
11574
11575
11576
11577
11578
11579
11580
11581
11582
11583
11584
11585
11586
11587
11588
11589
11590
11591
11592
11593
11594
11595
11596
11597
11598
11599
11600
11601
11602
11603
11604
11605
11606
11607
11608
11609
11610
11611
11612
11613
11614
11615
11616
11617
11618
11619
11620
11621
11622
11623
11624
11625
11626
11627
11628
11629
11630
11631
11632
11633
11634
11635
11636
11637
11638
11639
11640
11641
11642
11643
11644
11645
11646
11647
11648
11649
11650
11651
11652
11653
11654
11655
11656
11657
11658
11659
11660
11661
11662
11663
11664
11665
11666
11667
11668
11669
11670
11671
11672
11673
11674
11675
11676
11677
11678
11679
11680
11681
11682
11683
11684
11685
11686
11687
11688
11689
11690
11691
11692
11693
11694
11695
11696
11697
11698
11699
11700
11701
11702
11703
11704
11705
11706
11707
11708
11709
11710
11711
11712
11713
11714
11715
11716
11717
11718
11719
11720
11721
11722
11723
11724
11725
11726
11727
11728
11729
11730
11731
11732
11733
11734
11735
11736
11737
11738
11739
11740
11741
11742
11743
11744
11745
11746
11747
11748
11749
11750
11751
11752
11753
11754
11755
11756
11757
11758
11759
11760
11761
11762
11763
11764
11765
11766
11767
11768
11769
11770
11771
11772
11773
11774
11775
11776
11777
11778
11779
11780
11781
11782
11783
11784
11785
11786
11787
11788
11789
11790
11791
11792
11793
11794
11795
11796
11797
11798
11799
11800
11801
11802
11803
11804
11805
11806
11807
11808
11809
11810
11811
11812
11813
11814
11815
11816
11817
11818
11819
11820
11821
11822
11823
11824
11825
11826
11827
11828
11829
11830
11831
11832
11833
11834
11835
11836
11837
11838
11839
11840
11841
11842
11843
11844
11845
11846
11847
11848
11849
11850
11851
11852
11853
11854
11855
11856
11857
11858
11859
11860
11861
11862
11863
11864
11865
11866
11867
11868
11869
11870
11871
11872
11873
11874
11875
11876
11877
11878
11879
11880
11881
11882
11883
11884
11885
11886
11887
11888
11889
11890
11891
11892
11893
11894
11895
11896
11897
11898
11899
11900
11901
11902
11903
11904
11905
11906
11907
11908
11909
11910
11911
11912
11913
11914
11915
11916
11917
11918
11919
11920
11921
11922
11923
11924
11925
11926
11927
11928
11929
11930
11931
11932
11933
11934
11935
11936
11937
11938
11939
11940
11941
11942
11943
11944
11945
11946
11947
11948
11949
11950
11951
11952
11953
11954
11955
11956
11957
11958
11959
11960
11961
11962
11963
11964
11965
11966
11967
11968
11969
11970
11971
11972
11973
11974
11975
11976
11977
11978
11979
11980
11981
11982
11983
11984
11985
11986
11987
11988
11989
11990
11991
11992
11993
11994
11995
11996
11997
11998
11999
12000
12001
12002
12003
12004
12005
12006
12007
12008
12009
12010
12011
12012
12013
12014
12015
12016
12017
12018
12019
12020
12021
12022
12023
12024
12025
12026
12027
12028
12029
12030
12031
12032
12033
12034
12035
12036
12037
12038
12039
12040
12041
12042
12043
12044
12045
12046
12047
12048
12049
12050
12051
12052
12053
12054
12055
12056
12057
12058
12059
12060
12061
12062
12063
12064
12065
12066
12067
12068
12069
12070
12071
12072
12073
12074
12075
12076
12077
12078
12079
12080
12081
12082
12083
12084
12085
12086
12087
12088
12089
12090
12091
12092
12093
12094
12095
12096
12097
12098
12099
12100
12101
12102
12103
12104
12105
12106
12107
12108
12109
12110
12111
12112
12113
12114
12115
12116
12117
12118
12119
12120
12121
12122
12123
12124
12125
12126
12127
12128
12129
12130
12131
12132
12133
12134
12135
12136
12137
12138
12139
12140
12141
12142
12143
12144
12145
12146
12147
12148
12149
12150
12151
12152
12153
12154
12155
12156
12157
12158
12159
12160
12161
12162
12163
12164
12165
12166
12167
12168
12169
12170
12171
12172
12173
12174
12175
12176
12177
12178
12179
12180
12181
12182
12183
12184
12185
12186
12187
12188
12189
12190
12191
12192
12193
12194
12195
12196
12197
12198
12199
12200
12201
12202
12203
12204
12205
12206
12207
12208
12209
12210
12211
12212
12213
12214
12215
12216
12217
12218
12219
12220
12221
12222
12223
12224
12225
12226
12227
12228
12229
12230
12231
12232
12233
12234
12235
12236
12237
12238
12239
12240
12241
12242
12243
12244
12245
12246
12247
12248
12249
12250
12251
12252
12253
12254
12255
12256
12257
12258
12259
12260
12261
12262
12263
12264
12265
12266
12267
12268
12269
12270
12271
12272
12273
12274
12275
12276
12277
12278
12279
12280
12281
12282
12283
12284
12285
12286
12287
12288
12289
12290
12291
12292
12293
12294
12295
12296
12297
12298
12299
12300
12301
12302
12303
12304
12305
12306
12307
12308
12309
12310
12311
12312
12313
12314
12315
12316
12317
12318
12319
12320
12321
12322
12323
12324
12325
12326
12327
12328
12329
12330
12331
12332
12333
12334
12335
12336
12337
12338
12339
12340
12341
12342
12343
12344
12345
12346
12347
12348
12349
12350
12351
12352
12353
12354
12355
12356
12357
12358
12359
12360
12361
12362
12363
12364
12365
12366
12367
12368
12369
12370
12371
12372
12373
12374
12375
12376
12377
12378
12379
12380
12381
12382
12383
12384
12385
12386
12387
12388
12389
12390
12391
12392
12393
12394
12395
12396
12397
12398
12399
12400
12401
12402
12403
12404
12405
12406
12407
12408
12409
12410
12411
12412
12413
12414
12415
12416
12417
12418
12419
12420
12421
12422
12423
12424
12425
12426
12427
12428
12429
12430
12431
12432
12433
12434
12435
12436
12437
12438
12439
12440
12441
12442
12443
12444
12445
12446
12447
12448
12449
12450
12451
12452
12453
12454
12455
12456
12457
12458
12459
12460
12461
12462
12463
12464
12465
12466
12467
12468
12469
12470
12471
12472
12473
12474
12475
12476
12477
12478
12479
12480
12481
12482
12483
12484
12485
12486
12487
12488
12489
12490
12491
12492
12493
12494
12495
12496
12497
12498
12499
12500
12501
12502
12503
12504
12505
12506
12507
12508
12509
12510
12511
12512
12513
12514
12515
12516
12517
12518
12519
12520
12521
12522
12523
12524
12525
12526
12527
12528
12529
12530
12531
12532
12533
12534
12535
12536
12537
12538
12539
12540
12541
12542
12543
12544
12545
12546
12547
12548
12549
12550
12551
12552
12553
12554
12555
12556
12557
12558
12559
12560
12561
12562
12563
12564
12565
12566
12567
12568
12569
12570
12571
12572
12573
12574
12575
12576
12577
12578
12579
12580
12581
12582
12583
12584
12585
12586
12587
12588
12589
12590
12591
12592
12593
12594
12595
12596
12597
12598
12599
12600
12601
12602
12603
12604
12605
12606
12607
12608
12609
12610
12611
12612
12613
12614
12615
12616
12617
12618
12619
12620
12621
12622
12623
12624
12625
12626
12627
12628
12629
12630
12631
12632
12633
12634
12635
12636
12637
12638
12639
12640
12641
12642
12643
12644
12645
12646
12647
12648
12649
12650
12651
12652
12653
12654
12655
12656
12657
12658
12659
12660
12661
12662
12663
12664
12665
12666
12667
12668
12669
12670
12671
12672
12673
12674
12675
12676
12677
12678
12679
12680
12681
12682
12683
12684
12685
12686
12687
12688
12689
12690
12691
12692
12693
12694
12695
12696
12697
12698
12699
12700
12701
12702
12703
12704
12705
12706
12707
12708
12709
12710
12711
12712
12713
12714
12715
12716
12717
12718
12719
12720
12721
12722
12723
12724
12725
12726
12727
12728
12729
12730
12731
12732
12733
12734
12735
12736
12737
12738
12739
12740
12741
12742
12743
12744
12745
12746
12747
12748
12749
12750
12751
12752
12753
12754
12755
12756
12757
12758
12759
12760
12761
12762
12763
12764
12765
12766
12767
12768
12769
12770
12771
12772
12773
12774
12775
12776
12777
12778
12779
12780
12781
12782
12783
12784
12785
12786
12787
12788
12789
12790
12791
12792
12793
12794
12795
12796
12797
12798
12799
12800
12801
12802
12803
12804
12805
12806
12807
12808
12809
12810
12811
12812
12813
12814
12815
12816
12817
12818
12819
12820
12821
12822
12823
12824
12825
12826
12827
12828
12829
12830
12831
12832
12833
12834
12835
12836
12837
12838
12839
12840
12841
12842
12843
12844
12845
12846
12847
12848
12849
12850
12851
12852
12853
12854
12855
12856
12857
12858
12859
12860
12861
12862
12863
12864
12865
12866
12867
12868
12869
12870
12871
12872
12873
12874
12875
12876
12877
12878
12879
12880
12881
12882
12883
12884
12885
12886
12887
12888
12889
12890
12891
12892
12893
12894
12895
12896
12897
12898
12899
12900
12901
12902
12903
12904
12905
12906
12907
12908
12909
12910
12911
12912
12913
12914
12915
12916
12917
12918
12919
12920
12921
12922
12923
12924
12925
12926
12927
12928
12929
12930
12931
12932
12933
12934
12935
12936
12937
12938
12939
12940
12941
12942
12943
12944
12945
12946
12947
12948
12949
12950
12951
12952
12953
12954
12955
12956
12957
12958
12959
12960
12961
12962
12963
12964
12965
12966
12967
12968
12969
12970
12971
12972
12973
12974
12975
12976
12977
12978
12979
12980
12981
12982
12983
12984
12985
12986
12987
12988
12989
12990
12991
12992
12993
12994
12995
12996
12997
12998
12999
13000
13001
13002
13003
13004
13005
13006
13007
13008
13009
13010
13011
13012
13013
13014
13015
13016
13017
13018
13019
13020
13021
13022
13023
13024
13025
13026
13027
13028
13029
13030
13031
13032
13033
13034
13035
13036
13037
13038
13039
13040
13041
13042
13043
13044
13045
13046
13047
13048
13049
13050
13051
13052
13053
13054
13055
13056
13057
13058
13059
13060
13061
13062
13063
13064
13065
13066
13067
13068
13069
13070
13071
13072
13073
13074
13075
13076
13077
13078
13079
13080
13081
13082
13083
13084
13085
13086
13087
13088
13089
13090
13091
13092
13093
13094
13095
13096
13097
13098
13099
13100
13101
13102
13103
13104
13105
13106
13107
13108
13109
13110
13111
13112
13113
13114
13115
13116
13117
13118
13119
13120
13121
13122
13123
13124
13125
13126
13127
13128
13129
13130
13131
13132
13133
13134
13135
13136
13137
13138
13139
13140
13141
13142
13143
13144
13145
13146
13147
13148
13149
13150
13151
13152
13153
13154
13155
13156
13157
13158
13159
13160
13161
13162
13163
13164
13165
13166
13167
13168
13169
13170
13171
13172
13173
13174
13175
13176
13177
13178
13179
13180
13181
13182
13183
13184
13185
13186
13187
13188
13189
13190
13191
13192
13193
13194
13195
13196
13197
13198
13199
13200
13201
13202
13203
13204
13205
13206
13207
13208
13209
13210
13211
13212
13213
13214
13215
13216
13217
13218
13219
13220
13221
13222
13223
13224
13225
13226
13227
13228
13229
13230
13231
13232
13233
13234
13235
13236
13237
13238
13239
13240
13241
13242
13243
13244
13245
13246
13247
13248
13249
13250
13251
13252
13253
13254
13255
13256
13257
13258
13259
13260
13261
13262
13263
13264
13265
13266
13267
13268
13269
13270
13271
13272
13273
13274
13275
13276
13277
13278
13279
13280
13281
13282
13283
13284
13285
13286
13287
13288
13289
13290
13291
13292
13293
13294
13295
13296
13297
13298
13299
13300
13301
13302
13303
13304
13305
13306
13307
13308
13309
13310
13311
13312
13313
13314
13315
13316
13317
13318
13319
13320
13321
13322
13323
13324
13325
13326
13327
13328
13329
13330
13331
13332
13333
13334
13335
13336
13337
13338
13339
13340
13341
13342
13343
13344
13345
13346
13347
13348
13349
13350
13351
13352
13353
13354
13355
13356
13357
13358
13359
13360
13361
13362
13363
13364
13365
13366
13367
13368
13369
13370
13371
13372
13373
13374
13375
13376
13377
13378
13379
13380
13381
13382
13383
13384
13385
13386
13387
13388
13389
13390
13391
13392
13393
13394
13395
13396
13397
13398
13399
13400
13401
13402
13403
13404
13405
13406
13407
13408
13409
13410
13411
13412
13413
13414
13415
13416
13417
13418
13419
13420
13421
13422
13423
13424
13425
13426
13427
13428
13429
13430
13431
13432
13433
13434
13435
13436
13437
13438
13439
13440
13441
13442
13443
13444
13445
13446
13447
13448
13449
13450
13451
13452
13453
13454
13455
13456
13457
13458
13459
13460
13461
13462
13463
13464
13465
13466
13467
13468
13469
13470
13471
13472
13473
13474
13475
13476
13477
13478
13479
13480
13481
13482
13483
13484
13485
13486
13487
13488
13489
13490
13491
13492
13493
13494
13495
13496
13497
13498
13499
13500
13501
13502
13503
13504
13505
13506
13507
13508
13509
13510
13511
13512
13513
13514
13515
13516
13517
13518
13519
13520
13521
13522
13523
13524
13525
13526
13527
13528
13529
13530
13531
13532
13533
13534
13535
13536
13537
13538
13539
13540
13541
13542
13543
13544
13545
13546
13547
13548
13549
13550
13551
13552
13553
13554
13555
13556
13557
13558
13559
13560
13561
13562
13563
13564
13565
13566
13567
13568
13569
13570
13571
13572
13573
13574
13575
13576
13577
13578
13579
13580
13581
13582
13583
13584
13585
13586
13587
13588
13589
13590
13591
13592
13593
13594
13595
13596
13597
13598
13599
13600
13601
13602
13603
13604
13605
13606
13607
13608
13609
13610
13611
13612
13613
13614
13615
13616
13617
13618
13619
13620
13621
13622
13623
13624
13625
13626
13627
13628
13629
13630
13631
13632
13633
13634
13635
13636
13637
13638
13639
13640
13641
13642
13643
13644
13645
13646
13647
13648
13649
13650
13651
13652
13653
13654
13655
13656
13657
13658
13659
13660
13661
13662
13663
13664
13665
13666
13667
13668
13669
13670
13671
13672
13673
13674
13675
13676
13677
13678
13679
13680
13681
13682
13683
13684
13685
13686
13687
13688
13689
13690
13691
13692
13693
13694
13695
13696
13697
13698
13699
13700
13701
13702
13703
13704
13705
13706
13707
13708
13709
13710
13711
13712
13713
13714
13715
13716
13717
13718
13719
13720
13721
13722
13723
13724
13725
13726
13727
13728
13729
13730
13731
13732
13733
13734
13735
13736
13737
13738
13739
13740
13741
13742
13743
13744
13745
13746
13747
13748
13749
13750
13751
13752
13753
13754
13755
13756
13757
13758
13759
13760
13761
13762
13763
13764
13765
13766
13767
13768
13769
13770
13771
13772
13773
13774
13775
13776
13777
13778
13779
13780
13781
13782
13783
13784
13785
13786
13787
13788
13789
13790
13791
13792
13793
13794
13795
13796
13797
13798
13799
13800
13801
13802
13803
13804
13805
13806
13807
13808
13809
13810
13811
13812
13813
13814
13815
13816
13817
13818
13819
13820
13821
13822
13823
13824
13825
13826
13827
13828
13829
13830
13831
13832
13833
13834
13835
13836
13837
13838
13839
13840
13841
13842
13843
13844
13845
13846
13847
13848
13849
13850
13851
13852
13853
13854
13855
13856
13857
13858
13859
13860
13861
13862
13863
13864
13865
13866
13867
13868
13869
13870
13871
13872
13873
13874
13875
13876
13877
13878
13879
13880
13881
13882
13883
13884
13885
13886
13887
13888
13889
13890
13891
13892
13893
13894
13895
13896
13897
13898
13899
13900
13901
13902
13903
13904
13905
13906
13907
13908
13909
13910
13911
13912
13913
13914
13915
13916
13917
13918
13919
13920
13921
13922
13923
13924
13925
13926
13927
13928
13929
13930
13931
13932
13933
13934
13935
13936
13937
13938
13939
13940
13941
13942
13943
13944
13945
13946
13947
13948
13949
13950
13951
13952
13953
13954
13955
13956
13957
13958
13959
13960
13961
13962
13963
13964
13965
13966
13967
13968
13969
13970
13971
13972
13973
13974
13975
13976
13977
13978
13979
13980
13981
13982
13983
13984
13985
13986
13987
13988
13989
13990
13991
13992
13993
13994
13995
13996
13997
13998
13999
14000
14001
14002
14003
14004
14005
14006
14007
14008
14009
14010
14011
14012
14013
14014
14015
14016
14017
14018
14019
14020
14021
14022
14023
14024
14025
14026
14027
14028
14029
14030
14031
14032
14033
14034
14035
14036
14037
14038
14039
14040
14041
14042
14043
14044
14045
14046
14047
14048
14049
14050
14051
14052
14053
14054
14055
14056
14057
14058
14059
14060
14061
14062
14063
14064
14065
14066
14067
14068
14069
14070
14071
14072
14073
14074
14075
14076
14077
14078
14079
14080
14081
14082
14083
14084
14085
14086
14087
14088
14089
14090
14091
14092
14093
14094
14095
14096
14097
14098
14099
14100
14101
14102
14103
14104
14105
14106
14107
14108
14109
14110
14111
14112
14113
14114
14115
14116
14117
14118
14119
14120
14121
14122
14123
14124
14125
14126
14127
14128
14129
14130
14131
14132
14133
14134
14135
14136
14137
14138
14139
14140
14141
14142
14143
14144
14145
14146
14147
14148
14149
14150
14151
14152
14153
14154
14155
14156
14157
14158
14159
14160
14161
14162
14163
14164
14165
14166
14167
14168
14169
14170
14171
14172
14173
14174
14175
14176
14177
14178
14179
14180
14181
14182
14183
14184
14185
14186
14187
14188
14189
14190
14191
14192
14193
14194
14195
14196
14197
14198
14199
14200
14201
14202
14203
14204
14205
14206
14207
14208
14209
14210
14211
14212
14213
14214
14215
14216
14217
14218
14219
14220
14221
14222
14223
14224
14225
14226
14227
14228
14229
14230
14231
14232
14233
14234
14235
14236
14237
14238
14239
14240
14241
14242
14243
14244
14245
14246
14247
14248
14249
14250
14251
14252
14253
14254
14255
14256
14257
14258
14259
14260
14261
14262
14263
14264
14265
14266
14267
14268
14269
14270
14271
14272
14273
14274
14275
14276
14277
14278
14279
14280
14281
14282
14283
14284
14285
14286
14287
14288
14289
14290
14291
14292
14293
14294
14295
14296
14297
14298
14299
14300
14301
14302
14303
14304
14305
14306
14307
14308
14309
14310
14311
14312
14313
14314
14315
14316
14317
14318
14319
14320
14321
14322
14323
14324
14325
14326
14327
14328
14329
14330
14331
14332
14333
14334
14335
14336
14337
14338
14339
14340
14341
14342
14343
14344
14345
14346
14347
14348
14349
14350
14351
14352
14353
14354
14355
14356
14357
14358
14359
14360
14361
14362
14363
14364
14365
14366
14367
14368
14369
14370
14371
14372
14373
14374
14375
14376
14377
14378
14379
14380
14381
14382
14383
14384
14385
14386
14387
14388
14389
14390
14391
14392
14393
14394
14395
14396
14397
14398
14399
14400
14401
14402
14403
14404
14405
14406
14407
14408
14409
14410
14411
14412
14413
14414
14415
14416
14417
14418
14419
14420
14421
14422
14423
14424
14425
14426
14427
14428
14429
14430
14431
14432
14433
14434
14435
14436
14437
14438
14439
14440
14441
14442
14443
14444
14445
14446
14447
14448
14449
14450
14451
14452
14453
14454
14455
14456
14457
14458
14459
14460
14461
14462
14463
14464
14465
14466
14467
14468
14469
14470
14471
14472
14473
14474
14475
14476
14477
14478
14479
14480
14481
14482
14483
14484
14485
14486
14487
14488
14489
14490
14491
14492
14493
14494
14495
14496
14497
14498
14499
14500
14501
14502
14503
14504
14505
14506
14507
14508
14509
14510
14511
14512
14513
14514
14515
14516
14517
14518
14519
14520
14521
14522
14523
14524
14525
14526
14527
14528
14529
14530
14531
14532
14533
14534
14535
14536
14537
14538
14539
14540
14541
14542
14543
14544
14545
14546
14547
14548
14549
14550
14551
14552
14553
14554
14555
14556
14557
14558
14559
14560
14561
14562
14563
14564
14565
14566
14567
14568
14569
14570
14571
14572
14573
14574
14575
14576
14577
14578
14579
14580
14581
14582
14583
14584
14585
14586
14587
14588
14589
14590
14591
14592
14593
14594
14595
14596
14597
14598
14599
14600
14601
14602
14603
14604
14605
14606
14607
14608
14609
14610
14611
14612
14613
14614
14615
14616
14617
14618
14619
14620
14621
14622
14623
14624
14625
14626
14627
14628
14629
14630
14631
14632
14633
14634
14635
14636
14637
14638
14639
14640
14641
14642
14643
14644
14645
14646
14647
14648
14649
14650
14651
14652
14653
14654
14655
14656
14657
14658
14659
14660
14661
14662
14663
14664
14665
14666
14667
14668
14669
14670
14671
14672
14673
14674
14675
14676
14677
14678
14679
14680
14681
14682
14683
14684
14685
14686
14687
14688
14689
14690
14691
14692
14693
14694
14695
14696
14697
14698
14699
14700
14701
14702
14703
14704
14705
14706
14707
14708
14709
14710
14711
14712
14713
14714
14715
14716
14717
14718
14719
14720
14721
14722
14723
14724
14725
14726
14727
14728
14729
14730
14731
14732
14733
14734
14735
14736
14737
14738
14739
14740
14741
14742
14743
14744
14745
14746
14747
14748
14749
14750
14751
14752
14753
14754
14755
14756
14757
14758
14759
14760
14761
14762
14763
14764
14765
14766
14767
14768
14769
14770
14771
14772
14773
14774
14775
14776
14777
14778
14779
14780
14781
14782
14783
14784
14785
14786
14787
14788
14789
14790
14791
14792
14793
14794
14795
14796
14797
14798
14799
14800
14801
14802
14803
14804
14805
14806
14807
14808
14809
14810
14811
14812
14813
14814
14815
14816
14817
14818
14819
14820
14821
14822
14823
14824
14825
14826
14827
14828
14829
14830
14831
14832
14833
14834
14835
14836
14837
14838
14839
14840
14841
14842
14843
14844
14845
14846
14847
14848
14849
14850
14851
14852
14853
14854
14855
14856
14857
14858
14859
14860
14861
14862
14863
14864
14865
14866
14867
14868
14869
14870
14871
14872
14873
14874
14875
14876
14877
14878
14879
14880
14881
14882
14883
14884
14885
14886
14887
14888
14889
14890
14891
14892
14893
14894
14895
14896
14897
14898
14899
14900
14901
14902
14903
14904
14905
14906
14907
14908
14909
14910
14911
14912
14913
14914
14915
14916
14917
14918
14919
14920
14921
14922
14923
14924
14925
14926
14927
14928
14929
14930
14931
14932
14933
14934
14935
14936
14937
14938
14939
14940
14941
14942
14943
14944
14945
14946
14947
14948
14949
14950
14951
14952
14953
14954
14955
14956
14957
14958
14959
14960
14961
14962
14963
14964
14965
14966
14967
14968
14969
14970
14971
14972
14973
14974
14975
14976
14977
14978
14979
14980
14981
14982
14983
14984
14985
14986
14987
14988
14989
14990
14991
14992
14993
14994
14995
14996
14997
14998
14999
15000
15001
15002
15003
15004
15005
15006
15007
15008
15009
15010
15011
15012
15013
15014
15015
15016
15017
15018
15019
15020
15021
15022
15023
15024
15025
15026
15027
15028
15029
15030
15031
15032
15033
15034
15035
15036
15037
15038
15039
15040
15041
15042
15043
15044
15045
15046
15047
15048
15049
15050
15051
15052
15053
15054
15055
15056
15057
15058
15059
15060
15061
15062
15063
15064
15065
15066
15067
15068
15069
15070
15071
15072
15073
15074
15075
15076
15077
15078
15079
15080
15081
15082
15083
15084
15085
15086
15087
15088
15089
15090
15091
15092
15093
15094
15095
15096
15097
15098
15099
15100
15101
15102
15103
15104
15105
15106
15107
15108
15109
15110
15111
15112
15113
15114
15115
15116
15117
15118
15119
15120
15121
15122
15123
15124
15125
15126
15127
15128
15129
15130
15131
15132
15133
15134
15135
15136
15137
15138
15139
15140
15141
15142
15143
15144
15145
15146
15147
15148
15149
15150
15151
15152
15153
15154
15155
15156
15157
15158
15159
15160
15161
15162
15163
15164
15165
15166
15167
15168
15169
15170
15171
15172
15173
15174
15175
15176
15177
15178
15179
15180
15181
15182
15183
15184
15185
15186
15187
15188
15189
15190
15191
15192
15193
15194
15195
15196
15197
15198
15199
15200
15201
15202
15203
15204
15205
15206
15207
15208
15209
15210
15211
15212
15213
15214
15215
15216
15217
15218
15219
15220
15221
15222
15223
15224
15225
15226
15227
15228
15229
15230
15231
15232
15233
15234
15235
15236
15237
15238
15239
15240
15241
15242
15243
15244
15245
15246
15247
15248
15249
15250
15251
15252
15253
15254
15255
15256
15257
15258
15259
15260
15261
15262
15263
15264
15265
15266
15267
15268
15269
15270
15271
15272
15273
15274
15275
15276
15277
15278
15279
15280
15281
15282
15283
15284
15285
15286
15287
15288
15289
15290
15291
15292
15293
15294
15295
15296
15297
15298
15299
15300
15301
15302
15303
15304
15305
15306
15307
15308
15309
15310
15311
15312
15313
15314
15315
15316
15317
15318
15319
15320
15321
15322
15323
15324
15325
15326
15327
15328
15329
15330
15331
15332
15333
15334
15335
15336
15337
15338
15339
15340
15341
15342
15343
15344
15345
15346
15347
15348
15349
15350
15351
15352
15353
15354
15355
15356
15357
15358
15359
15360
15361
15362
15363
15364
15365
15366
15367
15368
15369
15370
15371
15372
15373
15374
15375
15376
15377
15378
15379
15380
15381
15382
15383
15384
15385
15386
15387
15388
15389
15390
15391
15392
15393
15394
15395
15396
15397
15398
15399
15400
15401
15402
15403
15404
15405
15406
15407
15408
15409
15410
15411
15412
15413
15414
15415
15416
15417
15418
15419
15420
15421
15422
15423
15424
15425
15426
15427
15428
15429
15430
15431
15432
15433
15434
15435
15436
15437
15438
15439
15440
15441
15442
15443
15444
15445
15446
15447
15448
15449
15450
15451
15452
15453
15454
15455
15456
15457
15458
15459
15460
15461
15462
15463
15464
15465
15466
15467
15468
15469
15470
15471
15472
15473
15474
15475
15476
15477
15478
15479
15480
15481
15482
15483
15484
15485
15486
15487
15488
15489
15490
15491
15492
15493
15494
15495
15496
15497
15498
15499
15500
15501
15502
15503
15504
15505
15506
15507
15508
15509
15510
15511
15512
15513
15514
15515
15516
15517
15518
15519
15520
15521
15522
15523
15524
15525
15526
15527
15528
15529
15530
15531
15532
15533
15534
15535
15536
15537
15538
15539
15540
15541
15542
15543
15544
15545
15546
15547
15548
15549
15550
15551
15552
15553
15554
15555
15556
15557
15558
15559
15560
15561
15562
15563
15564
15565
15566
15567
15568
15569
15570
15571
15572
15573
15574
15575
15576
15577
15578
15579
15580
15581
15582
15583
15584
15585
15586
15587
15588
15589
15590
15591
15592
15593
15594
15595
15596
15597
15598
15599
15600
15601
15602
15603
15604
15605
15606
15607
15608
15609
15610
15611
15612
15613
15614
15615
15616
15617
15618
15619
15620
15621
15622
15623
15624
15625
15626
15627
15628
15629
15630
15631
15632
15633
15634
15635
15636
15637
15638
15639
15640
15641
15642
15643
15644
15645
15646
15647
15648
15649
15650
15651
15652
15653
15654
15655
15656
15657
15658
15659
15660
15661
15662
15663
15664
15665
15666
15667
15668
15669
15670
15671
15672
15673
15674
15675
15676
15677
15678
15679
15680
15681
15682
15683
15684
15685
15686
15687
15688
15689
15690
15691
15692
15693
15694
15695
15696
15697
15698
15699
15700
15701
15702
15703
15704
15705
15706
15707
15708
15709
15710
15711
15712
15713
15714
15715
15716
15717
15718
15719
15720
15721
15722
15723
15724
15725
15726
15727
15728
15729
15730
15731
15732
15733
15734
15735
15736
15737
15738
15739
15740
15741
15742
15743
15744
15745
15746
15747
15748
15749
15750
15751
15752
15753
15754
15755
15756
15757
15758
15759
15760
15761
15762
15763
15764
15765
15766
15767
15768
15769
15770
15771
15772
15773
15774
15775
15776
15777
15778
15779
15780
15781
15782
15783
15784
15785
15786
15787
15788
15789
15790
15791
15792
15793
15794
15795
15796
15797
15798
15799
15800
15801
15802
15803
15804
15805
15806
15807
15808
15809
15810
15811
15812
15813
15814
15815
15816
15817
15818
15819
15820
15821
15822
15823
15824
15825
15826
15827
15828
15829
15830
15831
15832
15833
15834
15835
15836
15837
15838
15839
15840
15841
15842
15843
15844
15845
15846
15847
15848
15849
15850
15851
15852
15853
15854
15855
15856
15857
15858
15859
15860
15861
15862
15863
15864
15865
15866
15867
15868
15869
15870
15871
15872
15873
15874
15875
15876
15877
15878
15879
15880
15881
15882
15883
15884
15885
15886
15887
15888
15889
15890
15891
15892
15893
15894
15895
15896
15897
15898
15899
15900
15901
15902
15903
15904
15905
15906
15907
15908
15909
15910
15911
15912
15913
15914
15915
15916
15917
15918
15919
15920
15921
15922
15923
15924
15925
15926
15927
15928
15929
15930
15931
15932
15933
15934
15935
15936
15937
15938
15939
15940
15941
15942
15943
15944
15945
15946
15947
15948
15949
15950
15951
15952
15953
15954
15955
15956
15957
15958
15959
15960
15961
15962
15963
15964
15965
15966
15967
15968
15969
15970
15971
15972
15973
15974
15975
15976
15977
15978
15979
15980
15981
15982
15983
15984
15985
15986
15987
15988
15989
15990
15991
15992
15993
15994
15995
15996
15997
15998
15999
16000
16001
16002
16003
16004
16005
16006
16007
16008
16009
16010
16011
16012
16013
16014
16015
16016
16017
16018
16019
16020
16021
16022
16023
16024
16025
16026
16027
16028
16029
16030
16031
16032
16033
16034
16035
16036
16037
16038
16039
16040
16041
16042
16043
16044
16045
16046
16047
16048
16049
16050
16051
16052
16053
16054
16055
16056
16057
16058
16059
16060
16061
16062
16063
16064
16065
16066
16067
16068
16069
16070
16071
16072
16073
16074
16075
16076
16077
16078
16079
16080
16081
16082
16083
16084
16085
16086
16087
16088
16089
16090
16091
16092
16093
16094
16095
16096
16097
16098
16099
16100
16101
16102
16103
16104
16105
16106
16107
16108
16109
16110
16111
16112
16113
16114
16115
16116
16117
16118
16119
16120
16121
16122
16123
16124
16125
16126
16127
16128
16129
16130
16131
16132
16133
16134
16135
16136
16137
16138
16139
16140
16141
16142
16143
16144
16145
16146
16147
16148
16149
16150
16151
16152
16153
16154
16155
16156
16157
16158
16159
16160
16161
16162
16163
16164
16165
16166
16167
16168
16169
16170
16171
16172
16173
16174
16175
16176
16177
16178
16179
16180
16181
16182
16183
16184
16185
16186
16187
16188
16189
16190
16191
16192
16193
16194
16195
16196
16197
16198
16199
16200
16201
16202
16203
16204
16205
16206
16207
16208
16209
16210
16211
16212
16213
16214
16215
16216
16217
16218
16219
16220
16221
16222
16223
16224
16225
16226
16227
16228
16229
16230
16231
16232
16233
16234
16235
16236
16237
16238
16239
16240
16241
16242
16243
16244
16245
16246
16247
16248
16249
16250
16251
16252
16253
16254
16255
16256
16257
16258
16259
16260
16261
16262
16263
16264
16265
16266
16267
16268
16269
16270
16271
16272
16273
16274
16275
16276
16277
16278
16279
16280
16281
16282
16283
16284
16285
16286
16287
16288
16289
16290
16291
16292
16293
16294
16295
16296
16297
16298
16299
16300
16301
16302
16303
16304
16305
16306
16307
16308
16309
16310
16311
16312
16313
16314
16315
16316
16317
16318
16319
16320
16321
16322
16323
16324
16325
16326
16327
16328
16329
16330
16331
16332
16333
16334
16335
16336
16337
16338
16339
16340
16341
16342
16343
16344
16345
16346
16347
16348
16349
16350
16351
16352
16353
16354
16355
16356
16357
16358
16359
16360
16361
16362
16363
16364
16365
16366
16367
16368
16369
16370
16371
16372
16373
16374
16375
16376
16377
16378
16379
16380
16381
16382
16383
16384
16385
16386
16387
16388
16389
16390
16391
16392
16393
16394
16395
16396
16397
16398
16399
16400
16401
16402
16403
16404
16405
16406
16407
16408
16409
16410
16411
16412
16413
16414
16415
16416
16417
16418
16419
16420
16421
16422
16423
16424
16425
16426
16427
16428
16429
16430
16431
16432
16433
16434
16435
16436
16437
16438
16439
16440
16441
16442
16443
16444
16445
16446
16447
16448
16449
16450
16451
16452
16453
16454
16455
16456
16457
16458
16459
16460
16461
16462
16463
16464
16465
16466
16467
16468
16469
16470
16471
16472
16473
16474
16475
16476
16477
16478
16479
16480
16481
16482
16483
16484
16485
16486
16487
16488
16489
16490
16491
16492
16493
16494
16495
16496
16497
16498
16499
16500
16501
16502
16503
16504
16505
16506
16507
16508
16509
16510
16511
16512
16513
16514
16515
16516
16517
16518
16519
16520
16521
16522
16523
16524
16525
16526
16527
16528
16529
16530
16531
16532
16533
16534
16535
16536
16537
16538
16539
16540
16541
16542
16543
16544
16545
16546
16547
16548
16549
16550
16551
16552
16553
16554
16555
16556
16557
16558
16559
16560
16561
16562
16563
16564
16565
16566
16567
16568
16569
16570
16571
16572
16573
16574
16575
16576
16577
16578
16579
16580
16581
16582
16583
16584
16585
16586
16587
16588
16589
16590
16591
16592
16593
16594
16595
16596
16597
16598
16599
16600
16601
16602
16603
16604
16605
16606
16607
16608
16609
16610
16611
16612
16613
16614
16615
16616
16617
16618
16619
16620
16621
16622
16623
16624
16625
16626
16627
16628
16629
16630
16631
16632
16633
16634
16635
16636
16637
16638
16639
16640
16641
16642
16643
16644
16645
16646
16647
16648
16649
16650
16651
16652
16653
16654
16655
16656
16657
16658
16659
16660
16661
16662
16663
16664
16665
16666
16667
16668
16669
16670
16671
16672
16673
16674
16675
16676
16677
16678
16679
16680
16681
16682
16683
16684
16685
16686
16687
16688
16689
16690
16691
16692
16693
16694
16695
16696
16697
16698
16699
16700
16701
16702
16703
16704
16705
16706
16707
16708
16709
16710
16711
16712
16713
16714
16715
16716
16717
16718
16719
16720
16721
16722
16723
16724
16725
16726
16727
16728
16729
16730
16731
16732
16733
16734
16735
16736
16737
16738
16739
16740
16741
16742
16743
16744
16745
16746
16747
16748
16749
16750
16751
16752
16753
16754
16755
16756
16757
16758
16759
16760
16761
16762
16763
16764
16765
16766
16767
16768
16769
16770
16771
16772
16773
16774
16775
16776
16777
16778
16779
16780
16781
16782
16783
16784
16785
16786
16787
16788
16789
16790
16791
16792
16793
16794
16795
16796
16797
16798
16799
16800
16801
16802
16803
16804
16805
16806
16807
16808
16809
16810
16811
16812
16813
16814
16815
16816
16817
16818
16819
16820
16821
16822
16823
16824
16825
16826
16827
16828
16829
16830
16831
16832
16833
16834
16835
16836
16837
16838
16839
16840
16841
16842
16843
16844
16845
16846
16847
16848
16849
16850
16851
16852
16853
16854
16855
16856
16857
16858
16859
16860
16861
16862
16863
16864
16865
16866
16867
16868
16869
16870
16871
16872
16873
16874
16875
16876
16877
16878
16879
16880
16881
16882
16883
16884
16885
16886
16887
16888
16889
16890
16891
16892
16893
16894
16895
16896
16897
16898
16899
16900
16901
16902
16903
16904
16905
16906
16907
16908
16909
16910
16911
16912
16913
16914
16915
16916
16917
16918
16919
16920
16921
16922
16923
16924
16925
16926
16927
16928
16929
16930
16931
16932
16933
16934
16935
16936
16937
16938
16939
16940
16941
16942
16943
16944
16945
16946
16947
16948
16949
16950
16951
16952
16953
16954
16955
16956
16957
16958
16959
16960
16961
16962
16963
16964
16965
16966
16967
16968
16969
16970
16971
16972
16973
16974
16975
16976
16977
16978
16979
16980
16981
16982
16983
16984
16985
16986
16987
16988
16989
16990
16991
16992
16993
16994
16995
16996
16997
16998
16999
17000
17001
17002
17003
17004
17005
17006
17007
17008
17009
17010
17011
17012
17013
17014
17015
17016
17017
17018
17019
17020
17021
17022
17023
17024
17025
17026
17027
17028
17029
17030
17031
17032
17033
17034
17035
17036
17037
17038
17039
17040
17041
17042
17043
17044
17045
17046
17047
17048
17049
17050
17051
17052
17053
17054
17055
17056
17057
17058
17059
17060
17061
17062
17063
17064
17065
17066
17067
17068
17069
17070
17071
17072
17073
17074
17075
17076
17077
17078
17079
17080
17081
17082
17083
17084
17085
17086
17087
17088
17089
17090
17091
17092
17093
17094
17095
17096
17097
17098
17099
17100
17101
17102
17103
17104
17105
17106
17107
17108
17109
17110
17111
17112
17113
17114
17115
17116
17117
17118
17119
17120
17121
17122
17123
17124
17125
17126
17127
17128
17129
17130
17131
17132
17133
17134
17135
17136
17137
17138
17139
17140
17141
17142
17143
17144
17145
17146
17147
17148
17149
17150
17151
17152
17153
17154
17155
17156
17157
17158
17159
17160
17161
17162
17163
17164
17165
17166
17167
17168
17169
17170
17171
17172
17173
17174
17175
17176
17177
17178
17179
17180
17181
17182
17183
17184
17185
17186
17187
17188
17189
17190
17191
17192
17193
17194
17195
17196
17197
17198
17199
17200
17201
17202
17203
17204
17205
17206
17207
17208
17209
17210
17211
17212
17213
17214
17215
17216
17217
17218
17219
17220
17221
17222
17223
17224
17225
17226
17227
17228
17229
17230
17231
17232
17233
17234
17235
17236
17237
17238
17239
17240
17241
17242
17243
17244
17245
17246
17247
17248
17249
17250
17251
17252
17253
17254
17255
17256
17257
17258
17259
17260
17261
17262
17263
17264
17265
17266
17267
17268
17269
17270
17271
17272
17273
17274
17275
17276
17277
17278
17279
17280
17281
17282
17283
17284
17285
17286
17287
17288
17289
17290
17291
17292
17293
17294
17295
17296
17297
17298
17299
17300
17301
17302
17303
17304
17305
17306
17307
17308
17309
17310
17311
17312
17313
17314
17315
17316
17317
17318
17319
17320
17321
17322
17323
17324
17325
17326
17327
17328
17329
17330
17331
17332
17333
17334
17335
17336
17337
17338
17339
17340
17341
17342
17343
17344
17345
17346
17347
17348
17349
17350
17351
17352
17353
17354
17355
17356
17357
17358
17359
17360
17361
17362
17363
17364
17365
17366
17367
17368
17369
17370
17371
17372
17373
17374
17375
17376
17377
17378
17379
17380
17381
17382
17383
17384
17385
17386
17387
17388
17389
17390
17391
17392
17393
17394
17395
17396
17397
17398
17399
17400
17401
17402
17403
17404
17405
17406
17407
17408
17409
17410
17411
17412
17413
17414
17415
17416
17417
17418
17419
17420
17421
17422
17423
17424
17425
17426
17427
17428
17429
17430
17431
17432
17433
17434
17435
17436
17437
17438
17439
17440
17441
17442
17443
17444
17445
17446
17447
17448
17449
17450
17451
17452
17453
17454
17455
17456
17457
17458
17459
17460
17461
17462
17463
17464
17465
17466
17467
17468
17469
17470
17471
17472
17473
17474
17475
17476
17477
17478
17479
17480
17481
17482
17483
17484
17485
17486
17487
17488
17489
17490
17491
17492
17493
17494
17495
17496
17497
17498
17499
17500
17501
17502
17503
17504
17505
17506
17507
17508
17509
17510
17511
17512
17513
17514
17515
17516
17517
17518
17519
17520
17521
17522
17523
17524
17525
17526
17527
17528
17529
17530
17531
17532
17533
17534
17535
17536
17537
17538
17539
17540
17541
17542
17543
17544
17545
17546
17547
17548
17549
17550
17551
17552
17553
17554
17555
17556
17557
17558
17559
17560
17561
17562
17563
17564
17565
17566
17567
17568
17569
17570
17571
17572
17573
17574
17575
17576
17577
17578
17579
17580
17581
17582
17583
17584
17585
17586
17587
17588
17589
17590
17591
17592
17593
17594
17595
17596
17597
17598
17599
17600
17601
17602
17603
17604
17605
17606
17607
17608
17609
17610
17611
17612
17613
17614
17615
17616
17617
17618
17619
17620
17621
17622
17623
17624
17625
17626
17627
17628
17629
17630
17631
17632
17633
17634
17635
17636
17637
17638
17639
17640
17641
17642
17643
17644
17645
17646
17647
17648
17649
17650
17651
17652
17653
17654
17655
17656
17657
17658
17659
17660
17661
17662
17663
17664
17665
17666
17667
17668
17669
17670
17671
17672
17673
17674
17675
17676
17677
17678
17679
17680
17681
17682
17683
17684
17685
17686
17687
17688
17689
17690
17691
17692
17693
17694
17695
17696
17697
17698
17699
17700
17701
17702
17703
17704
17705
17706
17707
17708
17709
17710
17711
17712
17713
17714
17715
17716
17717
17718
17719
17720
17721
17722
17723
17724
17725
17726
17727
17728
17729
17730
17731
17732
17733
17734
17735
17736
17737
17738
17739
17740
17741
17742
17743
17744
17745
17746
17747
17748
17749
17750
17751
17752
17753
17754
17755
17756
17757
17758
17759
17760
17761
17762
17763
17764
17765
17766
17767
17768
17769
17770
17771
17772
17773
17774
17775
17776
17777
17778
17779
17780
17781
17782
17783
17784
17785
17786
17787
17788
17789
17790
17791
17792
17793
17794
17795
17796
17797
17798
17799
17800
17801
17802
17803
17804
17805
17806
17807
17808
17809
17810
17811
17812
17813
17814
17815
17816
17817
17818
17819
17820
17821
17822
17823
17824
17825
17826
17827
17828
17829
17830
17831
17832
17833
17834
17835
17836
17837
17838
17839
17840
17841
17842
17843
17844
17845
17846
17847
17848
17849
17850
17851
17852
17853
17854
17855
17856
17857
17858
17859
17860
17861
17862
17863
17864
17865
17866
17867
17868
17869
17870
17871
17872
17873
17874
17875
17876
17877
17878
17879
17880
17881
17882
17883
17884
17885
17886
17887
17888
17889
17890
17891
17892
17893
17894
17895
17896
17897
17898
17899
17900
17901
17902
17903
17904
17905
17906
17907
17908
17909
17910
17911
17912
17913
17914
17915
17916
17917
17918
17919
17920
17921
17922
17923
17924
17925
17926
17927
17928
17929
17930
17931
17932
17933
17934
17935
17936
17937
17938
17939
17940
17941
17942
17943
17944
17945
17946
17947
17948
17949
17950
17951
17952
17953
17954
17955
17956
17957
17958
17959
17960
17961
17962
17963
17964
17965
17966
17967
17968
17969
17970
17971
17972
17973
17974
17975
17976
17977
17978
17979
17980
17981
17982
17983
17984
17985
17986
17987
17988
17989
17990
17991
17992
17993
17994
17995
17996
17997
17998
17999
18000
18001
18002
18003
18004
18005
18006
18007
18008
18009
18010
18011
18012
18013
18014
18015
18016
18017
18018
18019
18020
18021
18022
18023
18024
18025
18026
18027
18028
18029
18030
18031
18032
18033
18034
18035
18036
18037
18038
18039
18040
18041
18042
18043
18044
18045
18046
18047
18048
18049
18050
18051
18052
18053
18054
18055
18056
18057
18058
18059
18060
18061
18062
18063
18064
18065
18066
18067
18068
18069
18070
18071
18072
18073
18074
18075
18076
18077
18078
18079
18080
18081
18082
18083
18084
18085
18086
18087
18088
18089
18090
18091
18092
18093
18094
18095
18096
18097
18098
18099
18100
18101
18102
18103
18104
18105
18106
18107
18108
18109
18110
18111
18112
18113
18114
18115
18116
18117
18118
18119
18120
18121
18122
18123
18124
18125
18126
18127
18128
18129
18130
18131
18132
18133
18134
18135
18136
18137
18138
18139
18140
18141
18142
18143
18144
18145
18146
18147
18148
18149
18150
18151
18152
18153
18154
18155
18156
18157
18158
18159
18160
18161
18162
18163
18164
18165
18166
18167
18168
18169
18170
18171
18172
18173
18174
18175
18176
18177
18178
18179
18180
18181
18182
18183
18184
18185
18186
18187
18188
18189
18190
18191
18192
18193
18194
18195
18196
18197
18198
18199
18200
18201
18202
18203
18204
18205
18206
18207
18208
18209
18210
18211
18212
18213
18214
18215
18216
18217
18218
18219
18220
18221
18222
18223
18224
18225
18226
18227
18228
18229
18230
18231
18232
18233
18234
18235
18236
18237
18238
18239
18240
18241
18242
18243
18244
18245
18246
18247
18248
18249
18250
18251
18252
18253
18254
18255
18256
18257
18258
18259
18260
18261
18262
18263
18264
18265
18266
18267
18268
18269
18270
18271
18272
18273
18274
18275
18276
18277
18278
18279
18280
18281
18282
18283
18284
18285
18286
18287
18288
18289
18290
18291
18292
18293
18294
18295
18296
18297
18298
18299
18300
18301
18302
18303
18304
18305
18306
18307
18308
18309
18310
18311
18312
18313
18314
18315
18316
18317
18318
18319
18320
18321
18322
18323
18324
18325
18326
18327
18328
18329
18330
18331
18332
18333
18334
18335
18336
18337
18338
18339
18340
18341
18342
18343
18344
18345
18346
18347
18348
18349
18350
18351
18352
18353
18354
18355
18356
18357
18358
18359
18360
18361
18362
18363
18364
18365
18366
18367
18368
18369
18370
18371
18372
18373
18374
18375
18376
18377
18378
18379
18380
18381
18382
18383
18384
18385
18386
18387
18388
18389
18390
18391
18392
18393
18394
18395
18396
18397
18398
18399
18400
18401
18402
18403
18404
18405
18406
18407
18408
18409
18410
18411
18412
18413
18414
18415
18416
18417
18418
18419
18420
18421
18422
18423
18424
18425
18426
18427
18428
18429
18430
18431
18432
18433
18434
18435
18436
18437
18438
18439
18440
18441
18442
18443
18444
18445
18446
18447
18448
18449
18450
18451
18452
18453
18454
18455
18456
18457
18458
18459
18460
18461
18462
18463
18464
18465
18466
18467
18468
18469
18470
18471
18472
18473
18474
18475
18476
18477
18478
18479
18480
18481
18482
18483
18484
18485
18486
18487
18488
18489
18490
18491
18492
18493
18494
18495
18496
18497
18498
18499
18500
18501
18502
18503
18504
18505
18506
18507
18508
18509
18510
18511
18512
18513
18514
18515
18516
18517
18518
18519
18520
18521
18522
18523
18524
18525
18526
18527
18528
18529
18530
18531
18532
18533
18534
18535
18536
18537
18538
18539
18540
18541
18542
18543
18544
18545
18546
18547
18548
18549
18550
18551
18552
18553
18554
18555
18556
18557
18558
18559
18560
18561
18562
18563
18564
18565
18566
18567
18568
18569
18570
18571
18572
18573
18574
18575
18576
18577
18578
18579
18580
18581
18582
18583
18584
18585
18586
18587
18588
18589
18590
18591
18592
18593
18594
18595
18596
18597
18598
18599
18600
18601
18602
18603
18604
18605
18606
18607
18608
18609
18610
18611
18612
18613
18614
18615
18616
18617
18618
18619
18620
18621
18622
18623
18624
18625
18626
18627
18628
18629
18630
18631
18632
18633
18634
18635
18636
18637
18638
18639
18640
18641
18642
18643
18644
18645
18646
18647
18648
18649
18650
18651
18652
18653
18654
18655
18656
18657
18658
18659
18660
18661
18662
18663
18664
18665
18666
18667
18668
18669
18670
18671
18672
18673
18674
18675
18676
18677
18678
18679
18680
18681
18682
18683
18684
18685
18686
18687
18688
18689
18690
18691
18692
18693
18694
18695
18696
18697
18698
18699
18700
18701
18702
18703
18704
18705
18706
18707
18708
18709
18710
18711
18712
18713
18714
18715
18716
18717
18718
18719
18720
18721
18722
18723
18724
18725
18726
18727
18728
18729
18730
18731
18732
18733
18734
18735
18736
18737
18738
18739
18740
18741
18742
18743
18744
18745
18746
18747
18748
18749
18750
18751
18752
18753
18754
18755
18756
18757
18758
18759
18760
18761
18762
18763
18764
18765
18766
18767
18768
18769
18770
18771
18772
18773
18774
18775
18776
18777
18778
18779
18780
18781
18782
18783
18784
18785
18786
18787
18788
18789
18790
18791
18792
18793
18794
18795
18796
18797
18798
18799
18800
18801
18802
18803
18804
18805
18806
18807
18808
18809
18810
18811
18812
18813
18814
18815
18816
18817
18818
18819
18820
18821
18822
18823
18824
18825
18826
18827
18828
18829
18830
18831
18832
18833
18834
18835
18836
18837
18838
18839
18840
18841
18842
18843
18844
18845
18846
18847
18848
18849
18850
18851
18852
18853
18854
18855
18856
18857
18858
18859
18860
18861
18862
18863
18864
18865
18866
18867
18868
18869
18870
18871
18872
18873
18874
18875
18876
18877
18878
18879
18880
18881
18882
18883
18884
18885
18886
18887
18888
18889
18890
18891
18892
18893
18894
18895
18896
18897
18898
18899
18900
18901
18902
18903
18904
18905
18906
18907
18908
18909
18910
18911
18912
18913
18914
18915
18916
18917
18918
18919
18920
18921
18922
18923
18924
18925
18926
18927
18928
18929
18930
18931
18932
18933
18934
18935
18936
18937
18938
18939
18940
18941
18942
18943
18944
18945
18946
18947
18948
18949
18950
18951
18952
18953
18954
18955
18956
18957
18958
18959
18960
18961
18962
18963
18964
18965
18966
18967
18968
18969
18970
18971
18972
18973
18974
18975
18976
18977
18978
18979
18980
18981
18982
18983
18984
18985
18986
18987
18988
18989
18990
18991
18992
18993
18994
18995
18996
18997
18998
18999
19000
19001
19002
19003
19004
19005
19006
19007
19008
19009
19010
19011
19012
19013
19014
19015
19016
19017
19018
19019
19020
19021
19022
19023
19024
19025
19026
19027
19028
19029
19030
19031
19032
19033
19034
19035
19036
19037
19038
19039
19040
19041
19042
19043
19044
19045
19046
19047
19048
19049
19050
19051
19052
19053
19054
19055
19056
19057
19058
19059
19060
19061
19062
19063
19064
19065
19066
19067
19068
19069
19070
19071
19072
19073
19074
19075
19076
19077
19078
19079
19080
19081
19082
19083
19084
19085
19086
19087
19088
19089
19090
19091
19092
19093
19094
19095
19096
19097
19098
19099
19100
19101
19102
19103
19104
19105
19106
19107
19108
19109
19110
19111
19112
19113
19114
19115
19116
19117
19118
19119
19120
19121
19122
19123
19124
19125
19126
19127
19128
19129
19130
19131
19132
19133
19134
19135
19136
19137
19138
19139
19140
19141
19142
19143
19144
19145
19146
19147
19148
19149
19150
19151
19152
19153
19154
19155
19156
19157
19158
19159
19160
19161
19162
19163
19164
19165
19166
19167
19168
19169
19170
19171
19172
19173
19174
19175
19176
19177
19178
19179
19180
19181
19182
19183
19184
19185
19186
19187
19188
19189
19190
19191
19192
19193
19194
19195
19196
19197
19198
19199
19200
19201
19202
19203
19204
19205
19206
19207
19208
19209
19210
19211
19212
19213
19214
19215
19216
19217
19218
19219
19220
19221
19222
19223
19224
19225
19226
19227
19228
19229
19230
19231
19232
19233
19234
19235
19236
19237
19238
19239
19240
19241
19242
19243
19244
19245
19246
19247
19248
19249
19250
19251
19252
19253
19254
19255
19256
19257
19258
19259
19260
19261
19262
19263
19264
19265
19266
19267
19268
19269
19270
19271
19272
19273
19274
19275
19276
19277
19278
19279
19280
19281
19282
19283
19284
19285
19286
19287
19288
19289
19290
19291
19292
19293
19294
19295
19296
19297
19298
19299
19300
19301
19302
19303
19304
19305
19306
19307
19308
19309
19310
19311
19312
19313
19314
19315
19316
19317
19318
19319
19320
19321
19322
19323
19324
19325
19326
19327
19328
19329
19330
19331
19332
19333
19334
19335
19336
19337
19338
19339
19340
19341
19342
19343
19344
19345
19346
19347
19348
19349
19350
19351
19352
19353
19354
19355
19356
19357
19358
19359
19360
19361
19362
19363
19364
19365
19366
19367
19368
19369
19370
19371
19372
19373
19374
19375
19376
19377
19378
19379
19380
19381
19382
19383
19384
19385
19386
19387
19388
19389
19390
19391
19392
19393
19394
19395
19396
19397
19398
19399
19400
19401
19402
19403
19404
19405
19406
19407
19408
19409
19410
19411
19412
19413
19414
19415
19416
19417
19418
19419
19420
19421
19422
19423
19424
19425
19426
19427
19428
19429
19430
19431
19432
19433
19434
19435
19436
19437
19438
19439
19440
19441
19442
19443
19444
19445
19446
19447
19448
19449
19450
19451
19452
19453
19454
19455
19456
19457
19458
19459
19460
19461
19462
19463
19464
19465
19466
19467
19468
19469
19470
19471
19472
19473
19474
19475
19476
19477
19478
19479
19480
19481
19482
19483
19484
19485
19486
19487
19488
19489
19490
19491
19492
19493
19494
19495
19496
19497
19498
19499
19500
19501
19502
19503
19504
19505
19506
19507
19508
19509
19510
19511
19512
19513
19514
19515
19516
19517
19518
19519
19520
19521
19522
19523
19524
19525
19526
19527
19528
19529
19530
19531
19532
19533
19534
19535
19536
19537
19538
19539
19540
19541
19542
19543
19544
19545
19546
19547
19548
19549
19550
19551
19552
19553
19554
19555
19556
19557
19558
19559
19560
19561
19562
19563
19564
19565
19566
19567
19568
19569
19570
19571
19572
19573
19574
19575
19576
19577
19578
19579
19580
19581
19582
19583
19584
19585
19586
19587
19588
19589
19590
19591
19592
19593
19594
19595
19596
19597
19598
19599
19600
19601
19602
19603
19604
19605
19606
19607
19608
19609
19610
19611
19612
19613
19614
19615
19616
19617
19618
19619
19620
19621
19622
19623
19624
19625
19626
19627
19628
19629
19630
19631
19632
19633
19634
19635
19636
19637
19638
19639
19640
19641
19642
19643
19644
19645
19646
19647
19648
19649
19650
19651
19652
19653
19654
19655
19656
19657
19658
19659
19660
19661
19662
19663
19664
19665
19666
19667
19668
19669
19670
19671
19672
19673
19674
19675
19676
19677
19678
19679
19680
19681
19682
19683
19684
19685
19686
19687
19688
19689
19690
19691
19692
19693
19694
19695
19696
19697
19698
19699
19700
19701
19702
19703
19704
19705
19706
19707
19708
19709
19710
19711
19712
19713
19714
19715
19716
19717
19718
19719
19720
19721
19722
19723
19724
19725
19726
19727
19728
19729
19730
19731
19732
19733
19734
19735
19736
19737
19738
19739
19740
19741
19742
19743
19744
19745
19746
19747
19748
19749
19750
19751
19752
19753
19754
19755
19756
19757
19758
19759
19760
19761
19762
19763
19764
19765
19766
19767
19768
19769
19770
19771
19772
19773
19774
19775
19776
19777
19778
19779
19780
19781
19782
19783
19784
19785
19786
19787
19788
19789
19790
19791
19792
19793
19794
19795
19796
19797
19798
19799
19800
19801
19802
19803
19804
19805
19806
19807
19808
19809
19810
19811
19812
19813
19814
19815
19816
19817
19818
19819
19820
19821
19822
19823
19824
19825
19826
19827
19828
19829
19830
19831
19832
19833
19834
19835
19836
19837
19838
19839
19840
19841
19842
19843
19844
19845
19846
19847
19848
19849
19850
19851
19852
19853
19854
19855
19856
19857
19858
19859
19860
19861
19862
19863
19864
19865
19866
19867
19868
19869
19870
19871
19872
19873
19874
19875
19876
19877
19878
19879
19880
19881
19882
19883
19884
19885
19886
19887
19888
19889
19890
19891
19892
19893
19894
19895
19896
19897
19898
19899
19900
19901
19902
19903
19904
19905
19906
19907
19908
19909
19910
19911
19912
19913
19914
19915
19916
19917
19918
19919
19920
19921
19922
19923
19924
19925
19926
19927
19928
19929
19930
19931
19932
19933
19934
19935
19936
19937
19938
19939
19940
19941
19942
19943
19944
19945
19946
19947
19948
19949
19950
19951
19952
19953
19954
19955
19956
19957
19958
19959
19960
19961
19962
19963
19964
19965
19966
19967
19968
19969
19970
19971
19972
19973
19974
19975
19976
19977
19978
19979
19980
19981
19982
19983
19984
19985
19986
19987
19988
19989
19990
19991
19992
19993
19994
19995
19996
19997
19998
19999
20000
20001
20002
20003
20004
20005
20006
20007
20008
20009
20010
20011
20012
20013
20014
20015
20016
20017
20018
20019
20020
20021
20022
20023
20024
20025
20026
20027
20028
20029
20030
20031
20032
20033
20034
20035
20036
20037
20038
20039
20040
20041
20042
20043
20044
20045
20046
20047
20048
20049
20050
20051
20052
20053
20054
20055
20056
20057
20058
20059
20060
20061
20062
20063
20064
20065
20066
20067
20068
20069
20070
20071
20072
20073
20074
20075
20076
20077
20078
20079
20080
20081
20082
20083
20084
20085
20086
20087
20088
20089
20090
20091
20092
20093
20094
20095
20096
20097
20098
20099
20100
20101
20102
20103
20104
20105
20106
20107
20108
20109
20110
20111
20112
20113
20114
20115
20116
20117
20118
20119
20120
20121
20122
20123
20124
20125
20126
20127
20128
20129
20130
20131
20132
20133
20134
20135
20136
20137
20138
20139
20140
20141
20142
20143
20144
20145
20146
20147
20148
20149
20150
20151
20152
20153
20154
20155
20156
20157
20158
20159
20160
20161
20162
20163
20164
20165
20166
20167
20168
20169
20170
20171
20172
20173
20174
20175
20176
20177
20178
20179
20180
20181
20182
20183
20184
20185
20186
20187
20188
20189
20190
20191
20192
20193
20194
20195
20196
20197
20198
20199
20200
20201
20202
20203
20204
20205
20206
20207
20208
20209
20210
20211
20212
20213
20214
20215
20216
20217
20218
20219
20220
20221
20222
20223
20224
20225
20226
20227
20228
20229
20230
20231
20232
20233
20234
20235
20236
20237
20238
20239
20240
20241
20242
20243
20244
20245
20246
20247
20248
20249
20250
20251
20252
20253
20254
20255
20256
20257
20258
20259
20260
20261
20262
20263
20264
20265
20266
20267
20268
20269
20270
20271
20272
20273
20274
20275
20276
20277
20278
20279
20280
20281
20282
20283
20284
20285
20286
20287
20288
20289
20290
20291
20292
20293
20294
20295
20296
20297
20298
20299
20300
20301
20302
20303
20304
20305
20306
20307
20308
20309
20310
20311
20312
20313
20314
20315
20316
20317
20318
20319
20320
20321
20322
20323
20324
20325
20326
20327
20328
20329
20330
20331
20332
20333
20334
20335
20336
20337
20338
20339
20340
20341
20342
20343
20344
20345
20346
20347
20348
20349
20350
20351
20352
20353
20354
20355
20356
20357
20358
20359
20360
20361
20362
20363
20364
20365
20366
20367
20368
20369
20370
20371
20372
20373
20374
20375
20376
20377
20378
20379
20380
20381
20382
20383
20384
20385
20386
20387
20388
20389
20390
20391
20392
20393
20394
20395
20396
20397
20398
20399
20400
20401
20402
20403
20404
20405
20406
20407
20408
20409
20410
20411
20412
20413
20414
20415
20416
20417
20418
20419
20420
20421
20422
20423
20424
20425
20426
20427
20428
20429
20430
20431
20432
20433
20434
20435
20436
20437
20438
20439
20440
20441
20442
20443
20444
20445
20446
20447
20448
20449
20450
20451
20452
20453
20454
20455
20456
20457
20458
20459
20460
20461
20462
20463
20464
20465
20466
20467
20468
20469
20470
20471
20472
20473
20474
20475
20476
20477
20478
20479
20480
20481
20482
20483
20484
20485
20486
20487
20488
20489
20490
20491
20492
20493
20494
20495
20496
20497
20498
20499
20500
20501
20502
20503
20504
20505
20506
20507
20508
20509
20510
20511
20512
20513
20514
20515
20516
20517
20518
20519
20520
20521
20522
20523
20524
20525
20526
20527
20528
20529
20530
20531
20532
20533
20534
20535
20536
20537
20538
20539
20540
20541
20542
20543
20544
20545
20546
20547
20548
20549
20550
20551
20552
20553
20554
20555
20556
20557
20558
20559
20560
20561
20562
20563
20564
20565
20566
20567
20568
20569
20570
20571
20572
20573
20574
20575
20576
20577
20578
20579
20580
20581
20582
20583
20584
20585
20586
20587
20588
20589
20590
20591
20592
20593
20594
20595
20596
20597
20598
20599
20600
20601
20602
20603
20604
20605
20606
20607
20608
20609
20610
20611
20612
20613
20614
20615
20616
20617
20618
20619
20620
20621
20622
20623
20624
20625
20626
20627
20628
20629
20630
20631
20632
20633
20634
20635
20636
20637
20638
20639
20640
20641
20642
20643
20644
20645
20646
20647
20648
20649
20650
20651
20652
20653
20654
20655
20656
20657
20658
20659
20660
20661
20662
20663
20664
20665
20666
20667
20668
20669
20670
20671
20672
20673
20674
20675
20676
20677
20678
20679
20680
20681
20682
20683
20684
20685
20686
20687
20688
20689
20690
20691
20692
20693
20694
20695
20696
20697
20698
20699
20700
20701
20702
20703
20704
20705
20706
20707
20708
20709
20710
20711
20712
20713
20714
20715
20716
20717
20718
20719
20720
20721
20722
20723
20724
20725
20726
20727
20728
20729
20730
20731
20732
20733
20734
20735
20736
20737
20738
20739
20740
20741
20742
20743
20744
20745
20746
20747
20748
20749
20750
20751
20752
20753
20754
20755
20756
20757
20758
20759
20760
20761
20762
20763
20764
20765
20766
20767
20768
20769
20770
20771
20772
20773
20774
20775
20776
20777
20778
20779
20780
20781
20782
20783
20784
20785
20786
20787
20788
20789
20790
20791
20792
20793
20794
20795
20796
20797
20798
20799
20800
20801
20802
20803
20804
20805
20806
20807
20808
20809
20810
20811
20812
20813
20814
20815
20816
20817
20818
20819
20820
20821
20822
20823
20824
20825
20826
20827
20828
20829
20830
20831
20832
20833
20834
20835
20836
20837
20838
20839
20840
20841
20842
20843
20844
20845
20846
20847
20848
20849
20850
20851
20852
20853
20854
20855
20856
20857
20858
20859
20860
20861
20862
20863
20864
20865
20866
20867
20868
20869
20870
20871
20872
20873
20874
20875
20876
20877
20878
20879
20880
20881
20882
20883
20884
20885
20886
20887
20888
20889
20890
20891
20892
20893
20894
20895
20896
20897
20898
20899
20900
20901
20902
20903
20904
20905
20906
20907
20908
20909
20910
20911
20912
20913
20914
20915
20916
20917
20918
20919
20920
20921
20922
20923
20924
20925
20926
20927
20928
20929
20930
20931
20932
20933
20934
20935
20936
20937
20938
20939
20940
20941
20942
20943
20944
20945
20946
20947
20948
20949
20950
20951
20952
20953
20954
20955
20956
20957
20958
20959
20960
20961
20962
20963
20964
20965
20966
20967
20968
20969
20970
20971
20972
20973
20974
20975
20976
20977
20978
20979
20980
20981
20982
20983
20984
20985
20986
20987
20988
20989
20990
20991
20992
20993
20994
20995
20996
20997
20998
20999
21000
21001
21002
21003
21004
21005
21006
21007
21008
21009
21010
21011
21012
21013
21014
21015
21016
21017
21018
21019
21020
21021
21022
21023
21024
21025
21026
21027
21028
21029
21030
21031
21032
21033
21034
21035
21036
21037
21038
21039
21040
21041
21042
21043
21044
21045
21046
21047
21048
21049
21050
21051
21052
21053
21054
21055
21056
21057
21058
21059
21060
21061
21062
21063
21064
21065
21066
21067
21068
21069
21070
21071
21072
21073
21074
21075
21076
21077
21078
21079
21080
21081
21082
21083
21084
21085
21086
21087
21088
21089
21090
21091
21092
21093
21094
21095
21096
21097
21098
21099
21100
21101
21102
21103
21104
21105
21106
21107
21108
21109
21110
21111
21112
21113
21114
21115
21116
21117
21118
21119
21120
21121
21122
21123
21124
21125
21126
21127
21128
21129
21130
21131
21132
21133
21134
21135
21136
21137
21138
21139
21140
21141
21142
21143
21144
21145
21146
21147
21148
21149
21150
21151
21152
21153
21154
21155
21156
21157
21158
21159
21160
21161
21162
21163
21164
21165
21166
21167
21168
21169
21170
21171
21172
21173
21174
21175
21176
21177
21178
21179
21180
21181
21182
21183
21184
21185
21186
21187
21188
21189
21190
21191
21192
21193
21194
21195
21196
21197
21198
21199
21200
21201
21202
21203
21204
21205
21206
21207
21208
21209
21210
21211
21212
21213
21214
21215
21216
21217
21218
21219
21220
21221
21222
21223
21224
21225
21226
21227
21228
21229
21230
21231
21232
21233
21234
21235
21236
21237
21238
21239
21240
21241
21242
21243
21244
21245
21246
21247
21248
21249
21250
21251
21252
21253
21254
21255
21256
21257
21258
21259
21260
21261
21262
21263
21264
21265
21266
21267
21268
21269
21270
21271
21272
21273
21274
21275
21276
21277
21278
21279
21280
21281
21282
21283
21284
21285
21286
21287
21288
21289
21290
21291
21292
21293
21294
21295
21296
21297
21298
21299
21300
21301
21302
21303
21304
21305
21306
21307
21308
21309
21310
21311
21312
21313
21314
21315
21316
21317
21318
21319
21320
21321
21322
21323
21324
21325
21326
21327
21328
21329
21330
21331
21332
21333
21334
21335
21336
21337
21338
21339
21340
21341
21342
21343
21344
21345
21346
21347
21348
21349
21350
21351
21352
21353
21354
21355
21356
21357
21358
21359
21360
21361
21362
21363
21364
21365
21366
21367
21368
21369
21370
21371
21372
21373
21374
21375
21376
21377
21378
21379
21380
21381
21382
21383
21384
21385
21386
21387
21388
21389
21390
21391
21392
21393
21394
21395
21396
21397
21398
21399
21400
21401
21402
21403
21404
21405
21406
21407
21408
21409
21410
21411
21412
21413
21414
21415
21416
21417
21418
21419
21420
21421
21422
21423
21424
21425
21426
21427
21428
21429
21430
21431
21432
21433
21434
21435
21436
21437
21438
21439
21440
21441
21442
21443
21444
21445
21446
21447
21448
21449
21450
21451
21452
21453
21454
21455
21456
21457
21458
21459
21460
21461
21462
21463
21464
21465
21466
21467
21468
21469
21470
21471
21472
21473
21474
21475
21476
21477
21478
21479
21480
21481
21482
21483
21484
21485
21486
21487
21488
21489
21490
21491
21492
21493
21494
21495
21496
21497
21498
21499
21500
21501
21502
21503
21504
21505
21506
21507
21508
21509
21510
21511
21512
21513
21514
21515
21516
21517
21518
21519
21520
21521
21522
21523
21524
21525
21526
21527
21528
21529
21530
21531
21532
21533
21534
21535
21536
21537
21538
21539
21540
21541
21542
21543
21544
21545
21546
21547
21548
21549
21550
21551
21552
21553
21554
21555
21556
21557
21558
21559
21560
21561
21562
21563
21564
21565
21566
21567
21568
21569
21570
21571
21572
21573
21574
21575
21576
21577
21578
21579
21580
21581
21582
21583
21584
21585
21586
21587
21588
21589
21590
21591
21592
21593
21594
21595
21596
21597
21598
21599
21600
21601
21602
21603
21604
21605
21606
21607
21608
21609
21610
21611
21612
21613
21614
21615
21616
21617
21618
21619
21620
21621
21622
21623
21624
21625
21626
21627
21628
21629
21630
21631
21632
21633
21634
21635
21636
21637
21638
21639
21640
21641
21642
21643
21644
21645
21646
21647
21648
21649
21650
21651
21652
21653
21654
21655
21656
21657
21658
21659
21660
21661
21662
21663
21664
21665
21666
21667
21668
21669
21670
21671
21672
21673
21674
21675
21676
21677
21678
21679
21680
21681
21682
21683
21684
21685
21686
21687
21688
21689
21690
21691
21692
21693
21694
21695
21696
21697
21698
21699
21700
21701
21702
21703
21704
21705
21706
21707
21708
21709
21710
21711
21712
21713
21714
21715
21716
21717
21718
21719
21720
21721
21722
21723
21724
21725
21726
21727
21728
21729
21730
21731
21732
21733
21734
21735
21736
21737
21738
21739
21740
21741
21742
21743
21744
21745
21746
21747
21748
21749
21750
21751
21752
21753
21754
21755
21756
21757
21758
21759
21760
21761
21762
21763
21764
21765
21766
21767
21768
21769
21770
21771
21772
21773
21774
21775
21776
21777
21778
21779
21780
21781
21782
21783
21784
21785
21786
21787
21788
21789
21790
21791
21792
21793
21794
21795
21796
21797
21798
21799
21800
21801
21802
21803
21804
21805
21806
21807
21808
21809
21810
21811
21812
21813
21814
21815
21816
21817
21818
21819
21820
21821
21822
21823
21824
21825
21826
21827
21828
21829
21830
21831
21832
21833
21834
21835
21836
21837
21838
21839
21840
21841
21842
21843
21844
21845
21846
21847
21848
21849
21850
21851
21852
21853
21854
21855
21856
21857
21858
21859
21860
21861
21862
21863
21864
21865
21866
21867
21868
21869
21870
21871
21872
21873
21874
21875
21876
21877
21878
21879
21880
21881
21882
21883
21884
21885
21886
21887
21888
21889
21890
21891
21892
21893
21894
21895
21896
21897
21898
21899
21900
21901
21902
21903
21904
21905
21906
21907
21908
21909
21910
21911
21912
21913
21914
21915
21916
21917
21918
21919
21920
21921
21922
21923
21924
21925
21926
21927
21928
21929
21930
21931
21932
21933
21934
21935
21936
21937
21938
21939
21940
21941
21942
21943
21944
21945
21946
21947
21948
21949
21950
21951
21952
21953
21954
21955
21956
21957
21958
21959
21960
21961
21962
21963
21964
21965
21966
21967
21968
21969
21970
21971
21972
21973
21974
21975
21976
21977
21978
21979
21980
21981
21982
21983
21984
21985
21986
21987
21988
21989
21990
21991
21992
21993
21994
21995
21996
21997
21998
21999
22000
22001
22002
22003
22004
22005
22006
22007
22008
22009
22010
22011
22012
22013
22014
22015
22016
22017
22018
22019
22020
22021
22022
22023
22024
22025
22026
22027
22028
22029
22030
22031
22032
22033
22034
22035
22036
22037
22038
22039
22040
22041
22042
22043
22044
22045
22046
22047
22048
22049
22050
22051
22052
22053
22054
22055
22056
22057
22058
22059
22060
22061
22062
22063
22064
22065
22066
22067
22068
22069
22070
22071
22072
22073
22074
22075
22076
22077
22078
22079
22080
22081
22082
22083
22084
22085
22086
22087
22088
22089
22090
22091
22092
22093
22094
22095
22096
22097
22098
22099
22100
22101
22102
22103
22104
22105
22106
22107
22108
22109
22110
22111
22112
22113
22114
22115
22116
22117
22118
22119
22120
22121
22122
22123
22124
22125
22126
22127
22128
22129
22130
22131
22132
22133
22134
22135
22136
22137
22138
22139
22140
22141
22142
22143
22144
22145
22146
22147
22148
22149
22150
22151
22152
22153
22154
22155
22156
22157
22158
22159
22160
22161
22162
22163
22164
22165
22166
22167
22168
22169
22170
22171
22172
22173
22174
22175
22176
22177
22178
22179
22180
22181
22182
22183
22184
22185
22186
22187
22188
22189
22190
22191
22192
22193
22194
22195
22196
22197
22198
22199
22200
22201
22202
22203
22204
22205
22206
22207
22208
22209
22210
22211
22212
22213
22214
22215
22216
22217
22218
22219
22220
22221
22222
22223
22224
22225
22226
22227
22228
22229
22230
22231
22232
22233
22234
22235
22236
22237
22238
22239
22240
22241
22242
22243
22244
22245
22246
22247
22248
22249
22250
22251
22252
22253
22254
22255
22256
22257
22258
22259
22260
22261
22262
22263
22264
22265
22266
22267
22268
22269
22270
22271
22272
22273
22274
22275
22276
22277
22278
22279
22280
22281
22282
22283
22284
22285
22286
22287
22288
22289
22290
22291
22292
22293
22294
22295
22296
22297
22298
22299
22300
22301
22302
22303
22304
22305
22306
22307
22308
22309
22310
22311
22312
22313
22314
22315
22316
22317
22318
22319
22320
22321
22322
22323
22324
22325
22326
22327
22328
22329
22330
22331
22332
22333
22334
22335
22336
22337
22338
22339
22340
22341
22342
22343
22344
22345
22346
22347
22348
22349
22350
22351
22352
22353
22354
22355
22356
22357
22358
22359
22360
22361
22362
22363
22364
22365
22366
22367
22368
22369
22370
22371
22372
22373
22374
22375
22376
22377
22378
22379
22380
22381
22382
22383
22384
22385
22386
22387
22388
22389
22390
22391
22392
22393
22394
22395
22396
22397
22398
22399
22400
22401
22402
22403
22404
22405
22406
22407
22408
22409
22410
22411
22412
22413
22414
22415
22416
22417
22418
22419
22420
22421
22422
22423
22424
22425
22426
22427
22428
22429
22430
22431
22432
22433
22434
22435
22436
22437
22438
22439
22440
22441
22442
22443
22444
22445
22446
22447
22448
22449
22450
22451
22452
22453
22454
22455
22456
22457
22458
22459
22460
22461
22462
22463
22464
22465
22466
22467
22468
22469
22470
22471
22472
22473
22474
22475
22476
22477
22478
22479
22480
22481
22482
22483
22484
22485
22486
22487
22488
22489
22490
22491
22492
22493
22494
22495
22496
22497
22498
22499
22500
22501
22502
22503
22504
22505
22506
22507
22508
22509
22510
22511
22512
22513
22514
22515
22516
22517
22518
22519
22520
22521
22522
22523
22524
22525
22526
22527
22528
22529
22530
22531
22532
22533
22534
22535
22536
22537
22538
22539
22540
22541
22542
22543
22544
22545
22546
22547
22548
22549
22550
22551
22552
22553
22554
22555
22556
22557
22558
22559
22560
22561
22562
22563
22564
22565
22566
22567
22568
22569
22570
22571
22572
22573
22574
22575
22576
22577
22578
22579
22580
22581
22582
22583
22584
22585
22586
22587
22588
22589
22590
22591
22592
22593
22594
22595
22596
22597
22598
22599
22600
22601
22602
22603
22604
22605
22606
22607
22608
22609
22610
22611
22612
22613
22614
22615
22616
22617
22618
22619
22620
22621
22622
22623
22624
22625
22626
22627
22628
22629
22630
22631
22632
22633
22634
22635
22636
22637
22638
22639
22640
22641
22642
22643
22644
22645
22646
22647
22648
22649
22650
22651
22652
22653
22654
22655
22656
22657
22658
22659
22660
22661
22662
22663
22664
22665
22666
22667
22668
22669
22670
22671
22672
22673
22674
22675
22676
22677
22678
22679
22680
22681
22682
22683
22684
22685
22686
22687
22688
22689
22690
22691
22692
22693
22694
22695
22696
22697
22698
22699
22700
22701
22702
22703
22704
22705
22706
22707
22708
22709
22710
22711
22712
22713
22714
22715
22716
22717
22718
22719
22720
22721
22722
22723
22724
22725
22726
22727
22728
22729
22730
22731
22732
22733
22734
22735
22736
22737
22738
22739
22740
22741
22742
22743
22744
22745
22746
22747
22748
22749
22750
22751
22752
22753
22754
22755
22756
22757
22758
22759
22760
22761
22762
22763
22764
22765
22766
22767
22768
22769
22770
22771
22772
22773
22774
22775
22776
22777
22778
22779
22780
22781
22782
22783
22784
22785
22786
22787
22788
22789
22790
22791
22792
22793
22794
22795
22796
22797
22798
22799
22800
22801
22802
22803
22804
22805
22806
22807
22808
22809
22810
22811
22812
22813
22814
22815
22816
22817
22818
22819
22820
22821
22822
22823
22824
22825
22826
22827
22828
22829
22830
22831
22832
22833
22834
22835
22836
22837
22838
22839
22840
22841
22842
22843
22844
22845
22846
22847
22848
22849
22850
22851
22852
22853
22854
22855
22856
22857
22858
22859
22860
22861
22862
22863
22864
22865
22866
22867
22868
22869
22870
22871
22872
22873
22874
22875
22876
22877
22878
22879
22880
22881
22882
22883
22884
22885
22886
22887
22888
22889
22890
22891
22892
22893
22894
22895
22896
22897
22898
22899
22900
22901
22902
22903
22904
22905
22906
22907
22908
22909
22910
22911
22912
22913
22914
22915
22916
22917
22918
22919
22920
22921
22922
22923
22924
22925
22926
22927
22928
22929
22930
22931
22932
22933
22934
22935
22936
22937
22938
22939
22940
22941
22942
22943
22944
22945
22946
22947
22948
22949
22950
22951
22952
22953
22954
22955
22956
22957
22958
22959
22960
22961
22962
22963
22964
22965
22966
22967
22968
22969
22970
22971
22972
22973
22974
22975
22976
22977
22978
22979
22980
22981
22982
22983
22984
22985
22986
22987
22988
22989
22990
22991
22992
22993
22994
22995
22996
22997
22998
22999
23000
23001
23002
23003
23004
23005
23006
23007
23008
23009
23010
23011
23012
23013
23014
23015
23016
23017
23018
23019
23020
23021
23022
23023
23024
23025
23026
23027
23028
23029
23030
23031
23032
23033
23034
23035
23036
23037
23038
23039
23040
23041
23042
23043
23044
23045
23046
23047
23048
23049
23050
23051
23052
23053
23054
23055
23056
23057
23058
23059
23060
23061
23062
23063
23064
23065
23066
23067
23068
23069
23070
23071
23072
23073
23074
23075
23076
23077
23078
23079
23080
23081
23082
23083
23084
23085
23086
23087
23088
23089
23090
23091
23092
23093
23094
23095
23096
23097
23098
23099
23100
23101
23102
23103
23104
23105
23106
23107
23108
23109
23110
23111
23112
23113
23114
23115
23116
23117
23118
23119
23120
23121
23122
23123
23124
23125
23126
23127
23128
23129
23130
23131
23132
23133
23134
23135
23136
23137
23138
23139
23140
23141
23142
23143
23144
23145
23146
23147
23148
23149
23150
23151
23152
23153
23154
23155
23156
23157
23158
23159
23160
23161
23162
23163
23164
23165
23166
23167
23168
23169
23170
23171
23172
23173
23174
23175
23176
23177
23178
23179
23180
23181
23182
23183
23184
23185
23186
23187
23188
23189
23190
23191
23192
23193
23194
23195
23196
23197
23198
23199
23200
23201
23202
23203
23204
23205
23206
23207
23208
23209
23210
23211
23212
23213
23214
23215
23216
23217
23218
23219
23220
23221
23222
23223
23224
23225
23226
23227
23228
23229
23230
23231
23232
23233
23234
23235
23236
23237
23238
23239
23240
23241
23242
23243
23244
23245
23246
23247
23248
23249
23250
23251
23252
23253
23254
23255
23256
23257
23258
23259
23260
23261
23262
23263
23264
23265
23266
23267
23268
23269
23270
23271
23272
23273
23274
23275
23276
23277
23278
23279
23280
23281
23282
23283
23284
23285
23286
23287
23288
23289
23290
23291
23292
23293
23294
23295
23296
23297
23298
23299
23300
23301
23302
23303
23304
23305
23306
23307
23308
23309
23310
23311
23312
23313
23314
23315
23316
23317
23318
23319
23320
23321
23322
23323
23324
23325
23326
23327
23328
23329
23330
23331
23332
23333
23334
23335
23336
23337
23338
23339
23340
23341
23342
23343
23344
23345
23346
23347
23348
23349
23350
23351
23352
23353
23354
23355
23356
23357
23358
23359
23360
23361
23362
23363
23364
23365
23366
23367
23368
23369
23370
23371
23372
23373
23374
23375
23376
23377
23378
23379
23380
23381
23382
23383
23384
23385
23386
23387
23388
23389
23390
23391
23392
23393
23394
23395
23396
23397
23398
23399
23400
23401
23402
23403
23404
23405
23406
23407
23408
23409
23410
23411
23412
23413
23414
23415
23416
23417
23418
23419
23420
23421
23422
23423
23424
23425
23426
23427
23428
23429
23430
23431
23432
23433
23434
23435
23436
23437
23438
23439
23440
23441
23442
23443
23444
23445
23446
23447
23448
23449
23450
23451
23452
23453
23454
23455
23456
23457
23458
23459
23460
23461
23462
23463
23464
23465
23466
23467
23468
23469
23470
23471
23472
23473
23474
23475
23476
23477
23478
23479
23480
23481
23482
23483
23484
23485
23486
23487
23488
23489
23490
23491
23492
23493
23494
23495
23496
23497
23498
23499
23500
23501
23502
23503
23504
23505
23506
23507
23508
23509
23510
23511
23512
23513
23514
23515
23516
23517
23518
23519
23520
23521
23522
23523
23524
23525
23526
23527
23528
23529
23530
23531
23532
23533
23534
23535
23536
23537
23538
23539
23540
23541
23542
23543
23544
23545
23546
23547
23548
23549
23550
23551
23552
23553
23554
23555
23556
23557
23558
23559
23560
23561
23562
23563
23564
23565
23566
23567
23568
23569
23570
23571
23572
23573
23574
23575
23576
23577
23578
23579
23580
23581
23582
23583
23584
23585
23586
23587
23588
23589
23590
23591
23592
23593
23594
23595
23596
23597
23598
23599
23600
23601
23602
23603
23604
23605
23606
23607
23608
23609
23610
23611
23612
23613
23614
23615
23616
23617
23618
23619
23620
23621
23622
23623
23624
23625
23626
23627
23628
23629
23630
23631
23632
23633
23634
23635
23636
23637
23638
23639
23640
23641
23642
23643
23644
23645
23646
23647
23648
23649
23650
23651
23652
23653
23654
23655
23656
23657
23658
23659
23660
23661
23662
23663
23664
23665
23666
23667
23668
23669
23670
23671
23672
23673
23674
23675
23676
23677
23678
23679
23680
23681
23682
23683
23684
23685
23686
23687
23688
23689
23690
23691
23692
23693
23694
23695
23696
23697
23698
23699
23700
23701
23702
23703
23704
23705
23706
23707
23708
23709
23710
23711
23712
23713
23714
23715
23716
23717
23718
23719
23720
23721
23722
23723
23724
23725
23726
23727
23728
23729
23730
23731
23732
23733
23734
23735
23736
23737
23738
23739
23740
23741
23742
23743
23744
23745
23746
23747
23748
23749
23750
23751
23752
23753
23754
23755
23756
23757
23758
23759
23760
23761
23762
23763
23764
23765
23766
23767
23768
23769
23770
23771
23772
23773
23774
23775
23776
23777
23778
23779
23780
23781
23782
23783
23784
23785
23786
23787
23788
23789
23790
23791
23792
23793
23794
23795
23796
23797
23798
23799
23800
23801
23802
23803
23804
23805
23806
23807
23808
23809
23810
23811
23812
23813
23814
23815
23816
23817
23818
23819
23820
23821
23822
23823
23824
23825
23826
23827
23828
23829
23830
23831
23832
23833
23834
23835
23836
23837
23838
23839
23840
23841
23842
23843
23844
23845
23846
23847
23848
23849
23850
23851
23852
23853
23854
23855
23856
23857
23858
23859
23860
23861
23862
23863
23864
23865
23866
23867
23868
23869
23870
23871
23872
23873
23874
23875
23876
23877
23878
23879
23880
23881
23882
23883
23884
23885
23886
23887
23888
23889
23890
23891
23892
23893
23894
23895
23896
23897
23898
23899
23900
23901
23902
23903
23904
23905
23906
23907
23908
23909
23910
23911
23912
23913
23914
23915
23916
23917
23918
23919
23920
23921
23922
23923
23924
23925
23926
23927
23928
23929
23930
23931
23932
23933
23934
23935
23936
23937
23938
23939
23940
23941
23942
23943
23944
23945
23946
23947
23948
23949
23950
23951
23952
23953
23954
23955
23956
23957
23958
23959
23960
23961
23962
23963
23964
23965
23966
23967
23968
23969
23970
23971
23972
23973
23974
23975
23976
23977
23978
23979
23980
23981
23982
23983
23984
23985
23986
23987
23988
23989
23990
23991
23992
23993
23994
23995
23996
23997
23998
23999
24000
24001
24002
24003
24004
24005
24006
24007
24008
24009
24010
24011
24012
24013
24014
24015
24016
24017
24018
24019
24020
24021
24022
24023
24024
24025
24026
24027
24028
24029
24030
24031
24032
24033
24034
24035
24036
24037
24038
24039
24040
24041
24042
24043
24044
24045
24046
24047
24048
24049
24050
24051
24052
24053
24054
24055
24056
24057
24058
24059
24060
24061
24062
24063
24064
24065
24066
24067
24068
24069
24070
24071
24072
24073
24074
24075
24076
24077
24078
24079
24080
24081
24082
24083
24084
24085
24086
24087
24088
24089
24090
24091
24092
24093
24094
24095
24096
24097
24098
24099
24100
24101
24102
24103
24104
24105
24106
24107
24108
24109
24110
24111
24112
24113
24114
24115
24116
24117
24118
24119
24120
24121
24122
24123
24124
24125
24126
24127
24128
24129
24130
24131
24132
24133
24134
24135
24136
24137
24138
24139
24140
24141
24142
24143
24144
24145
24146
24147
24148
24149
24150
24151
24152
24153
24154
24155
24156
24157
24158
24159
24160
24161
24162
24163
24164
24165
24166
24167
24168
24169
24170
24171
24172
24173
24174
24175
24176
24177
24178
24179
24180
24181
24182
24183
24184
24185
24186
24187
24188
24189
24190
24191
24192
24193
24194
24195
24196
24197
24198
24199
24200
24201
24202
24203
24204
24205
24206
24207
24208
24209
24210
24211
24212
24213
24214
24215
24216
24217
24218
24219
24220
24221
24222
24223
24224
24225
24226
24227
24228
24229
24230
24231
24232
24233
24234
24235
24236
24237
24238
24239
24240
24241
24242
24243
24244
24245
24246
24247
24248
24249
24250
24251
24252
24253
24254
24255
24256
24257
24258
24259
24260
24261
24262
24263
24264
24265
24266
24267
24268
24269
24270
24271
24272
24273
24274
24275
24276
24277
24278
24279
24280
24281
24282
24283
24284
24285
24286
24287
24288
24289
24290
24291
24292
24293
24294
24295
24296
24297
24298
24299
24300
24301
24302
24303
24304
24305
24306
24307
24308
24309
24310
24311
24312
24313
24314
24315
24316
24317
24318
24319
24320
24321
24322
24323
24324
24325
24326
24327
24328
24329
24330
24331
24332
24333
24334
24335
24336
24337
24338
24339
24340
24341
24342
24343
24344
24345
24346
24347
24348
24349
24350
24351
24352
24353
24354
24355
24356
24357
24358
24359
24360
24361
24362
24363
24364
24365
24366
24367
24368
24369
24370
24371
24372
24373
24374
24375
24376
24377
24378
24379
24380
24381
24382
24383
24384
24385
24386
24387
24388
24389
24390
24391
24392
24393
24394
24395
24396
24397
24398
24399
24400
24401
24402
24403
24404
24405
24406
24407
24408
24409
24410
24411
24412
24413
24414
24415
24416
24417
24418
24419
24420
24421
24422
24423
24424
24425
24426
24427
24428
24429
24430
24431
24432
24433
24434
24435
24436
24437
24438
24439
24440
24441
24442
24443
24444
24445
24446
24447
24448
24449
24450
24451
24452
24453
24454
24455
24456
24457
24458
24459
24460
24461
24462
24463
24464
24465
24466
24467
24468
24469
24470
24471
24472
24473
24474
24475
24476
24477
24478
24479
24480
24481
24482
24483
24484
24485
24486
24487
24488
24489
24490
24491
24492
24493
24494
24495
24496
24497
24498
24499
24500
24501
24502
24503
24504
24505
24506
24507
24508
24509
24510
24511
24512
24513
24514
24515
24516
24517
24518
24519
24520
24521
24522
24523
24524
24525
24526
24527
24528
24529
24530
24531
24532
24533
24534
24535
24536
24537
24538
24539
24540
24541
24542
24543
24544
24545
24546
24547
24548
24549
24550
24551
24552
24553
24554
24555
24556
24557
24558
24559
24560
24561
24562
24563
24564
24565
24566
24567
24568
24569
24570
24571
24572
24573
24574
24575
24576
24577
24578
24579
24580
24581
24582
24583
24584
24585
24586
24587
24588
24589
24590
24591
24592
24593
24594
24595
24596
24597
24598
24599
24600
24601
24602
24603
24604
24605
24606
24607
24608
24609
24610
24611
24612
24613
24614
24615
24616
24617
24618
24619
24620
24621
24622
24623
24624
24625
24626
24627
24628
24629
24630
24631
24632
24633
24634
24635
24636
24637
24638
24639
24640
24641
24642
24643
24644
24645
24646
24647
24648
24649
24650
24651
24652
24653
24654
24655
24656
24657
24658
24659
24660
24661
24662
24663
24664
24665
24666
24667
24668
24669
24670
24671
24672
24673
24674
24675
24676
24677
24678
24679
24680
24681
24682
24683
24684
24685
24686
24687
24688
24689
24690
24691
24692
24693
24694
24695
24696
24697
24698
24699
24700
24701
24702
24703
24704
24705
24706
24707
24708
24709
24710
24711
24712
24713
24714
24715
24716
24717
24718
24719
24720
24721
24722
24723
24724
24725
24726
24727
24728
24729
24730
24731
24732
24733
24734
24735
24736
24737
24738
24739
24740
24741
24742
24743
24744
24745
24746
24747
24748
24749
24750
24751
24752
24753
24754
24755
24756
24757
24758
24759
24760
24761
24762
24763
24764
24765
24766
24767
24768
24769
24770
24771
24772
24773
24774
24775
24776
24777
24778
24779
24780
24781
24782
24783
24784
24785
24786
24787
24788
24789
24790
24791
24792
24793
24794
24795
24796
24797
24798
24799
24800
24801
24802
24803
24804
24805
24806
24807
24808
24809
24810
24811
24812
24813
24814
24815
24816
24817
24818
24819
24820
24821
24822
24823
24824
24825
24826
24827
24828
24829
24830
24831
24832
24833
24834
24835
24836
24837
24838
24839
24840
24841
24842
24843
24844
24845
24846
24847
24848
24849
24850
24851
24852
24853
24854
24855
24856
24857
24858
24859
24860
24861
24862
24863
24864
24865
24866
24867
24868
24869
24870
24871
24872
24873
24874
24875
24876
24877
24878
24879
24880
24881
24882
24883
24884
24885
24886
24887
24888
24889
24890
24891
24892
24893
24894
24895
24896
24897
24898
24899
24900
24901
24902
24903
24904
24905
24906
24907
24908
24909
24910
24911
24912
24913
24914
24915
24916
24917
24918
24919
24920
24921
24922
24923
24924
24925
24926
24927
24928
24929
24930
24931
24932
24933
24934
24935
24936
24937
24938
24939
24940
24941
24942
24943
24944
24945
24946
24947
24948
24949
24950
24951
24952
24953
24954
24955
24956
24957
24958
24959
24960
24961
24962
24963
24964
24965
24966
24967
24968
24969
24970
24971
24972
24973
24974
24975
24976
24977
24978
24979
24980
24981
24982
24983
24984
24985
24986
24987
24988
24989
24990
24991
24992
24993
24994
24995
24996
24997
24998
24999
25000
25001
25002
25003
25004
25005
25006
25007
25008
25009
25010
25011
25012
25013
25014
25015
25016
25017
25018
25019
25020
25021
25022
25023
25024
25025
25026
25027
25028
25029
25030
25031
25032
25033
25034
25035
25036
25037
25038
25039
25040
25041
25042
25043
25044
25045
25046
25047
25048
25049
25050
25051
25052
25053
25054
25055
25056
25057
25058
25059
25060
25061
25062
25063
25064
25065
25066
25067
25068
25069
25070
25071
25072
25073
25074
25075
25076
25077
25078
25079
25080
25081
25082
25083
25084
25085
25086
25087
25088
25089
25090
25091
25092
25093
25094
25095
25096
25097
25098
25099
25100
25101
25102
25103
25104
25105
25106
25107
25108
25109
25110
25111
25112
25113
25114
25115
25116
25117
25118
25119
25120
25121
25122
25123
25124
25125
25126
25127
25128
25129
25130
25131
25132
25133
25134
25135
25136
25137
25138
25139
25140
25141
25142
25143
25144
25145
25146
25147
25148
25149
25150
25151
25152
25153
25154
25155
25156
25157
25158
25159
25160
25161
25162
25163
25164
25165
25166
25167
25168
25169
25170
25171
25172
25173
25174
25175
25176
25177
25178
25179
25180
25181
25182
25183
25184
25185
25186
25187
25188
25189
25190
25191
25192
25193
25194
25195
25196
25197
25198
25199
25200
25201
25202
25203
25204
25205
25206
25207
25208
25209
25210
25211
25212
25213
25214
25215
25216
25217
25218
25219
25220
25221
25222
25223
25224
25225
25226
25227
25228
25229
25230
25231
25232
25233
25234
25235
25236
25237
25238
25239
25240
25241
25242
25243
25244
25245
25246
25247
25248
25249
25250
25251
25252
25253
25254
25255
25256
25257
25258
25259
25260
25261
25262
25263
25264
25265
25266
25267
25268
25269
25270
25271
25272
25273
25274
25275
25276
25277
25278
25279
25280
25281
25282
25283
25284
25285
25286
25287
25288
25289
25290
25291
25292
25293
25294
25295
25296
25297
25298
25299
25300
25301
25302
25303
25304
25305
25306
25307
25308
25309
25310
25311
25312
25313
25314
25315
25316
25317
25318
25319
25320
25321
25322
25323
25324
25325
25326
25327
25328
25329
25330
25331
25332
25333
25334
25335
25336
25337
25338
25339
25340
25341
25342
25343
25344
25345
25346
25347
25348
25349
25350
25351
25352
25353
25354
25355
25356
25357
25358
25359
25360
25361
25362
25363
25364
25365
25366
25367
25368
25369
25370
25371
25372
25373
25374
25375
25376
25377
25378
25379
25380
25381
25382
25383
25384
25385
25386
25387
25388
25389
25390
25391
25392
25393
25394
25395
25396
25397
25398
25399
25400
25401
25402
25403
25404
25405
25406
25407
25408
25409
25410
25411
25412
25413
25414
25415
25416
25417
25418
25419
25420
25421
25422
25423
25424
25425
25426
25427
25428
25429
25430
25431
25432
25433
25434
25435
25436
25437
25438
25439
25440
25441
25442
25443
25444
25445
25446
25447
25448
25449
25450
25451
25452
25453
25454
25455
25456
25457
25458
25459
25460
25461
25462
25463
25464
25465
25466
25467
25468
25469
25470
25471
25472
25473
25474
25475
25476
25477
25478
25479
25480
25481
25482
25483
25484
25485
25486
25487
25488
25489
25490
25491
25492
25493
25494
25495
25496
25497
25498
25499
25500
25501
25502
25503
25504
25505
25506
25507
25508
25509
25510
25511
25512
25513
25514
25515
25516
25517
25518
25519
25520
25521
25522
25523
25524
25525
25526
25527
25528
25529
25530
25531
25532
25533
25534
25535
25536
25537
25538
25539
25540
25541
25542
25543
25544
25545
25546
25547
25548
25549
25550
25551
25552
25553
25554
25555
25556
25557
25558
25559
25560
25561
25562
25563
25564
25565
25566
25567
25568
25569
25570
25571
25572
25573
25574
25575
25576
25577
25578
25579
25580
25581
25582
25583
25584
25585
25586
25587
25588
25589
25590
25591
25592
25593
25594
25595
25596
25597
25598
25599
25600
25601
25602
25603
25604
25605
25606
25607
25608
25609
25610
25611
25612
25613
25614
25615
25616
25617
25618
25619
25620
25621
25622
25623
25624
25625
25626
25627
25628
25629
25630
25631
25632
25633
25634
25635
25636
25637
25638
25639
25640
25641
25642
25643
25644
25645
25646
25647
25648
25649
25650
25651
25652
25653
25654
25655
25656
25657
25658
25659
25660
25661
25662
25663
25664
25665
25666
25667
25668
25669
25670
25671
25672
25673
25674
25675
25676
25677
25678
25679
25680
25681
25682
25683
25684
25685
25686
25687
25688
25689
25690
25691
25692
25693
25694
25695
25696
25697
25698
25699
25700
25701
25702
25703
25704
25705
25706
25707
25708
25709
25710
25711
25712
25713
25714
25715
25716
25717
25718
25719
25720
25721
25722
25723
25724
25725
25726
25727
25728
25729
25730
25731
25732
25733
25734
25735
25736
25737
25738
25739
25740
25741
25742
25743
25744
25745
25746
25747
25748
25749
25750
25751
25752
25753
25754
25755
25756
25757
25758
25759
25760
25761
25762
25763
25764
25765
25766
25767
25768
25769
25770
25771
25772
25773
25774
25775
25776
25777
25778
25779
25780
25781
25782
25783
25784
25785
25786
25787
25788
25789
25790
25791
25792
25793
25794
25795
25796
25797
25798
25799
25800
25801
25802
25803
25804
25805
25806
25807
25808
25809
25810
25811
25812
25813
25814
25815
25816
25817
25818
25819
25820
25821
25822
25823
25824
25825
25826
25827
25828
25829
25830
25831
25832
25833
25834
25835
25836
25837
25838
25839
25840
25841
25842
25843
25844
25845
25846
25847
25848
25849
25850
25851
25852
25853
25854
25855
25856
25857
25858
25859
25860
25861
25862
25863
25864
25865
25866
25867
25868
25869
25870
25871
25872
25873
25874
25875
25876
25877
25878
25879
25880
25881
25882
25883
25884
25885
25886
25887
25888
25889
25890
25891
25892
25893
25894
25895
25896
25897
25898
25899
25900
25901
25902
25903
25904
25905
25906
25907
25908
25909
25910
25911
25912
25913
25914
25915
25916
25917
25918
25919
25920
25921
25922
25923
25924
25925
25926
25927
25928
25929
25930
25931
25932
25933
25934
25935
25936
25937
25938
25939
25940
25941
25942
25943
25944
25945
25946
25947
25948
25949
25950
25951
25952
25953
25954
25955
25956
25957
25958
25959
25960
25961
25962
25963
25964
25965
25966
25967
25968
25969
25970
25971
25972
25973
25974
25975
25976
25977
25978
25979
25980
25981
25982
25983
25984
25985
25986
25987
25988
25989
25990
25991
25992
25993
25994
25995
25996
25997
25998
25999
26000
26001
26002
26003
26004
26005
26006
26007
26008
26009
26010
26011
26012
26013
26014
26015
26016
26017
26018
26019
26020
26021
26022
26023
26024
26025
26026
26027
26028
26029
26030
26031
26032
26033
26034
26035
26036
26037
26038
26039
26040
26041
26042
26043
26044
26045
26046
26047
26048
26049
26050
26051
26052
26053
26054
26055
26056
26057
26058
26059
26060
26061
26062
26063
26064
26065
26066
26067
26068
26069
26070
26071
26072
26073
26074
26075
26076
26077
26078
26079
26080
26081
26082
26083
26084
26085
26086
26087
26088
26089
26090
26091
26092
26093
26094
26095
26096
26097
26098
26099
26100
26101
26102
26103
26104
26105
26106
26107
26108
26109
26110
26111
26112
26113
26114
26115
26116
26117
26118
26119
26120
26121
26122
26123
26124
26125
26126
26127
26128
26129
26130
26131
26132
26133
26134
26135
26136
26137
26138
26139
26140
26141
26142
26143
26144
26145
26146
26147
26148
26149
26150
26151
26152
26153
26154
26155
26156
26157
26158
26159
26160
26161
26162
26163
26164
26165
26166
26167
26168
26169
26170
26171
26172
26173
26174
26175
26176
26177
26178
26179
26180
26181
26182
26183
26184
26185
26186
26187
26188
26189
26190
26191
26192
26193
26194
26195
26196
26197
26198
26199
26200
26201
26202
26203
26204
26205
26206
26207
26208
26209
26210
26211
26212
26213
26214
26215
26216
26217
26218
26219
26220
26221
26222
26223
26224
26225
26226
26227
26228
26229
26230
26231
26232
26233
26234
26235
26236
26237
26238
26239
26240
26241
26242
26243
26244
26245
26246
26247
26248
26249
26250
26251
26252
26253
26254
26255
26256
26257
26258
26259
26260
26261
26262
26263
26264
26265
26266
26267
26268
26269
26270
26271
26272
26273
26274
26275
26276
26277
26278
26279
26280
26281
26282
26283
26284
26285
26286
26287
26288
26289
26290
26291
26292
26293
26294
26295
26296
26297
26298
26299
26300
26301
26302
26303
26304
26305
26306
26307
26308
26309
26310
26311
26312
26313
26314
26315
26316
26317
26318
26319
26320
26321
26322
26323
26324
26325
26326
26327
26328
26329
26330
26331
26332
26333
26334
26335
26336
26337
26338
26339
26340
26341
26342
26343
26344
26345
26346
26347
26348
26349
26350
26351
26352
26353
26354
26355
26356
26357
26358
26359
26360
26361
26362
26363
26364
26365
26366
26367
26368
26369
26370
26371
26372
26373
26374
26375
26376
26377
26378
26379
26380
26381
26382
26383
26384
26385
26386
26387
26388
26389
26390
26391
26392
26393
26394
26395
26396
26397
26398
26399
26400
26401
26402
26403
26404
26405
26406
26407
26408
26409
26410
26411
26412
26413
26414
26415
26416
26417
26418
26419
26420
26421
26422
26423
26424
26425
26426
26427
26428
26429
26430
26431
26432
26433
26434
26435
26436
26437
26438
26439
26440
26441
26442
26443
26444
26445
26446
26447
26448
26449
26450
26451
26452
26453
26454
26455
26456
26457
26458
26459
26460
26461
26462
26463
26464
26465
26466
26467
26468
26469
26470
26471
26472
26473
26474
26475
26476
26477
26478
26479
26480
26481
26482
26483
26484
26485
26486
26487
26488
26489
26490
26491
26492
26493
26494
26495
26496
26497
26498
26499
26500
26501
26502
26503
26504
26505
26506
26507
26508
26509
26510
26511
26512
26513
26514
26515
26516
26517
26518
26519
26520
26521
26522
26523
26524
26525
26526
26527
26528
26529
26530
26531
26532
26533
26534
26535
26536
26537
26538
26539
26540
26541
26542
26543
26544
26545
26546
26547
26548
26549
26550
26551
26552
26553
26554
26555
26556
26557
26558
26559
26560
26561
26562
26563
26564
26565
26566
26567
26568
26569
26570
26571
26572
26573
26574
26575
26576
26577
26578
26579
26580
26581
26582
26583
26584
26585
26586
26587
26588
26589
26590
26591
26592
26593
26594
26595
26596
26597
26598
26599
26600
26601
26602
26603
26604
26605
26606
26607
26608
26609
26610
26611
26612
26613
26614
26615
26616
26617
26618
26619
26620
26621
26622
26623
26624
26625
26626
26627
26628
26629
26630
26631
26632
26633
26634
26635
26636
26637
26638
26639
26640
26641
26642
26643
26644
26645
26646
26647
26648
26649
26650
26651
26652
26653
26654
26655
26656
26657
26658
26659
26660
26661
26662
26663
26664
26665
26666
26667
26668
26669
26670
26671
26672
26673
26674
26675
26676
26677
26678
26679
26680
26681
26682
26683
26684
26685
26686
26687
26688
26689
26690
26691
26692
26693
26694
26695
26696
26697
26698
26699
26700
26701
26702
26703
26704
26705
26706
26707
26708
26709
26710
26711
26712
26713
26714
26715
26716
26717
26718
26719
26720
26721
26722
26723
26724
26725
26726
26727
26728
26729
26730
26731
26732
26733
26734
26735
26736
26737
26738
26739
26740
26741
26742
26743
26744
26745
26746
26747
26748
26749
26750
26751
26752
26753
26754
26755
26756
26757
26758
26759
26760
26761
26762
26763
26764
26765
26766
26767
26768
26769
26770
26771
26772
26773
26774
26775
26776
26777
26778
26779
26780
26781
26782
26783
26784
26785
26786
26787
26788
26789
26790
26791
26792
26793
26794
26795
26796
26797
26798
26799
26800
26801
26802
26803
26804
26805
26806
26807
26808
26809
26810
26811
26812
26813
26814
26815
26816
26817
26818
26819
26820
26821
26822
26823
26824
26825
26826
26827
26828
26829
26830
26831
26832
26833
26834
26835
26836
26837
26838
26839
26840
26841
26842
26843
26844
26845
26846
26847
26848
26849
26850
26851
26852
26853
26854
26855
26856
26857
26858
26859
26860
26861
26862
26863
26864
26865
26866
26867
26868
26869
26870
26871
26872
26873
26874
26875
26876
26877
26878
26879
26880
26881
26882
26883
26884
26885
26886
26887
26888
26889
26890
26891
26892
26893
26894
26895
26896
26897
26898
26899
26900
26901
26902
26903
26904
26905
26906
26907
26908
26909
26910
26911
26912
26913
26914
26915
26916
26917
26918
26919
26920
26921
26922
26923
26924
26925
26926
26927
26928
26929
26930
26931
26932
26933
26934
26935
26936
26937
26938
26939
26940
26941
26942
26943
26944
26945
26946
26947
26948
26949
26950
26951
26952
26953
26954
26955
26956
26957
26958
26959
26960
26961
26962
26963
26964
26965
26966
26967
26968
26969
26970
26971
26972
26973
26974
26975
26976
26977
26978
26979
26980
26981
26982
26983
26984
26985
26986
26987
26988
26989
26990
26991
26992
26993
26994
26995
26996
26997
26998
26999
27000
27001
27002
27003
27004
27005
27006
27007
27008
27009
27010
27011
27012
27013
27014
27015
27016
27017
27018
27019
27020
27021
27022
27023
27024
27025
27026
27027
27028
27029
27030
27031
27032
27033
27034
27035
27036
27037
27038
27039
27040
27041
27042
27043
27044
27045
27046
27047
27048
27049
27050
27051
27052
27053
27054
27055
27056
27057
27058
27059
27060
27061
27062
27063
27064
27065
27066
27067
27068
27069
27070
27071
27072
27073
27074
27075
27076
27077
27078
27079
27080
27081
27082
27083
27084
27085
27086
27087
27088
27089
27090
27091
27092
27093
27094
27095
27096
27097
27098
27099
27100
27101
27102
27103
27104
27105
27106
27107
27108
27109
27110
27111
27112
27113
27114
27115
27116
27117
27118
27119
27120
27121
27122
27123
27124
27125
27126
27127
27128
27129
27130
27131
27132
27133
27134
27135
27136
27137
27138
27139
27140
27141
27142
27143
27144
27145
27146
27147
27148
27149
27150
27151
27152
27153
27154
27155
27156
27157
27158
27159
27160
27161
27162
27163
27164
27165
27166
27167
27168
27169
27170
27171
27172
27173
27174
27175
27176
27177
27178
27179
27180
27181
27182
27183
27184
27185
27186
27187
27188
27189
27190
27191
27192
27193
27194
27195
27196
27197
27198
27199
27200
27201
27202
27203
27204
27205
27206
27207
27208
27209
27210
27211
27212
27213
27214
27215
27216
27217
27218
27219
27220
27221
27222
27223
27224
27225
27226
27227
27228
27229
27230
27231
27232
27233
27234
27235
27236
27237
27238
27239
27240
27241
27242
27243
27244
27245
27246
27247
27248
27249
27250
27251
27252
27253
27254
27255
27256
27257
27258
27259
27260
27261
27262
27263
27264
27265
27266
27267
27268
27269
27270
27271
27272
27273
27274
27275
27276
27277
27278
27279
27280
27281
27282
27283
27284
27285
27286
27287
27288
27289
27290
27291
27292
27293
27294
27295
27296
27297
27298
27299
27300
27301
27302
27303
27304
27305
27306
27307
27308
27309
27310
27311
27312
27313
27314
27315
27316
27317
27318
27319
27320
27321
27322
27323
27324
27325
27326
27327
27328
27329
27330
27331
27332
27333
27334
27335
27336
27337
27338
27339
27340
27341
27342
27343
27344
27345
27346
27347
27348
27349
27350
27351
27352
27353
27354
27355
27356
27357
27358
27359
27360
27361
27362
27363
27364
27365
27366
27367
27368
27369
27370
27371
27372
27373
27374
27375
27376
27377
27378
27379
27380
27381
27382
27383
27384
27385
27386
27387
27388
27389
27390
27391
27392
27393
27394
27395
27396
27397
27398
27399
27400
27401
27402
27403
27404
27405
27406
27407
27408
27409
27410
27411
27412
27413
27414
27415
27416
27417
27418
27419
27420
27421
27422
27423
27424
27425
27426
27427
27428
27429
27430
27431
27432
27433
27434
27435
27436
27437
27438
27439
27440
27441
27442
27443
27444
27445
27446
27447
27448
27449
27450
27451
27452
27453
27454
27455
27456
27457
27458
27459
27460
27461
27462
27463
27464
27465
27466
27467
27468
27469
27470
27471
27472
27473
27474
27475
27476
27477
27478
27479
27480
27481
27482
27483
27484
27485
27486
27487
27488
27489
27490
27491
27492
27493
27494
27495
27496
27497
27498
27499
27500
27501
27502
27503
27504
27505
27506
27507
27508
27509
27510
27511
27512
27513
27514
27515
27516
27517
27518
27519
27520
27521
27522
27523
27524
27525
27526
27527
27528
27529
27530
27531
27532
27533
27534
27535
27536
27537
27538
27539
27540
27541
27542
27543
27544
27545
27546
27547
27548
27549
27550
27551
27552
27553
27554
27555
27556
27557
27558
27559
27560
27561
27562
27563
27564
27565
27566
27567
27568
27569
27570
27571
27572
27573
27574
27575
27576
27577
27578
27579
27580
27581
27582
27583
27584
27585
27586
27587
27588
27589
27590
27591
27592
27593
27594
27595
27596
27597
27598
27599
27600
27601
27602
27603
27604
27605
27606
27607
27608
27609
27610
27611
27612
27613
27614
27615
27616
27617
27618
27619
27620
27621
27622
27623
27624
27625
27626
27627
27628
27629
27630
27631
27632
27633
27634
27635
27636
27637
27638
27639
27640
27641
27642
27643
27644
27645
27646
27647
27648
27649
27650
27651
27652
27653
27654
27655
27656
27657
27658
27659
27660
27661
27662
27663
27664
27665
27666
27667
27668
27669
27670
27671
27672
27673
27674
27675
27676
27677
27678
27679
27680
27681
27682
27683
27684
27685
27686
27687
27688
27689
27690
27691
27692
27693
27694
27695
27696
27697
27698
27699
27700
27701
27702
27703
27704
27705
27706
27707
27708
27709
27710
27711
27712
27713
27714
27715
27716
27717
27718
27719
27720
27721
27722
27723
27724
27725
27726
27727
27728
27729
27730
27731
27732
27733
27734
27735
27736
27737
27738
27739
27740
27741
27742
27743
27744
27745
27746
27747
27748
27749
27750
27751
27752
27753
27754
27755
27756
27757
27758
27759
27760
27761
27762
27763
27764
27765
27766
27767
27768
27769
27770
27771
27772
27773
27774
27775
27776
27777
27778
27779
27780
27781
27782
27783
27784
27785
27786
27787
27788
27789
27790
27791
27792
27793
27794
27795
27796
27797
27798
27799
27800
27801
27802
27803
27804
27805
27806
27807
27808
27809
27810
27811
27812
27813
27814
27815
27816
27817
27818
27819
27820
27821
27822
27823
27824
27825
27826
27827
27828
27829
27830
27831
27832
27833
27834
27835
27836
27837
27838
27839
27840
27841
27842
27843
27844
27845
27846
27847
27848
27849
27850
27851
27852
27853
27854
27855
27856
27857
27858
27859
27860
27861
27862
27863
27864
27865
27866
27867
27868
27869
27870
27871
27872
27873
27874
27875
27876
27877
27878
27879
27880
27881
27882
27883
27884
27885
27886
27887
27888
27889
27890
27891
27892
27893
27894
27895
27896
27897
27898
27899
27900
27901
27902
27903
27904
27905
27906
27907
27908
27909
27910
27911
27912
27913
27914
27915
27916
27917
27918
27919
27920
27921
27922
27923
27924
27925
27926
27927
27928
27929
27930
27931
27932
27933
27934
27935
27936
27937
27938
27939
27940
27941
27942
27943
27944
27945
27946
27947
27948
27949
27950
27951
27952
27953
27954
27955
27956
27957
27958
27959
27960
27961
27962
27963
27964
27965
27966
27967
27968
27969
27970
27971
27972
27973
27974
27975
27976
27977
27978
27979
27980
27981
27982
27983
27984
27985
27986
27987
27988
27989
27990
27991
27992
27993
27994
27995
27996
27997
27998
27999
28000
28001
28002
28003
28004
28005
28006
28007
28008
28009
28010
28011
28012
28013
28014
28015
28016
28017
28018
28019
28020
28021
28022
28023
28024
28025
28026
28027
28028
28029
28030
28031
28032
28033
28034
28035
28036
28037
28038
28039
28040
28041
28042
28043
28044
28045
28046
28047
28048
28049
28050
28051
28052
28053
28054
28055
28056
28057
28058
28059
28060
28061
28062
28063
28064
28065
28066
28067
28068
28069
28070
28071
28072
28073
28074
28075
28076
28077
28078
28079
28080
28081
28082
28083
28084
28085
28086
28087
28088
28089
28090
28091
28092
28093
28094
28095
28096
28097
28098
28099
28100
28101
28102
28103
28104
28105
28106
28107
28108
28109
28110
28111
28112
28113
28114
28115
28116
28117
28118
28119
28120
28121
28122
28123
28124
28125
28126
28127
28128
28129
28130
28131
28132
28133
28134
28135
28136
28137
28138
28139
28140
28141
28142
28143
28144
28145
28146
28147
28148
28149
28150
28151
28152
28153
28154
28155
28156
28157
28158
28159
28160
28161
28162
28163
28164
28165
28166
28167
28168
28169
28170
28171
28172
28173
28174
28175
28176
28177
28178
28179
28180
28181
28182
28183
28184
28185
28186
28187
28188
28189
28190
28191
28192
28193
28194
28195
28196
28197
28198
28199
28200
28201
28202
28203
28204
28205
28206
28207
28208
28209
28210
28211
28212
28213
28214
28215
28216
28217
28218
28219
28220
28221
28222
28223
28224
28225
28226
28227
28228
28229
28230
28231
28232
28233
28234
28235
28236
28237
28238
28239
28240
28241
28242
28243
28244
28245
28246
28247
28248
28249
28250
28251
28252
28253
28254
28255
28256
28257
28258
28259
28260
28261
28262
28263
28264
28265
28266
28267
28268
28269
28270
28271
28272
28273
28274
28275
28276
28277
28278
28279
28280
28281
28282
28283
28284
28285
28286
28287
28288
28289
28290
28291
28292
28293
28294
28295
28296
28297
28298
28299
28300
28301
28302
28303
28304
28305
28306
28307
28308
28309
28310
28311
28312
28313
28314
28315
28316
28317
28318
28319
28320
28321
28322
28323
28324
28325
28326
28327
28328
28329
28330
28331
28332
28333
28334
28335
28336
28337
28338
28339
28340
28341
28342
28343
28344
28345
28346
28347
28348
28349
28350
28351
28352
28353
28354
28355
28356
28357
28358
28359
28360
28361
28362
28363
28364
28365
28366
28367
28368
28369
28370
28371
28372
28373
28374
28375
28376
28377
28378
28379
28380
28381
28382
28383
28384
28385
28386
28387
28388
28389
28390
28391
28392
28393
28394
28395
28396
28397
28398
28399
28400
28401
28402
28403
28404
28405
28406
28407
28408
28409
28410
28411
28412
28413
28414
28415
28416
28417
28418
28419
28420
28421
28422
28423
28424
28425
28426
28427
28428
28429
28430
28431
28432
28433
28434
28435
28436
28437
28438
28439
28440
28441
28442
28443
28444
28445
28446
28447
28448
28449
28450
28451
28452
28453
28454
28455
28456
28457
28458
28459
28460
28461
28462
28463
28464
28465
28466
28467
28468
28469
28470
28471
28472
28473
28474
28475
28476
28477
28478
28479
28480
28481
28482
28483
28484
28485
28486
28487
28488
28489
28490
28491
28492
28493
28494
28495
28496
28497
28498
28499
28500
28501
28502
28503
28504
28505
28506
28507
28508
28509
28510
28511
28512
28513
28514
28515
28516
28517
28518
28519
28520
28521
28522
28523
28524
28525
28526
28527
28528
28529
28530
28531
28532
28533
28534
28535
28536
28537
28538
28539
28540
28541
28542
28543
28544
28545
28546
28547
28548
28549
28550
28551
28552
28553
28554
28555
28556
28557
28558
28559
28560
28561
28562
28563
28564
28565
28566
28567
28568
28569
28570
28571
28572
28573
28574
28575
28576
28577
28578
28579
28580
28581
28582
28583
28584
28585
28586
28587
28588
28589
28590
28591
28592
28593
28594
28595
28596
28597
28598
28599
28600
28601
28602
28603
28604
28605
28606
28607
28608
28609
28610
28611
28612
28613
28614
28615
28616
28617
28618
28619
28620
28621
28622
28623
28624
28625
28626
28627
28628
28629
28630
28631
28632
28633
28634
28635
28636
28637
28638
28639
28640
28641
28642
28643
28644
28645
28646
28647
28648
28649
28650
28651
28652
28653
28654
28655
28656
28657
28658
28659
28660
28661
28662
28663
28664
28665
28666
28667
28668
28669
28670
28671
28672
28673
28674
28675
28676
28677
28678
28679
28680
28681
28682
28683
28684
28685
28686
28687
28688
28689
28690
28691
28692
28693
28694
28695
28696
28697
28698
28699
28700
28701
28702
28703
28704
28705
28706
28707
28708
28709
28710
28711
28712
28713
28714
28715
28716
28717
28718
28719
28720
28721
28722
28723
28724
28725
28726
28727
28728
28729
28730
28731
28732
28733
28734
28735
28736
28737
28738
28739
28740
28741
28742
28743
28744
28745
28746
28747
28748
28749
28750
28751
28752
28753
28754
28755
28756
28757
28758
28759
28760
28761
28762
28763
28764
28765
28766
28767
28768
28769
28770
28771
28772
28773
28774
28775
28776
28777
28778
28779
28780
28781
28782
28783
28784
28785
28786
28787
28788
28789
28790
28791
28792
28793
28794
28795
28796
28797
28798
28799
28800
28801
28802
28803
28804
28805
28806
28807
28808
28809
28810
28811
28812
28813
28814
28815
28816
28817
28818
28819
28820
28821
28822
28823
28824
28825
28826
28827
28828
28829
28830
28831
28832
28833
28834
28835
28836
28837
28838
28839
28840
28841
28842
28843
28844
28845
28846
28847
28848
28849
28850
28851
28852
28853
28854
28855
28856
28857
28858
28859
28860
28861
28862
28863
28864
28865
28866
28867
28868
28869
28870
28871
28872
28873
28874
28875
28876
28877
28878
28879
28880
28881
28882
28883
28884
28885
28886
28887
28888
28889
28890
28891
28892
28893
28894
28895
28896
28897
28898
28899
28900
28901
28902
28903
28904
28905
28906
28907
28908
28909
28910
28911
28912
28913
28914
28915
28916
28917
28918
28919
28920
28921
28922
28923
28924
28925
28926
28927
28928
28929
28930
28931
28932
28933
28934
28935
28936
28937
28938
28939
28940
28941
28942
28943
28944
28945
28946
28947
28948
28949
28950
28951
28952
28953
28954
28955
28956
28957
28958
28959
28960
28961
28962
28963
28964
28965
28966
28967
28968
28969
28970
28971
28972
28973
28974
28975
28976
28977
28978
28979
28980
28981
28982
28983
28984
28985
28986
28987
28988
28989
28990
28991
28992
28993
28994
28995
28996
28997
28998
28999
29000
29001
29002
29003
29004
29005
29006
29007
29008
29009
29010
29011
29012
29013
29014
29015
29016
29017
29018
29019
29020
29021
29022
29023
29024
29025
29026
29027
29028
29029
29030
29031
29032
29033
29034
29035
29036
29037
29038
29039
29040
29041
29042
29043
29044
29045
29046
29047
29048
29049
29050
29051
29052
29053
29054
29055
29056
29057
29058
29059
29060
29061
29062
29063
29064
29065
29066
29067
29068
29069
29070
29071
29072
29073
29074
29075
29076
29077
29078
29079
29080
29081
29082
29083
29084
29085
29086
29087
29088
29089
29090
29091
29092
29093
29094
29095
29096
29097
29098
29099
29100
29101
29102
29103
29104
29105
29106
29107
29108
29109
29110
29111
29112
29113
29114
29115
29116
29117
29118
29119
29120
29121
29122
29123
29124
29125
29126
29127
29128
29129
29130
29131
29132
29133
29134
29135
29136
29137
29138
29139
29140
29141
29142
29143
29144
29145
29146
29147
29148
29149
29150
29151
29152
29153
29154
29155
29156
29157
29158
29159
29160
29161
29162
29163
29164
29165
29166
29167
29168
29169
29170
29171
29172
29173
29174
29175
29176
29177
29178
29179
29180
29181
29182
29183
29184
29185
29186
29187
29188
29189
29190
29191
29192
29193
29194
29195
29196
29197
29198
29199
29200
29201
29202
29203
29204
29205
29206
29207
29208
29209
29210
29211
29212
29213
29214
29215
29216
29217
29218
29219
29220
29221
29222
29223
29224
29225
29226
29227
29228
29229
29230
29231
29232
29233
29234
29235
29236
29237
29238
29239
29240
29241
29242
29243
29244
29245
29246
29247
29248
29249
29250
29251
29252
29253
29254
29255
29256
29257
29258
29259
29260
29261
29262
29263
29264
29265
29266
29267
29268
29269
29270
29271
29272
29273
29274
29275
29276
29277
29278
29279
29280
29281
29282
29283
29284
29285
29286
29287
29288
29289
29290
29291
29292
29293
29294
29295
29296
29297
29298
29299
29300
29301
29302
29303
29304
29305
29306
29307
29308
29309
29310
29311
29312
29313
29314
29315
29316
29317
29318
29319
29320
29321
29322
29323
29324
29325
29326
29327
29328
29329
29330
29331
29332
29333
29334
29335
29336
29337
29338
29339
29340
29341
29342
29343
29344
29345
29346
29347
29348
29349
29350
29351
29352
29353
29354
29355
29356
29357
29358
29359
29360
29361
29362
29363
29364
29365
29366
29367
29368
29369
29370
29371
29372
29373
29374
29375
29376
29377
29378
29379
29380
29381
29382
29383
29384
29385
29386
29387
29388
29389
29390
29391
29392
29393
29394
29395
29396
29397
29398
29399
29400
29401
29402
29403
29404
29405
29406
29407
29408
29409
29410
29411
29412
29413
29414
29415
29416
29417
29418
29419
29420
29421
29422
29423
29424
29425
29426
29427
29428
29429
29430
29431
29432
29433
29434
29435
29436
29437
29438
29439
29440
29441
29442
29443
29444
29445
29446
29447
29448
29449
29450
29451
29452
29453
29454
29455
29456
29457
29458
29459
29460
29461
29462
29463
29464
29465
29466
29467
29468
29469
29470
29471
29472
29473
29474
29475
29476
29477
29478
29479
29480
29481
29482
29483
29484
29485
29486
29487
29488
29489
29490
29491
29492
29493
29494
29495
29496
29497
29498
29499
29500
29501
29502
29503
29504
29505
29506
29507
29508
29509
29510
29511
29512
29513
29514
29515
29516
29517
29518
29519
29520
29521
29522
29523
29524
29525
29526
29527
29528
29529
29530
29531
29532
29533
29534
29535
29536
29537
29538
29539
29540
29541
29542
29543
29544
29545
29546
29547
29548
29549
29550
29551
29552
29553
29554
29555
29556
29557
29558
29559
29560
29561
29562
29563
29564
29565
29566
29567
29568
29569
29570
29571
29572
29573
29574
29575
29576
29577
29578
29579
29580
29581
29582
29583
29584
29585
29586
29587
29588
29589
29590
29591
29592
29593
29594
29595
29596
29597
29598
29599
29600
29601
29602
29603
29604
29605
29606
29607
29608
29609
29610
29611
29612
29613
29614
29615
29616
29617
29618
29619
29620
29621
29622
29623
29624
29625
29626
29627
29628
29629
29630
29631
29632
29633
29634
29635
29636
29637
29638
29639
29640
29641
29642
29643
29644
29645
29646
29647
29648
29649
29650
29651
29652
29653
29654
29655
29656
29657
29658
29659
29660
29661
29662
29663
29664
29665
29666
29667
29668
29669
29670
29671
29672
29673
29674
29675
29676
29677
29678
29679
29680
29681
29682
29683
29684
29685
29686
29687
29688
29689
29690
29691
29692
29693
29694
29695
29696
29697
29698
29699
29700
29701
29702
29703
29704
29705
29706
29707
29708
29709
29710
29711
29712
29713
29714
29715
29716
29717
29718
29719
29720
29721
29722
29723
29724
29725
29726
29727
29728
29729
29730
29731
29732
29733
29734
29735
29736
29737
29738
29739
29740
29741
29742
29743
29744
29745
29746
29747
29748
29749
29750
29751
29752
29753
29754
29755
29756
29757
29758
29759
29760
29761
29762
29763
29764
29765
29766
29767
29768
29769
29770
29771
29772
29773
29774
29775
29776
29777
29778
29779
29780
29781
29782
29783
29784
29785
29786
29787
29788
29789
29790
29791
29792
29793
29794
29795
29796
29797
29798
29799
29800
29801
29802
29803
29804
29805
29806
29807
29808
29809
29810
29811
29812
29813
29814
29815
29816
29817
29818
29819
29820
29821
29822
29823
29824
29825
29826
29827
29828
29829
29830
29831
29832
29833
29834
29835
29836
29837
29838
29839
29840
29841
29842
29843
29844
29845
29846
29847
29848
29849
29850
29851
29852
29853
29854
29855
29856
29857
29858
29859
29860
29861
29862
29863
29864
29865
29866
29867
29868
29869
29870
29871
29872
29873
29874
29875
29876
29877
29878
29879
29880
29881
29882
29883
29884
29885
29886
29887
29888
29889
29890
29891
29892
29893
29894
29895
29896
29897
29898
29899
29900
29901
29902
29903
29904
29905
29906
29907
29908
29909
29910
29911
29912
29913
29914
29915
29916
29917
29918
29919
29920
29921
29922
29923
29924
29925
29926
29927
29928
29929
29930
29931
29932
29933
29934
29935
29936
29937
29938
29939
29940
29941
29942
29943
29944
29945
29946
29947
29948
29949
29950
29951
29952
29953
29954
29955
29956
29957
29958
29959
29960
29961
29962
29963
29964
29965
29966
29967
29968
29969
29970
29971
29972
29973
29974
29975
29976
29977
29978
29979
29980
29981
29982
29983
29984
29985
29986
29987
29988
29989
29990
29991
29992
29993
29994
29995
29996
29997
29998
29999
30000
30001
30002
30003
30004
30005
30006
30007
30008
30009
30010
30011
30012
30013
30014
30015
30016
30017
30018
30019
30020
30021
30022
30023
30024
30025
30026
30027
30028
30029
30030
30031
30032
30033
30034
30035
30036
30037
30038
30039
30040
30041
30042
30043
30044
30045
30046
30047
30048
30049
30050
30051
30052
30053
30054
30055
30056
30057
30058
30059
30060
30061
30062
30063
30064
30065
30066
30067
30068
30069
30070
30071
30072
30073
30074
30075
30076
30077
30078
30079
30080
30081
30082
30083
30084
30085
30086
30087
30088
30089
30090
30091
30092
30093
30094
30095
30096
30097
30098
30099
30100
30101
30102
30103
30104
30105
30106
30107
30108
30109
30110
30111
30112
30113
30114
30115
30116
30117
30118
30119
30120
30121
30122
30123
30124
30125
30126
30127
30128
30129
30130
30131
30132
30133
30134
30135
30136
30137
30138
30139
30140
30141
30142
30143
30144
30145
30146
30147
30148
30149
30150
30151
30152
30153
30154
30155
30156
30157
30158
30159
30160
30161
30162
30163
30164
30165
30166
30167
30168
30169
30170
30171
30172
30173
30174
30175
30176
30177
30178
30179
30180
30181
30182
30183
30184
30185
30186
30187
30188
30189
30190
30191
30192
30193
30194
30195
30196
30197
30198
30199
30200
30201
30202
30203
30204
30205
30206
30207
30208
30209
30210
30211
30212
30213
30214
30215
30216
30217
30218
30219
30220
30221
30222
30223
30224
30225
30226
30227
30228
30229
30230
30231
30232
30233
30234
30235
30236
30237
30238
30239
30240
30241
30242
30243
30244
30245
30246
30247
30248
30249
30250
30251
30252
30253
30254
30255
30256
30257
30258
30259
30260
30261
30262
30263
30264
30265
30266
30267
30268
30269
30270
30271
30272
30273
30274
30275
30276
30277
30278
30279
30280
30281
30282
30283
30284
30285
30286
30287
30288
30289
30290
30291
30292
30293
30294
30295
30296
30297
30298
30299
30300
30301
30302
30303
30304
30305
30306
30307
30308
30309
30310
30311
30312
30313
30314
30315
30316
30317
30318
30319
30320
30321
30322
30323
30324
30325
30326
30327
30328
30329
30330
30331
30332
30333
30334
30335
30336
30337
30338
30339
30340
30341
30342
30343
30344
30345
30346
30347
30348
30349
30350
30351
30352
30353
30354
30355
30356
30357
30358
30359
30360
30361
30362
30363
30364
30365
30366
30367
30368
30369
30370
30371
30372
30373
30374
30375
30376
30377
30378
30379
30380
30381
30382
30383
30384
30385
30386
30387
30388
30389
30390
30391
30392
30393
30394
30395
30396
30397
30398
30399
30400
30401
30402
30403
30404
30405
30406
30407
30408
30409
30410
30411
30412
30413
30414
30415
30416
30417
30418
30419
30420
30421
30422
30423
30424
30425
30426
30427
30428
30429
30430
30431
30432
30433
30434
30435
30436
30437
30438
30439
30440
30441
30442
30443
30444
30445
30446
30447
30448
30449
30450
30451
30452
30453
30454
30455
30456
30457
30458
30459
30460
30461
30462
30463
30464
30465
30466
30467
30468
30469
30470
30471
30472
30473
30474
30475
30476
30477
30478
30479
30480
30481
30482
30483
30484
30485
30486
30487
30488
30489
30490
30491
30492
30493
30494
30495
30496
30497
30498
30499
30500
30501
30502
30503
30504
30505
30506
30507
30508
30509
30510
30511
30512
30513
30514
30515
30516
30517
30518
30519
30520
30521
30522
30523
30524
30525
30526
30527
30528
30529
30530
30531
30532
30533
30534
30535
30536
30537
30538
30539
30540
30541
30542
30543
30544
30545
30546
30547
30548
30549
30550
30551
30552
30553
30554
30555
30556
30557
30558
30559
30560
30561
30562
30563
30564
30565
30566
30567
30568
30569
30570
30571
30572
30573
30574
30575
30576
30577
30578
30579
30580
30581
30582
30583
30584
30585
30586
30587
30588
30589
30590
30591
30592
30593
30594
30595
30596
30597
30598
30599
30600
30601
30602
30603
30604
30605
30606
30607
30608
30609
30610
30611
30612
30613
30614
30615
30616
30617
30618
30619
30620
30621
30622
30623
30624
30625
30626
30627
30628
30629
30630
30631
30632
30633
30634
30635
30636
30637
30638
30639
30640
30641
30642
30643
30644
30645
30646
30647
30648
30649
30650
30651
30652
30653
30654
30655
30656
30657
30658
30659
30660
30661
30662
30663
30664
30665
30666
30667
30668
30669
30670
30671
30672
30673
30674
30675
30676
30677
30678
30679
30680
30681
30682
30683
30684
30685
30686
30687
30688
30689
30690
30691
30692
30693
30694
30695
30696
30697
30698
30699
30700
30701
30702
30703
30704
30705
30706
30707
30708
30709
30710
30711
30712
30713
30714
30715
30716
30717
30718
30719
30720
30721
30722
30723
30724
30725
30726
30727
30728
30729
30730
30731
30732
30733
30734
30735
30736
30737
30738
30739
30740
30741
30742
30743
30744
30745
30746
30747
30748
30749
30750
30751
30752
30753
30754
30755
30756
30757
30758
30759
30760
30761
30762
30763
30764
30765
30766
30767
30768
30769
30770
30771
30772
30773
30774
30775
30776
30777
30778
30779
30780
30781
30782
30783
30784
30785
30786
30787
30788
30789
30790
30791
30792
30793
30794
30795
30796
30797
30798
30799
30800
30801
30802
30803
30804
30805
30806
30807
30808
30809
30810
30811
30812
30813
30814
30815
30816
30817
30818
30819
30820
30821
30822
30823
30824
30825
30826
30827
30828
30829
30830
30831
30832
30833
30834
30835
30836
30837
30838
30839
30840
30841
30842
30843
30844
30845
30846
30847
30848
30849
30850
30851
30852
30853
30854
30855
30856
30857
30858
30859
30860
30861
30862
30863
30864
30865
30866
30867
30868
30869
30870
30871
30872
30873
30874
30875
30876
30877
30878
30879
30880
30881
30882
30883
30884
30885
30886
30887
30888
30889
30890
30891
30892
30893
30894
30895
30896
30897
30898
30899
30900
30901
30902
30903
30904
30905
30906
30907
30908
30909
30910
30911
30912
30913
30914
30915
30916
30917
30918
30919
30920
30921
30922
30923
30924
30925
30926
30927
30928
30929
30930
30931
30932
30933
30934
30935
30936
30937
30938
30939
30940
30941
30942
30943
30944
30945
30946
30947
30948
30949
30950
30951
30952
30953
30954
30955
30956
30957
30958
30959
30960
30961
30962
30963
30964
30965
30966
30967
30968
30969
30970
30971
30972
30973
30974
30975
30976
30977
30978
30979
30980
30981
30982
30983
30984
30985
30986
30987
30988
30989
30990
30991
30992
30993
30994
30995
30996
30997
30998
30999
31000
31001
31002
31003
31004
31005
31006
31007
31008
31009
31010
31011
31012
31013
31014
31015
31016
31017
31018
31019
31020
31021
31022
31023
31024
31025
31026
31027
31028
31029
31030
31031
31032
31033
31034
31035
31036
31037
31038
31039
31040
31041
31042
31043
31044
31045
31046
31047
31048
31049
31050
31051
31052
31053
31054
31055
31056
31057
31058
31059
31060
31061
31062
31063
31064
31065
31066
31067
31068
31069
31070
31071
31072
31073
31074
31075
31076
31077
31078
31079
31080
31081
31082
31083
31084
31085
31086
31087
31088
31089
31090
31091
31092
31093
31094
31095
31096
31097
31098
31099
31100
31101
31102
31103
31104
31105
31106
31107
31108
31109
31110
31111
31112
31113
31114
31115
31116
31117
31118
31119
31120
31121
31122
31123
31124
31125
31126
31127
31128
31129
31130
31131
31132
31133
31134
31135
31136
31137
31138
31139
31140
31141
31142
31143
31144
31145
31146
31147
31148
31149
31150
31151
31152
31153
31154
31155
31156
31157
31158
31159
31160
31161
31162
31163
31164
31165
31166
31167
31168
31169
31170
31171
31172
31173
31174
31175
31176
31177
31178
31179
31180
31181
31182
31183
31184
31185
31186
31187
31188
31189
31190
31191
31192
31193
31194
31195
31196
31197
31198
31199
31200
31201
31202
31203
31204
31205
31206
31207
31208
31209
31210
31211
31212
31213
31214
31215
31216
31217
31218
31219
31220
31221
31222
31223
31224
31225
31226
31227
31228
31229
31230
31231
31232
31233
31234
31235
31236
31237
31238
31239
31240
31241
31242
31243
31244
31245
31246
31247
31248
31249
31250
31251
31252
31253
31254
31255
31256
31257
31258
31259
31260
31261
31262
31263
31264
31265
31266
31267
31268
31269
31270
31271
31272
31273
31274
31275
31276
31277
31278
31279
31280
31281
31282
31283
31284
31285
31286
31287
31288
31289
31290
31291
31292
31293
31294
31295
31296
31297
31298
31299
31300
31301
31302
31303
31304
31305
31306
31307
31308
31309
31310
31311
31312
31313
31314
31315
31316
31317
31318
31319
31320
31321
31322
31323
31324
31325
31326
31327
31328
31329
31330
31331
31332
31333
31334
31335
31336
31337
31338
31339
31340
31341
31342
31343
31344
31345
31346
31347
31348
31349
31350
31351
31352
31353
31354
31355
31356
31357
31358
31359
31360
31361
31362
31363
31364
31365
31366
31367
31368
31369
31370
31371
31372
31373
31374
31375
31376
31377
31378
31379
31380
31381
31382
31383
31384
31385
31386
31387
31388
31389
31390
31391
31392
31393
31394
31395
31396
31397
31398
31399
31400
31401
31402
31403
31404
31405
31406
31407
31408
31409
31410
31411
31412
31413
31414
31415
31416
31417
31418
31419
31420
31421
31422
31423
31424
31425
31426
31427
31428
31429
31430
31431
31432
31433
31434
31435
31436
31437
31438
31439
31440
31441
31442
31443
31444
31445
31446
31447
31448
31449
31450
31451
31452
31453
31454
31455
31456
31457
31458
31459
31460
31461
31462
31463
31464
31465
31466
31467
31468
31469
31470
31471
31472
31473
31474
31475
31476
31477
31478
31479
31480
31481
31482
31483
31484
31485
31486
31487
31488
31489
31490
31491
31492
31493
31494
31495
31496
31497
31498
31499
31500
31501
31502
31503
31504
31505
31506
31507
31508
31509
31510
31511
31512
31513
31514
31515
31516
31517
31518
31519
31520
31521
31522
31523
31524
31525
31526
31527
31528
31529
31530
31531
31532
31533
31534
31535
31536
31537
31538
31539
31540
31541
31542
31543
31544
31545
31546
31547
31548
31549
31550
31551
31552
31553
31554
31555
31556
31557
31558
31559
31560
31561
31562
31563
31564
31565
31566
31567
31568
31569
31570
31571
31572
31573
31574
31575
31576
31577
31578
31579
31580
31581
31582
31583
31584
31585
31586
31587
31588
31589
31590
31591
31592
31593
31594
31595
31596
31597
31598
31599
31600
31601
31602
31603
31604
31605
31606
31607
31608
31609
31610
31611
31612
31613
31614
31615
31616
31617
31618
31619
31620
31621
31622
31623
31624
31625
31626
31627
31628
31629
31630
31631
31632
31633
31634
31635
31636
31637
31638
31639
31640
31641
31642
31643
31644
31645
31646
31647
31648
31649
31650
31651
31652
31653
31654
31655
31656
31657
31658
31659
31660
31661
31662
31663
31664
31665
31666
31667
31668
31669
31670
31671
31672
31673
31674
31675
31676
31677
31678
31679
31680
31681
31682
31683
31684
31685
31686
31687
31688
31689
31690
31691
31692
31693
31694
31695
31696
31697
31698
31699
31700
31701
31702
31703
31704
31705
31706
31707
31708
31709
31710
31711
31712
31713
31714
31715
31716
31717
31718
31719
31720
31721
31722
31723
31724
31725
31726
31727
31728
31729
31730
31731
31732
31733
31734
31735
31736
31737
31738
31739
31740
31741
31742
31743
31744
31745
31746
31747
31748
31749
31750
31751
31752
31753
31754
31755
31756
31757
31758
31759
31760
31761
31762
31763
31764
31765
31766
31767
31768
31769
31770
31771
31772
31773
31774
31775
31776
31777
31778
31779
31780
31781
31782
31783
31784
31785
31786
31787
31788
31789
31790
31791
31792
31793
31794
31795
31796
31797
31798
31799
31800
31801
31802
31803
31804
31805
31806
31807
31808
31809
31810
31811
31812
31813
31814
31815
31816
31817
31818
31819
31820
31821
31822
31823
31824
31825
31826
31827
31828
31829
31830
31831
31832
31833
31834
31835
31836
31837
31838
31839
31840
31841
31842
31843
31844
31845
31846
31847
31848
31849
31850
31851
31852
31853
31854
31855
31856
31857
31858
31859
31860
31861
31862
31863
31864
31865
31866
31867
31868
31869
31870
31871
31872
31873
31874
31875
31876
31877
31878
31879
31880
31881
31882
31883
31884
31885
31886
31887
31888
31889
31890
31891
31892
31893
31894
31895
31896
31897
31898
31899
31900
31901
31902
31903
31904
31905
31906
31907
31908
31909
31910
31911
31912
31913
31914
31915
31916
31917
31918
31919
31920
31921
31922
31923
31924
31925
31926
31927
31928
31929
31930
31931
31932
31933
31934
31935
31936
31937
31938
31939
31940
31941
31942
31943
31944
31945
31946
31947
31948
31949
31950
31951
31952
31953
31954
31955
31956
31957
31958
31959
31960
31961
31962
31963
31964
31965
31966
31967
31968
31969
31970
31971
31972
31973
31974
31975
31976
31977
31978
31979
31980
31981
31982
31983
31984
31985
31986
31987
31988
31989
31990
31991
31992
31993
31994
31995
31996
31997
31998
31999
32000
32001
32002
32003
32004
32005
32006
32007
32008
32009
32010
32011
32012
32013
32014
32015
32016
32017
32018
32019
32020
32021
32022
32023
32024
32025
32026
32027
32028
32029
32030
32031
32032
32033
32034
32035
32036
32037
32038
32039
32040
32041
32042
32043
32044
32045
32046
32047
32048
32049
32050
32051
32052
32053
32054
32055
32056
32057
32058
32059
32060
32061
32062
32063
32064
32065
32066
32067
32068
32069
32070
32071
32072
32073
32074
32075
32076
32077
32078
32079
32080
32081
32082
32083
32084
32085
32086
32087
32088
32089
32090
32091
32092
32093
32094
32095
32096
32097
32098
32099
32100
32101
32102
32103
32104
32105
32106
32107
32108
32109
32110
32111
32112
32113
32114
32115
32116
32117
32118
32119
32120
32121
32122
32123
32124
32125
32126
32127
32128
32129
32130
32131
32132
32133
32134
32135
32136
32137
32138
32139
32140
32141
32142
32143
32144
32145
32146
32147
32148
32149
32150
32151
32152
32153
32154
32155
32156
32157
32158
32159
32160
32161
32162
32163
32164
32165
32166
32167
32168
32169
32170
32171
32172
32173
32174
32175
32176
32177
32178
32179
32180
32181
32182
32183
32184
32185
32186
32187
32188
32189
32190
32191
32192
32193
32194
32195
32196
32197
32198
32199
32200
32201
32202
32203
32204
32205
32206
32207
32208
32209
32210
32211
32212
32213
32214
32215
32216
32217
32218
32219
32220
32221
32222
32223
32224
32225
32226
32227
32228
32229
32230
32231
32232
32233
32234
32235
32236
32237
32238
32239
32240
32241
32242
32243
32244
32245
32246
32247
32248
32249
32250
32251
32252
32253
32254
32255
32256
32257
32258
32259
32260
32261
32262
32263
32264
32265
32266
32267
32268
32269
32270
32271
32272
32273
32274
32275
32276
32277
32278
32279
32280
32281
32282
32283
32284
32285
32286
32287
32288
32289
32290
32291
32292
32293
32294
32295
32296
32297
32298
32299
32300
32301
32302
32303
32304
32305
32306
32307
32308
32309
32310
32311
32312
32313
32314
32315
32316
32317
32318
32319
32320
32321
32322
32323
32324
32325
32326
32327
32328
32329
32330
32331
32332
32333
32334
32335
32336
32337
32338
32339
32340
32341
32342
32343
32344
32345
32346
32347
32348
32349
32350
32351
32352
32353
32354
32355
32356
32357
32358
32359
32360
32361
32362
32363
32364
32365
32366
32367
32368
32369
32370
32371
32372
32373
32374
32375
32376
32377
32378
32379
32380
32381
32382
32383
32384
32385
32386
32387
32388
32389
32390
32391
32392
32393
32394
32395
32396
32397
32398
32399
32400
32401
32402
32403
32404
32405
32406
32407
32408
32409
32410
32411
32412
32413
32414
32415
32416
32417
32418
32419
32420
32421
32422
32423
32424
32425
32426
32427
32428
32429
32430
32431
32432
32433
32434
32435
32436
32437
32438
32439
32440
32441
32442
32443
32444
32445
32446
32447
32448
32449
32450
32451
32452
32453
32454
32455
32456
32457
32458
32459
32460
32461
32462
32463
32464
32465
32466
32467
32468
32469
32470
32471
32472
32473
32474
32475
32476
32477
32478
32479
32480
32481
32482
32483
32484
32485
32486
32487
32488
32489
32490
32491
32492
32493
32494
32495
32496
32497
32498
32499
32500
32501
32502
32503
32504
32505
32506
32507
32508
32509
32510
32511
32512
32513
32514
32515
32516
32517
32518
32519
32520
32521
32522
32523
32524
32525
32526
32527
32528
32529
32530
32531
32532
32533
32534
32535
32536
32537
32538
32539
32540
32541
32542
32543
32544
32545
32546
32547
32548
32549
32550
32551
32552
32553
32554
32555
32556
32557
32558
32559
32560
32561
32562
32563
32564
32565
32566
32567
32568
32569
32570
32571
32572
32573
32574
32575
32576
32577
32578
32579
32580
32581
32582
32583
32584
32585
32586
32587
32588
32589
32590
32591
32592
32593
32594
32595
32596
32597
32598
32599
32600
32601
32602
32603
32604
32605
32606
32607
32608
32609
32610
32611
32612
32613
32614
32615
32616
32617
32618
32619
32620
32621
32622
32623
32624
32625
32626
32627
32628
32629
32630
32631
32632
32633
32634
32635
32636
32637
32638
32639
32640
32641
32642
32643
32644
32645
32646
32647
32648
32649
32650
32651
32652
32653
32654
32655
32656
32657
32658
32659
32660
32661
32662
32663
32664
32665
32666
32667
32668
32669
32670
32671
32672
32673
32674
32675
32676
32677
32678
32679
32680
32681
32682
32683
32684
32685
32686
32687
32688
32689
32690
32691
32692
32693
32694
32695
32696
32697
32698
32699
32700
32701
32702
32703
32704
32705
32706
32707
32708
32709
32710
32711
32712
32713
32714
32715
32716
32717
32718
32719
32720
32721
32722
32723
32724
32725
32726
32727
32728
32729
32730
32731
32732
32733
32734
32735
32736
32737
32738
32739
32740
32741
32742
32743
32744
32745
32746
32747
32748
32749
32750
32751
32752
32753
32754
32755
32756
32757
32758
32759
32760
32761
32762
32763
32764
32765
32766
32767
32768
32769
32770
32771
32772
32773
32774
32775
32776
32777
32778
32779
32780
32781
32782
32783
32784
32785
32786
32787
32788
32789
32790
32791
32792
32793
32794
32795
32796
32797
32798
32799
32800
32801
32802
32803
32804
32805
32806
32807
32808
32809
32810
32811
32812
32813
32814
32815
32816
32817
32818
32819
32820
32821
32822
32823
32824
32825
32826
32827
32828
32829
32830
32831
32832
32833
32834
32835
32836
32837
32838
32839
32840
32841
32842
32843
32844
32845
32846
32847
32848
32849
32850
32851
32852
32853
32854
32855
32856
32857
32858
32859
32860
32861
32862
32863
32864
32865
32866
32867
32868
32869
32870
32871
32872
32873
32874
32875
32876
32877
32878
32879
32880
32881
32882
32883
32884
32885
32886
32887
32888
32889
32890
32891
32892
32893
32894
32895
32896
32897
32898
32899
32900
32901
32902
32903
32904
32905
32906
32907
32908
32909
32910
32911
32912
32913
32914
32915
32916
32917
32918
32919
32920
32921
32922
32923
32924
32925
32926
32927
32928
32929
32930
32931
32932
32933
32934
32935
32936
32937
32938
32939
32940
32941
32942
32943
32944
32945
32946
32947
32948
32949
32950
32951
32952
32953
32954
32955
32956
32957
32958
32959
32960
32961
32962
32963
32964
32965
32966
32967
32968
32969
32970
32971
32972
32973
32974
32975
32976
32977
32978
32979
32980
32981
32982
32983
32984
32985
32986
32987
32988
32989
32990
32991
32992
32993
32994
32995
32996
32997
32998
32999
33000
33001
33002
33003
33004
33005
33006
33007
33008
33009
33010
33011
33012
33013
33014
33015
33016
33017
33018
33019
33020
33021
33022
33023
33024
33025
33026
33027
33028
33029
33030
33031
33032
33033
33034
33035
33036
33037
33038
33039
33040
33041
33042
33043
33044
33045
33046
33047
33048
33049
33050
33051
33052
33053
33054
33055
33056
33057
33058
33059
33060
33061
33062
33063
33064
33065
33066
33067
33068
33069
33070
33071
33072
33073
33074
33075
33076
33077
33078
33079
33080
33081
33082
33083
33084
33085
33086
33087
33088
33089
33090
33091
33092
33093
33094
33095
33096
33097
33098
33099
33100
33101
33102
33103
33104
33105
33106
33107
33108
33109
33110
33111
33112
33113
33114
33115
33116
33117
33118
33119
33120
33121
33122
33123
33124
33125
33126
33127
33128
33129
33130
33131
33132
33133
33134
33135
33136
33137
33138
33139
33140
33141
33142
33143
33144
33145
33146
33147
33148
33149
33150
33151
33152
33153
33154
33155
33156
33157
33158
33159
33160
33161
33162
33163
33164
33165
33166
33167
33168
33169
33170
33171
33172
33173
33174
33175
33176
33177
33178
33179
33180
33181
33182
33183
33184
33185
33186
33187
33188
33189
33190
33191
33192
33193
33194
33195
33196
33197
33198
33199
33200
33201
33202
33203
33204
33205
33206
33207
33208
33209
33210
33211
33212
33213
33214
33215
33216
33217
33218
33219
33220
33221
33222
33223
33224
33225
33226
33227
33228
33229
33230
33231
33232
33233
33234
33235
33236
33237
33238
33239
33240
33241
33242
33243
33244
33245
33246
33247
33248
33249
33250
33251
33252
33253
33254
33255
33256
33257
33258
33259
33260
33261
33262
33263
33264
33265
33266
33267
33268
33269
33270
33271
33272
33273
33274
33275
33276
33277
33278
33279
33280
33281
33282
33283
33284
33285
33286
33287
33288
33289
33290
33291
33292
33293
33294
33295
33296
33297
33298
33299
33300
33301
33302
33303
33304
33305
33306
33307
33308
33309
33310
33311
33312
33313
33314
33315
33316
33317
33318
33319
33320
33321
33322
33323
33324
33325
33326
33327
33328
33329
33330
33331
33332
33333
33334
33335
33336
33337
33338
33339
33340
33341
33342
33343
33344
33345
33346
33347
33348
33349
33350
33351
33352
33353
33354
33355
33356
33357
33358
33359
33360
33361
33362
33363
33364
33365
33366
33367
33368
33369
33370
33371
33372
33373
33374
33375
33376
33377
33378
33379
33380
33381
33382
33383
33384
33385
33386
33387
33388
33389
33390
33391
33392
33393
33394
33395
33396
33397
33398
33399
33400
33401
33402
33403
33404
33405
33406
33407
33408
33409
33410
33411
33412
33413
33414
33415
33416
33417
33418
33419
33420
33421
33422
33423
33424
33425
33426
33427
33428
33429
33430
33431
33432
33433
33434
33435
33436
33437
33438
33439
33440
33441
33442
33443
33444
33445
33446
33447
33448
33449
33450
33451
33452
33453
33454
33455
33456
33457
33458
33459
33460
33461
33462
33463
33464
33465
33466
33467
33468
33469
33470
33471
33472
33473
33474
33475
33476
33477
33478
33479
33480
33481
33482
33483
33484
33485
33486
33487
33488
33489
33490
33491
33492
33493
33494
33495
33496
33497
33498
33499
33500
33501
33502
33503
33504
33505
33506
33507
33508
33509
33510
33511
33512
33513
33514
33515
33516
33517
33518
33519
33520
33521
33522
33523
33524
33525
33526
33527
33528
33529
33530
33531
33532
33533
33534
33535
33536
33537
33538
33539
33540
33541
33542
33543
33544
33545
33546
33547
33548
33549
33550
33551
33552
33553
33554
33555
33556
33557
33558
33559
33560
33561
33562
33563
33564
33565
33566
33567
33568
33569
33570
33571
33572
33573
33574
33575
33576
33577
33578
33579
33580
33581
33582
33583
33584
33585
33586
33587
33588
33589
33590
33591
33592
33593
33594
33595
33596
33597
33598
33599
33600
33601
33602
33603
33604
33605
33606
33607
33608
33609
33610
33611
33612
33613
33614
33615
33616
33617
33618
33619
33620
33621
33622
33623
33624
33625
33626
33627
33628
33629
33630
33631
33632
33633
33634
33635
33636
33637
33638
33639
33640
33641
33642
33643
33644
33645
33646
33647
33648
33649
33650
33651
33652
33653
33654
33655
33656
33657
33658
33659
33660
33661
33662
33663
33664
33665
33666
33667
33668
33669
33670
33671
33672
33673
33674
33675
33676
33677
33678
33679
33680
33681
33682
33683
33684
33685
33686
33687
33688
33689
33690
33691
33692
33693
33694
33695
33696
33697
33698
33699
33700
33701
33702
33703
33704
33705
33706
33707
33708
33709
33710
33711
33712
33713
33714
33715
33716
33717
33718
33719
33720
33721
33722
33723
33724
33725
33726
33727
33728
33729
33730
33731
33732
33733
33734
33735
33736
33737
33738
33739
33740
33741
33742
33743
33744
33745
33746
33747
33748
33749
33750
33751
33752
33753
33754
33755
33756
33757
33758
33759
33760
33761
33762
33763
33764
33765
33766
33767
33768
33769
33770
33771
33772
33773
33774
33775
33776
33777
33778
33779
33780
33781
33782
33783
33784
33785
33786
33787
33788
33789
33790
33791
33792
33793
33794
33795
33796
33797
33798
33799
33800
33801
33802
33803
33804
33805
33806
33807
33808
33809
33810
33811
33812
33813
33814
33815
33816
33817
33818
33819
33820
33821
33822
33823
33824
33825
33826
33827
33828
33829
33830
33831
33832
33833
33834
33835
33836
33837
33838
33839
33840
33841
33842
33843
33844
33845
33846
33847
33848
33849
33850
33851
33852
33853
33854
33855
33856
33857
33858
33859
33860
33861
33862
33863
33864
33865
33866
33867
33868
33869
33870
33871
33872
33873
33874
33875
33876
33877
33878
33879
33880
33881
33882
33883
33884
33885
33886
33887
33888
33889
33890
33891
33892
33893
33894
33895
33896
33897
33898
33899
33900
33901
33902
33903
33904
33905
33906
33907
33908
33909
33910
33911
33912
33913
33914
33915
33916
33917
33918
33919
33920
33921
33922
33923
33924
33925
33926
33927
33928
33929
33930
33931
33932
33933
33934
33935
33936
33937
33938
33939
33940
33941
33942
33943
33944
33945
33946
33947
33948
33949
33950
33951
33952
33953
33954
33955
33956
33957
33958
33959
33960
33961
33962
33963
33964
33965
33966
33967
33968
33969
33970
33971
33972
33973
33974
33975
33976
33977
33978
33979
33980
33981
33982
33983
33984
33985
33986
33987
33988
33989
33990
33991
33992
33993
33994
33995
33996
33997
33998
33999
34000
34001
34002
34003
34004
34005
34006
34007
34008
34009
34010
34011
34012
34013
34014
34015
34016
34017
34018
34019
34020
34021
34022
34023
34024
34025
34026
34027
34028
34029
34030
34031
34032
34033
34034
34035
34036
34037
34038
34039
34040
34041
34042
34043
34044
34045
34046
34047
34048
34049
34050
34051
34052
34053
34054
34055
34056
34057
34058
34059
34060
34061
34062
34063
34064
34065
34066
34067
34068
34069
34070
34071
34072
34073
34074
34075
34076
34077
34078
34079
34080
34081
34082
34083
34084
34085
34086
34087
34088
34089
34090
34091
34092
34093
34094
34095
34096
34097
34098
34099
34100
34101
34102
34103
34104
34105
34106
34107
34108
34109
34110
34111
34112
34113
34114
34115
34116
34117
34118
34119
34120
34121
34122
34123
34124
34125
34126
34127
34128
34129
34130
34131
34132
34133
34134
34135
34136
34137
34138
34139
34140
34141
34142
34143
34144
34145
34146
34147
34148
34149
34150
34151
34152
34153
34154
34155
34156
34157
34158
34159
34160
34161
34162
34163
34164
34165
34166
34167
34168
34169
34170
34171
34172
34173
34174
34175
34176
34177
34178
34179
34180
34181
34182
34183
34184
34185
34186
34187
34188
34189
34190
34191
34192
34193
34194
34195
34196
34197
34198
34199
34200
34201
34202
34203
34204
34205
34206
34207
34208
34209
34210
34211
34212
34213
34214
34215
34216
34217
34218
34219
34220
34221
34222
34223
34224
34225
34226
34227
34228
34229
34230
34231
34232
34233
34234
34235
34236
34237
34238
34239
34240
34241
34242
34243
34244
34245
34246
34247
34248
34249
34250
34251
34252
34253
34254
34255
34256
34257
34258
34259
34260
34261
34262
34263
34264
34265
34266
34267
34268
34269
34270
34271
34272
34273
34274
34275
34276
34277
34278
34279
34280
34281
34282
34283
34284
34285
34286
34287
34288
34289
34290
34291
34292
34293
34294
34295
34296
34297
34298
34299
34300
34301
34302
34303
34304
34305
34306
34307
34308
34309
34310
34311
34312
34313
34314
34315
34316
34317
34318
34319
34320
34321
34322
34323
34324
34325
34326
34327
34328
34329
34330
34331
34332
34333
34334
34335
34336
34337
34338
34339
34340
34341
34342
34343
34344
34345
34346
34347
34348
34349
34350
34351
34352
34353
34354
34355
34356
34357
34358
34359
34360
34361
34362
34363
34364
34365
34366
34367
34368
34369
34370
34371
34372
34373
34374
34375
34376
34377
34378
34379
34380
34381
34382
34383
34384
34385
34386
34387
34388
34389
34390
34391
34392
34393
34394
34395
34396
34397
34398
34399
34400
34401
34402
34403
34404
34405
34406
34407
34408
34409
34410
34411
34412
34413
34414
34415
34416
34417
34418
34419
34420
34421
34422
34423
34424
34425
34426
34427
34428
34429
34430
34431
34432
34433
34434
34435
34436
34437
34438
34439
34440
34441
34442
34443
34444
34445
34446
34447
34448
34449
34450
34451
34452
34453
34454
34455
34456
34457
34458
34459
34460
34461
34462
34463
34464
34465
34466
34467
34468
34469
34470
34471
34472
34473
34474
34475
34476
34477
34478
34479
34480
34481
34482
34483
34484
34485
34486
34487
34488
34489
34490
34491
34492
34493
34494
34495
34496
34497
34498
34499
34500
34501
34502
34503
34504
34505
34506
34507
34508
34509
34510
34511
34512
34513
34514
34515
34516
34517
34518
34519
34520
34521
34522
34523
34524
34525
34526
34527
34528
34529
34530
34531
34532
34533
34534
34535
34536
34537
34538
34539
34540
34541
34542
34543
34544
34545
34546
34547
34548
34549
34550
34551
34552
34553
34554
34555
34556
34557
34558
34559
34560
34561
34562
34563
34564
34565
34566
34567
34568
34569
34570
34571
34572
34573
34574
34575
34576
34577
34578
34579
34580
34581
34582
34583
34584
34585
34586
34587
34588
34589
34590
34591
34592
34593
34594
34595
34596
34597
34598
34599
34600
34601
34602
34603
34604
34605
34606
34607
34608
34609
34610
34611
34612
34613
34614
34615
34616
34617
34618
34619
34620
34621
34622
34623
34624
34625
34626
34627
34628
34629
34630
34631
34632
34633
34634
34635
34636
34637
34638
34639
34640
34641
34642
34643
34644
34645
34646
34647
34648
34649
34650
34651
34652
34653
34654
34655
34656
34657
34658
34659
34660
34661
34662
34663
34664
34665
34666
34667
34668
34669
34670
34671
34672
34673
34674
34675
34676
34677
34678
34679
34680
34681
34682
34683
34684
34685
34686
34687
34688
34689
34690
34691
34692
34693
34694
34695
34696
34697
34698
34699
34700
34701
34702
34703
34704
34705
34706
34707
34708
34709
34710
34711
34712
34713
34714
34715
34716
34717
34718
34719
34720
34721
34722
34723
34724
34725
34726
34727
34728
34729
34730
34731
34732
34733
34734
34735
34736
34737
34738
34739
34740
34741
34742
34743
34744
34745
34746
34747
34748
34749
34750
34751
34752
34753
34754
34755
34756
34757
34758
34759
34760
34761
34762
34763
34764
34765
34766
34767
34768
34769
34770
34771
34772
34773
34774
34775
34776
34777
34778
34779
34780
34781
34782
34783
34784
34785
34786
34787
34788
34789
34790
34791
34792
34793
34794
34795
34796
34797
34798
34799
34800
34801
34802
34803
34804
34805
34806
34807
34808
34809
34810
34811
34812
34813
34814
34815
34816
34817
34818
34819
34820
34821
34822
34823
34824
34825
34826
34827
34828
34829
34830
34831
34832
34833
34834
34835
34836
34837
34838
34839
34840
34841
34842
34843
34844
34845
34846
34847
34848
34849
34850
34851
34852
34853
34854
34855
34856
34857
34858
34859
34860
34861
34862
34863
34864
34865
34866
34867
34868
34869
34870
34871
34872
34873
34874
34875
34876
34877
34878
34879
34880
34881
34882
34883
34884
34885
34886
34887
34888
34889
34890
34891
34892
34893
34894
34895
34896
34897
34898
34899
34900
34901
34902
34903
34904
34905
34906
34907
34908
34909
34910
34911
34912
34913
34914
34915
34916
34917
34918
34919
34920
34921
34922
34923
34924
34925
34926
34927
34928
34929
34930
34931
34932
34933
34934
34935
34936
34937
34938
34939
34940
34941
34942
34943
34944
34945
34946
34947
34948
34949
34950
34951
34952
34953
34954
34955
34956
34957
34958
34959
34960
34961
34962
34963
34964
34965
34966
34967
34968
34969
34970
34971
34972
34973
34974
34975
34976
34977
34978
34979
34980
34981
34982
34983
34984
34985
34986
34987
34988
34989
34990
34991
34992
34993
34994
34995
34996
34997
34998
34999
35000
35001
35002
35003
35004
35005
35006
35007
35008
35009
35010
35011
35012
35013
35014
35015
35016
35017
35018
35019
35020
35021
35022
35023
35024
35025
35026
35027
35028
35029
35030
35031
35032
35033
35034
35035
35036
35037
35038
35039
35040
35041
35042
35043
35044
35045
35046
35047
35048
35049
35050
35051
35052
35053
35054
35055
35056
35057
35058
35059
35060
35061
35062
35063
35064
35065
35066
35067
35068
35069
35070
35071
35072
35073
35074
35075
35076
35077
35078
35079
35080
35081
35082
35083
35084
35085
35086
35087
35088
35089
35090
35091
35092
35093
35094
35095
35096
35097
35098
35099
35100
35101
35102
35103
35104
35105
35106
35107
35108
35109
35110
35111
35112
35113
35114
35115
35116
35117
35118
35119
35120
35121
35122
35123
35124
35125
35126
35127
35128
35129
35130
35131
35132
35133
35134
35135
35136
35137
35138
35139
35140
35141
35142
35143
35144
35145
35146
35147
35148
35149
35150
35151
35152
35153
35154
35155
35156
35157
35158
35159
35160
35161
35162
35163
35164
35165
35166
35167
35168
35169
35170
35171
35172
35173
35174
35175
35176
35177
35178
35179
35180
35181
35182
35183
35184
35185
35186
35187
35188
35189
35190
35191
35192
35193
35194
35195
35196
35197
35198
35199
35200
35201
35202
35203
35204
35205
35206
35207
35208
35209
35210
35211
35212
35213
35214
35215
35216
35217
35218
35219
35220
35221
35222
35223
35224
35225
35226
35227
35228
35229
35230
35231
35232
35233
35234
35235
35236
35237
35238
35239
35240
35241
35242
35243
35244
35245
35246
35247
35248
35249
35250
35251
35252
35253
35254
35255
35256
35257
35258
35259
35260
35261
35262
35263
35264
35265
35266
35267
35268
35269
35270
35271
35272
35273
35274
35275
35276
35277
35278
35279
35280
35281
35282
35283
35284
35285
35286
35287
35288
35289
35290
35291
35292
35293
35294
35295
35296
35297
35298
35299
35300
35301
35302
35303
35304
35305
35306
35307
35308
35309
35310
35311
35312
35313
35314
35315
35316
35317
35318
35319
35320
35321
35322
35323
35324
35325
35326
35327
35328
35329
35330
35331
35332
35333
35334
35335
35336
35337
35338
35339
35340
35341
35342
35343
35344
35345
35346
35347
35348
35349
35350
35351
35352
35353
35354
35355
35356
35357
35358
35359
35360
35361
35362
35363
35364
35365
35366
35367
35368
35369
35370
35371
35372
35373
35374
35375
35376
35377
35378
35379
35380
35381
35382
35383
35384
35385
35386
35387
35388
35389
35390
35391
35392
35393
35394
35395
35396
35397
35398
35399
35400
35401
35402
35403
35404
35405
35406
35407
35408
35409
35410
35411
35412
35413
35414
35415
35416
35417
35418
35419
35420
35421
35422
35423
35424
35425
35426
35427
35428
35429
35430
35431
35432
35433
35434
35435
35436
35437
35438
35439
35440
35441
35442
35443
35444
35445
35446
35447
35448
35449
35450
35451
35452
35453
35454
35455
35456
35457
35458
35459
35460
35461
35462
35463
35464
35465
35466
35467
35468
35469
35470
35471
35472
35473
35474
35475
35476
35477
35478
35479
35480
35481
35482
35483
35484
35485
35486
35487
35488
35489
35490
35491
35492
35493
35494
35495
35496
35497
35498
35499
35500
35501
35502
35503
35504
35505
35506
35507
35508
35509
35510
35511
35512
35513
35514
35515
35516
35517
35518
35519
35520
35521
35522
35523
35524
35525
35526
35527
35528
35529
35530
35531
35532
35533
35534
35535
35536
35537
35538
35539
35540
35541
35542
35543
35544
35545
35546
35547
35548
35549
35550
35551
35552
35553
35554
35555
35556
35557
35558
35559
35560
35561
35562
35563
35564
35565
35566
35567
35568
35569
35570
35571
35572
35573
35574
35575
35576
35577
35578
35579
35580
35581
35582
35583
35584
35585
35586
35587
35588
35589
35590
35591
35592
35593
35594
35595
35596
35597
35598
35599
35600
35601
35602
35603
35604
35605
35606
35607
35608
35609
35610
35611
35612
35613
35614
35615
35616
35617
35618
35619
35620
35621
35622
35623
35624
35625
35626
35627
35628
35629
35630
35631
35632
35633
35634
35635
35636
35637
35638
35639
35640
35641
35642
35643
35644
35645
35646
35647
35648
35649
35650
35651
35652
35653
35654
35655
35656
35657
35658
35659
35660
35661
35662
35663
35664
35665
35666
35667
35668
35669
35670
35671
35672
35673
35674
35675
35676
35677
35678
35679
35680
35681
35682
35683
35684
35685
35686
35687
35688
35689
35690
35691
35692
35693
35694
35695
35696
35697
35698
35699
35700
35701
35702
35703
35704
35705
35706
35707
35708
35709
35710
35711
35712
35713
35714
35715
35716
35717
35718
35719
35720
35721
35722
35723
35724
35725
35726
35727
35728
35729
35730
35731
35732
35733
35734
35735
35736
35737
35738
35739
35740
35741
35742
35743
35744
35745
35746
35747
35748
35749
35750
35751
35752
35753
35754
35755
35756
35757
35758
35759
35760
35761
35762
35763
35764
35765
35766
35767
35768
35769
35770
35771
35772
35773
35774
35775
35776
35777
35778
35779
35780
35781
35782
35783
35784
35785
35786
35787
35788
35789
35790
35791
35792
35793
35794
35795
35796
35797
35798
35799
35800
35801
35802
35803
35804
35805
35806
35807
35808
35809
35810
35811
35812
35813
35814
35815
35816
35817
35818
35819
35820
35821
35822
35823
35824
35825
35826
35827
35828
35829
35830
35831
35832
35833
35834
35835
35836
35837
35838
35839
35840
35841
35842
35843
35844
35845
35846
35847
35848
35849
35850
35851
35852
35853
35854
35855
35856
35857
35858
35859
35860
35861
35862
35863
35864
35865
35866
35867
35868
35869
35870
35871
35872
35873
35874
35875
35876
35877
35878
35879
35880
35881
35882
35883
35884
35885
35886
35887
35888
35889
35890
35891
35892
35893
35894
35895
35896
35897
35898
35899
35900
35901
35902
35903
35904
35905
35906
35907
35908
35909
35910
35911
35912
35913
35914
35915
35916
35917
35918
35919
35920
35921
35922
35923
35924
35925
35926
35927
35928
35929
35930
35931
35932
35933
35934
35935
35936
35937
35938
35939
35940
35941
35942
35943
35944
35945
35946
35947
35948
35949
35950
35951
35952
35953
35954
35955
35956
35957
35958
35959
35960
35961
35962
35963
35964
35965
35966
35967
35968
35969
35970
35971
35972
35973
35974
35975
35976
35977
35978
35979
35980
35981
35982
35983
35984
35985
35986
35987
35988
35989
35990
35991
35992
35993
35994
35995
35996
35997
35998
35999
36000
36001
36002
36003
36004
36005
36006
36007
36008
36009
36010
36011
36012
36013
36014
36015
36016
36017
36018
36019
36020
36021
36022
36023
36024
36025
36026
36027
36028
36029
36030
36031
36032
36033
36034
36035
36036
36037
36038
36039
36040
36041
36042
36043
36044
36045
36046
36047
36048
36049
36050
36051
36052
36053
36054
36055
36056
36057
36058
36059
36060
36061
36062
36063
36064
36065
36066
36067
36068
36069
36070
36071
36072
36073
36074
36075
36076
36077
36078
36079
36080
36081
36082
36083
36084
36085
36086
36087
36088
36089
36090
36091
36092
36093
36094
36095
36096
36097
36098
36099
36100
36101
36102
36103
36104
36105
36106
36107
36108
36109
36110
36111
36112
36113
36114
36115
36116
36117
36118
36119
36120
36121
36122
36123
36124
36125
36126
36127
36128
36129
36130
36131
36132
36133
36134
36135
36136
36137
36138
36139
36140
36141
36142
36143
36144
36145
36146
36147
36148
36149
36150
36151
36152
36153
36154
36155
36156
36157
36158
36159
36160
36161
36162
36163
36164
36165
36166
36167
36168
36169
36170
36171
36172
36173
36174
36175
36176
36177
36178
36179
36180
36181
36182
36183
36184
36185
36186
36187
36188
36189
36190
36191
36192
36193
36194
36195
36196
36197
36198
36199
36200
36201
36202
36203
36204
36205
36206
36207
36208
36209
36210
36211
36212
36213
36214
36215
36216
36217
36218
36219
36220
36221
36222
36223
36224
36225
36226
36227
36228
36229
36230
36231
36232
36233
36234
36235
36236
36237
36238
36239
36240
36241
36242
36243
36244
36245
36246
36247
36248
36249
36250
36251
36252
36253
36254
36255
36256
36257
36258
36259
36260
36261
36262
36263
36264
36265
36266
36267
36268
36269
36270
36271
36272
36273
36274
36275
36276
36277
36278
36279
36280
36281
36282
36283
36284
36285
36286
36287
36288
36289
36290
36291
36292
36293
36294
36295
36296
36297
36298
36299
36300
36301
36302
36303
36304
36305
36306
36307
36308
36309
36310
36311
36312
36313
36314
36315
36316
36317
36318
36319
36320
36321
36322
36323
36324
36325
36326
36327
36328
36329
36330
36331
36332
36333
36334
36335
36336
36337
36338
36339
36340
36341
36342
36343
36344
36345
36346
36347
36348
36349
36350
36351
36352
36353
36354
36355
36356
36357
36358
36359
36360
36361
36362
36363
36364
36365
36366
36367
36368
36369
36370
36371
36372
36373
36374
36375
36376
36377
36378
36379
36380
36381
36382
36383
36384
36385
36386
36387
36388
36389
36390
36391
36392
36393
36394
36395
36396
36397
36398
36399
36400
36401
36402
36403
36404
36405
36406
36407
36408
36409
36410
36411
36412
36413
36414
36415
36416
36417
36418
36419
36420
36421
36422
36423
36424
36425
36426
36427
36428
36429
36430
36431
36432
36433
36434
36435
36436
36437
36438
36439
36440
36441
36442
36443
36444
36445
36446
36447
36448
36449
36450
36451
36452
36453
36454
36455
36456
36457
36458
36459
36460
36461
36462
36463
36464
36465
36466
36467
36468
36469
36470
36471
36472
36473
36474
36475
36476
36477
36478
36479
36480
36481
36482
36483
36484
36485
36486
36487
36488
36489
36490
36491
36492
36493
36494
36495
36496
36497
36498
36499
36500
36501
36502
36503
36504
36505
36506
36507
36508
36509
36510
36511
36512
36513
36514
36515
36516
36517
36518
36519
36520
36521
36522
36523
36524
36525
36526
36527
36528
36529
36530
36531
36532
36533
36534
36535
36536
36537
36538
36539
36540
36541
36542
36543
36544
36545
36546
36547
36548
36549
36550
36551
36552
36553
36554
36555
36556
36557
36558
36559
36560
36561
36562
36563
36564
36565
36566
36567
36568
36569
36570
36571
36572
36573
36574
36575
36576
36577
36578
36579
36580
36581
36582
36583
36584
36585
36586
36587
36588
36589
36590
36591
36592
36593
36594
36595
36596
36597
36598
36599
36600
36601
36602
36603
36604
36605
36606
36607
36608
36609
36610
36611
36612
36613
36614
36615
36616
36617
36618
36619
36620
36621
36622
36623
36624
36625
36626
36627
36628
36629
36630
36631
36632
36633
36634
36635
36636
36637
36638
36639
36640
36641
36642
36643
36644
36645
36646
36647
36648
36649
36650
36651
36652
36653
36654
36655
36656
36657
36658
36659
36660
36661
36662
36663
36664
36665
36666
36667
36668
36669
36670
36671
36672
36673
36674
36675
36676
36677
36678
36679
36680
36681
36682
36683
36684
36685
36686
36687
36688
36689
36690
36691
36692
36693
36694
36695
36696
36697
36698
36699
36700
36701
36702
36703
36704
36705
36706
36707
36708
36709
36710
36711
36712
36713
36714
36715
36716
36717
36718
36719
36720
36721
36722
36723
36724
36725
36726
36727
36728
36729
36730
36731
36732
36733
36734
36735
36736
36737
36738
36739
36740
36741
36742
36743
36744
36745
36746
36747
36748
36749
36750
36751
36752
36753
36754
36755
36756
36757
36758
36759
36760
36761
36762
36763
36764
36765
36766
36767
36768
36769
36770
36771
36772
36773
36774
36775
36776
36777
36778
36779
36780
36781
36782
36783
36784
36785
36786
36787
36788
36789
36790
36791
36792
36793
36794
36795
36796
36797
36798
36799
36800
36801
36802
36803
36804
36805
36806
36807
36808
36809
36810
36811
36812
36813
36814
36815
36816
36817
36818
36819
36820
36821
36822
36823
36824
36825
36826
36827
36828
36829
36830
36831
36832
36833
36834
36835
36836
36837
36838
36839
36840
36841
36842
36843
36844
36845
36846
36847
36848
36849
36850
36851
36852
36853
36854
36855
36856
36857
36858
36859
36860
36861
36862
36863
36864
36865
36866
36867
36868
36869
36870
36871
36872
36873
36874
36875
36876
36877
36878
36879
36880
36881
36882
36883
36884
36885
36886
36887
36888
36889
36890
36891
36892
36893
36894
36895
36896
36897
36898
36899
36900
36901
36902
36903
36904
36905
36906
36907
36908
36909
36910
36911
36912
36913
36914
36915
36916
36917
36918
36919
36920
36921
36922
36923
36924
36925
36926
36927
36928
36929
36930
36931
36932
36933
36934
36935
36936
36937
36938
36939
36940
36941
36942
36943
36944
36945
36946
36947
36948
36949
36950
36951
36952
36953
36954
36955
36956
36957
36958
36959
36960
36961
36962
36963
36964
36965
36966
36967
36968
36969
36970
36971
36972
36973
36974
36975
36976
36977
36978
36979
36980
36981
36982
36983
36984
36985
36986
36987
36988
36989
36990
36991
36992
36993
36994
36995
36996
36997
36998
36999
37000
37001
37002
37003
37004
37005
37006
37007
37008
37009
37010
37011
37012
37013
37014
37015
37016
37017
37018
37019
37020
37021
37022
37023
37024
37025
37026
37027
37028
37029
37030
37031
37032
37033
37034
37035
37036
37037
37038
37039
37040
37041
37042
37043
37044
37045
37046
37047
37048
37049
37050
37051
37052
37053
37054
37055
37056
37057
37058
37059
37060
37061
37062
37063
37064
37065
37066
37067
37068
37069
37070
37071
37072
37073
37074
37075
37076
37077
37078
37079
37080
37081
37082
37083
37084
37085
37086
37087
37088
37089
37090
37091
37092
37093
37094
37095
37096
37097
37098
37099
37100
37101
37102
37103
37104
37105
37106
37107
37108
37109
37110
37111
37112
37113
37114
37115
37116
37117
37118
37119
37120
37121
37122
37123
37124
37125
37126
37127
37128
37129
37130
37131
37132
37133
37134
37135
37136
37137
37138
37139
37140
37141
37142
37143
37144
37145
37146
37147
37148
37149
37150
37151
37152
37153
37154
37155
37156
37157
37158
37159
37160
37161
37162
37163
37164
37165
37166
37167
37168
37169
37170
37171
37172
37173
37174
37175
37176
37177
37178
37179
37180
37181
37182
37183
37184
37185
37186
37187
37188
37189
37190
37191
37192
37193
37194
37195
37196
37197
37198
37199
37200
37201
37202
37203
37204
37205
37206
37207
37208
37209
37210
37211
37212
37213
37214
37215
37216
37217
37218
37219
37220
37221
37222
37223
37224
37225
37226
37227
37228
37229
37230
37231
37232
37233
37234
37235
37236
37237
37238
37239
37240
37241
37242
37243
37244
37245
37246
37247
37248
37249
37250
37251
37252
37253
37254
37255
37256
37257
37258
37259
37260
37261
37262
37263
37264
37265
37266
37267
37268
37269
37270
37271
37272
37273
37274
37275
37276
37277
37278
37279
37280
37281
37282
37283
37284
37285
37286
37287
37288
37289
37290
37291
37292
37293
37294
37295
37296
37297
37298
37299
37300
37301
37302
37303
37304
37305
37306
37307
37308
37309
37310
37311
37312
37313
37314
37315
37316
37317
37318
37319
37320
37321
37322
37323
37324
37325
37326
37327
37328
37329
37330
37331
37332
37333
37334
37335
37336
37337
37338
37339
37340
37341
37342
37343
37344
37345
37346
37347
37348
37349
37350
37351
37352
37353
37354
37355
37356
37357
37358
37359
37360
37361
37362
37363
37364
37365
37366
37367
37368
37369
37370
37371
37372
37373
37374
37375
37376
37377
37378
37379
37380
37381
37382
37383
37384
37385
37386
37387
37388
37389
37390
37391
37392
37393
37394
37395
37396
37397
37398
37399
37400
37401
37402
37403
37404
37405
37406
37407
37408
37409
37410
37411
37412
37413
37414
37415
37416
37417
37418
37419
37420
37421
37422
37423
37424
37425
37426
37427
37428
37429
37430
37431
37432
37433
37434
37435
37436
37437
37438
37439
37440
37441
37442
37443
37444
37445
37446
37447
37448
37449
37450
37451
37452
37453
37454
37455
37456
37457
37458
37459
37460
37461
37462
37463
37464
37465
37466
37467
37468
37469
37470
37471
37472
37473
37474
37475
37476
37477
37478
37479
37480
37481
37482
37483
37484
37485
37486
37487
37488
37489
37490
37491
37492
37493
37494
37495
37496
37497
37498
37499
37500
37501
37502
37503
37504
37505
37506
37507
37508
37509
37510
37511
37512
37513
37514
37515
37516
37517
37518
37519
37520
37521
37522
37523
37524
37525
37526
37527
37528
37529
37530
37531
37532
37533
37534
37535
37536
37537
37538
37539
37540
37541
37542
37543
37544
37545
37546
37547
37548
37549
37550
37551
37552
37553
37554
37555
37556
37557
37558
37559
37560
37561
37562
37563
37564
37565
37566
37567
37568
37569
37570
37571
37572
37573
37574
37575
37576
37577
37578
37579
37580
37581
37582
37583
37584
37585
37586
37587
37588
37589
37590
37591
37592
37593
37594
37595
37596
37597
37598
37599
37600
37601
37602
37603
37604
37605
37606
37607
37608
37609
37610
37611
37612
37613
37614
37615
37616
37617
37618
37619
37620
37621
37622
37623
37624
37625
37626
37627
37628
37629
37630
37631
37632
37633
37634
37635
37636
37637
37638
37639
37640
37641
37642
37643
37644
37645
37646
37647
37648
37649
37650
37651
37652
37653
37654
37655
37656
37657
37658
37659
37660
37661
37662
37663
37664
37665
37666
37667
37668
37669
37670
37671
37672
37673
37674
37675
37676
37677
37678
37679
37680
37681
37682
37683
37684
37685
37686
37687
37688
37689
37690
37691
37692
37693
37694
37695
37696
37697
37698
37699
37700
37701
37702
37703
37704
37705
37706
37707
37708
37709
37710
37711
37712
37713
37714
37715
37716
37717
37718
37719
37720
37721
37722
37723
37724
37725
37726
37727
37728
37729
37730
37731
37732
37733
37734
37735
37736
37737
37738
37739
37740
37741
37742
37743
37744
37745
37746
37747
37748
37749
37750
37751
37752
37753
37754
37755
37756
37757
37758
37759
37760
37761
37762
37763
37764
37765
37766
37767
37768
37769
37770
37771
37772
37773
37774
37775
37776
37777
37778
37779
37780
37781
37782
37783
37784
37785
37786
37787
37788
37789
37790
37791
37792
37793
37794
37795
37796
37797
37798
37799
37800
37801
37802
37803
37804
37805
37806
37807
37808
37809
37810
37811
37812
37813
37814
37815
37816
37817
37818
37819
37820
37821
37822
37823
37824
37825
37826
37827
37828
37829
37830
37831
37832
37833
37834
37835
37836
37837
37838
37839
37840
37841
37842
37843
37844
37845
37846
37847
37848
37849
37850
37851
37852
37853
37854
37855
37856
37857
37858
37859
37860
37861
37862
37863
37864
37865
37866
37867
37868
37869
37870
37871
37872
37873
37874
37875
37876
37877
37878
37879
37880
37881
37882
37883
37884
37885
37886
37887
37888
37889
37890
37891
37892
37893
37894
37895
37896
37897
37898
37899
37900
37901
37902
37903
37904
37905
37906
37907
37908
37909
37910
37911
37912
37913
37914
37915
37916
37917
37918
37919
37920
37921
37922
37923
37924
37925
37926
37927
37928
37929
37930
37931
37932
37933
37934
37935
37936
37937
37938
37939
37940
37941
37942
37943
37944
37945
37946
37947
37948
37949
37950
37951
37952
37953
37954
37955
37956
37957
37958
37959
37960
37961
37962
37963
37964
37965
37966
37967
37968
37969
37970
37971
37972
37973
37974
37975
37976
37977
37978
37979
37980
37981
37982
37983
37984
37985
37986
37987
37988
37989
37990
37991
37992
37993
37994
37995
37996
37997
37998
37999
38000
38001
38002
38003
38004
38005
38006
38007
38008
38009
38010
38011
38012
38013
38014
38015
38016
38017
38018
38019
38020
38021
38022
38023
38024
38025
38026
38027
38028
38029
38030
38031
38032
38033
38034
38035
38036
38037
38038
38039
38040
38041
38042
38043
38044
38045
38046
38047
38048
38049
38050
38051
38052
38053
38054
38055
38056
38057
38058
38059
38060
38061
38062
38063
38064
38065
38066
38067
38068
38069
38070
38071
38072
38073
38074
38075
38076
38077
38078
38079
38080
38081
38082
38083
38084
38085
38086
38087
38088
38089
38090
38091
38092
38093
38094
38095
38096
38097
38098
38099
38100
38101
38102
38103
38104
38105
38106
38107
38108
38109
38110
38111
38112
38113
38114
38115
38116
38117
38118
38119
38120
38121
38122
38123
38124
38125
38126
38127
38128
38129
38130
38131
38132
38133
38134
38135
38136
38137
38138
38139
38140
38141
38142
38143
38144
38145
38146
38147
38148
38149
38150
38151
38152
38153
38154
38155
38156
38157
38158
38159
38160
38161
38162
38163
38164
38165
38166
38167
38168
38169
38170
38171
38172
38173
38174
38175
38176
38177
38178
38179
38180
38181
38182
38183
38184
38185
38186
38187
38188
38189
38190
38191
38192
38193
38194
38195
38196
38197
38198
38199
38200
38201
38202
38203
38204
38205
38206
38207
38208
38209
38210
38211
38212
38213
38214
38215
38216
38217
38218
38219
38220
38221
38222
38223
38224
38225
38226
38227
38228
38229
38230
38231
38232
38233
38234
38235
38236
38237
38238
38239
38240
38241
38242
38243
38244
38245
38246
38247
38248
38249
38250
38251
38252
38253
38254
38255
38256
38257
38258
38259
38260
38261
38262
38263
38264
38265
38266
38267
38268
38269
38270
38271
38272
38273
38274
38275
38276
38277
38278
38279
38280
38281
38282
38283
38284
38285
38286
38287
38288
38289
38290
38291
38292
38293
38294
38295
38296
38297
38298
38299
38300
38301
38302
38303
38304
38305
38306
38307
38308
38309
38310
38311
38312
38313
38314
38315
38316
38317
38318
38319
38320
38321
38322
38323
38324
38325
38326
38327
38328
38329
38330
38331
38332
38333
38334
38335
38336
38337
38338
38339
38340
38341
38342
38343
38344
38345
38346
38347
38348
38349
38350
38351
38352
38353
38354
38355
38356
38357
38358
38359
38360
38361
38362
38363
38364
38365
38366
38367
38368
38369
38370
38371
38372
38373
38374
38375
38376
38377
38378
38379
38380
38381
38382
38383
38384
38385
38386
38387
38388
38389
38390
38391
38392
38393
38394
38395
38396
38397
38398
38399
38400
38401
38402
38403
38404
38405
38406
38407
38408
38409
38410
38411
38412
38413
38414
38415
38416
38417
38418
38419
38420
38421
38422
38423
38424
38425
38426
38427
38428
38429
38430
38431
38432
38433
38434
38435
38436
38437
38438
38439
38440
38441
38442
38443
38444
38445
38446
38447
38448
38449
38450
38451
38452
38453
38454
38455
38456
38457
38458
38459
38460
38461
38462
38463
38464
38465
38466
38467
38468
38469
38470
38471
38472
38473
38474
38475
38476
38477
38478
38479
38480
38481
38482
38483
38484
38485
38486
38487
38488
38489
38490
38491
38492
38493
38494
38495
38496
38497
38498
38499
38500
38501
38502
38503
38504
38505
38506
38507
38508
38509
38510
38511
38512
38513
38514
38515
38516
38517
38518
38519
38520
38521
38522
38523
38524
38525
38526
38527
38528
38529
38530
38531
38532
38533
38534
38535
38536
38537
38538
38539
38540
38541
38542
38543
38544
38545
38546
38547
38548
38549
38550
38551
38552
38553
38554
38555
38556
38557
38558
38559
38560
38561
38562
38563
38564
38565
38566
38567
38568
38569
38570
38571
38572
38573
38574
38575
38576
38577
38578
38579
38580
38581
38582
38583
38584
38585
38586
38587
38588
38589
38590
38591
38592
38593
38594
38595
38596
38597
38598
38599
38600
38601
38602
38603
38604
38605
38606
38607
38608
38609
38610
38611
38612
38613
38614
38615
38616
38617
38618
38619
38620
38621
38622
38623
38624
38625
38626
38627
38628
38629
38630
38631
38632
38633
38634
38635
38636
38637
38638
38639
38640
38641
38642
38643
38644
38645
38646
38647
38648
38649
38650
38651
38652
38653
38654
38655
38656
38657
38658
38659
38660
38661
38662
38663
38664
38665
38666
38667
38668
38669
38670
38671
38672
38673
38674
38675
38676
38677
38678
38679
38680
38681
38682
38683
38684
38685
38686
38687
38688
38689
38690
38691
38692
38693
38694
38695
38696
38697
38698
38699
38700
38701
38702
38703
38704
38705
38706
38707
38708
38709
38710
38711
38712
38713
38714
38715
38716
38717
38718
38719
38720
38721
38722
38723
38724
38725
38726
38727
38728
38729
38730
38731
38732
38733
38734
38735
38736
38737
38738
38739
38740
38741
38742
38743
38744
38745
38746
38747
38748
38749
38750
38751
38752
38753
38754
38755
38756
38757
38758
38759
38760
38761
38762
38763
38764
38765
38766
38767
38768
38769
38770
38771
38772
38773
38774
38775
38776
38777
38778
38779
38780
38781
38782
38783
38784
38785
38786
38787
38788
38789
38790
38791
38792
38793
38794
38795
38796
38797
38798
38799
38800
38801
38802
38803
38804
38805
38806
38807
38808
38809
38810
38811
38812
38813
38814
38815
38816
38817
38818
38819
38820
38821
38822
38823
38824
38825
38826
38827
38828
38829
38830
38831
38832
38833
38834
38835
38836
38837
38838
38839
38840
38841
38842
38843
38844
38845
38846
38847
38848
38849
38850
38851
38852
38853
38854
38855
38856
38857
38858
38859
38860
38861
38862
38863
38864
38865
38866
38867
38868
38869
38870
38871
38872
38873
38874
38875
38876
38877
38878
38879
38880
38881
38882
38883
38884
38885
38886
38887
38888
38889
38890
38891
38892
38893
38894
38895
38896
38897
38898
38899
38900
38901
38902
38903
38904
38905
38906
38907
38908
38909
38910
38911
38912
38913
38914
38915
38916
38917
38918
38919
38920
38921
38922
38923
38924
38925
38926
38927
38928
38929
38930
38931
38932
38933
38934
38935
38936
38937
38938
38939
38940
38941
38942
38943
38944
38945
38946
38947
38948
38949
38950
38951
38952
38953
38954
38955
38956
38957
38958
38959
38960
38961
38962
38963
38964
38965
38966
38967
38968
38969
38970
38971
38972
38973
38974
38975
38976
38977
38978
38979
38980
38981
38982
38983
38984
38985
38986
38987
38988
38989
38990
38991
38992
38993
38994
38995
38996
38997
38998
38999
39000
39001
39002
39003
39004
39005
39006
39007
39008
39009
39010
39011
39012
39013
39014
39015
39016
39017
39018
39019
39020
39021
39022
39023
39024
39025
39026
39027
39028
39029
39030
39031
39032
39033
39034
39035
39036
39037
39038
39039
39040
39041
39042
39043
39044
39045
39046
39047
39048
39049
39050
39051
39052
39053
39054
39055
39056
39057
39058
39059
39060
39061
39062
39063
39064
39065
39066
39067
39068
39069
39070
39071
39072
39073
39074
39075
39076
39077
39078
39079
39080
39081
39082
39083
39084
39085
39086
39087
39088
39089
39090
39091
39092
39093
39094
39095
39096
39097
39098
39099
39100
39101
39102
39103
39104
39105
39106
39107
39108
39109
39110
39111
39112
39113
39114
39115
39116
39117
39118
39119
39120
39121
39122
39123
39124
39125
39126
39127
39128
39129
39130
39131
39132
39133
39134
39135
39136
39137
39138
39139
39140
39141
39142
39143
39144
39145
39146
39147
39148
39149
39150
39151
39152
39153
39154
39155
39156
39157
39158
39159
39160
39161
39162
39163
39164
39165
39166
39167
39168
39169
39170
39171
39172
39173
39174
39175
39176
39177
39178
39179
39180
39181
39182
39183
39184
39185
39186
39187
39188
39189
39190
39191
39192
39193
39194
39195
39196
39197
39198
39199
39200
39201
39202
39203
39204
39205
39206
39207
39208
39209
39210
39211
39212
39213
39214
39215
39216
39217
39218
39219
39220
39221
39222
39223
39224
39225
39226
39227
39228
39229
39230
39231
39232
39233
39234
39235
39236
39237
39238
39239
39240
39241
39242
39243
39244
39245
39246
39247
39248
39249
39250
39251
39252
39253
39254
39255
39256
39257
39258
39259
39260
39261
39262
39263
39264
39265
39266
39267
39268
39269
39270
39271
39272
39273
39274
39275
39276
39277
39278
39279
39280
39281
39282
39283
39284
39285
39286
39287
39288
39289
39290
39291
39292
39293
39294
39295
39296
39297
39298
39299
39300
39301
39302
39303
39304
39305
39306
39307
39308
39309
39310
39311
39312
39313
39314
39315
39316
39317
39318
39319
39320
39321
39322
39323
39324
39325
39326
39327
39328
39329
39330
39331
39332
39333
39334
39335
39336
39337
39338
39339
39340
39341
39342
39343
39344
39345
39346
39347
39348
39349
39350
39351
39352
39353
39354
39355
39356
39357
39358
39359
39360
39361
39362
39363
39364
39365
39366
39367
39368
39369
39370
39371
39372
39373
39374
39375
39376
39377
39378
39379
39380
39381
39382
39383
39384
39385
39386
39387
39388
39389
39390
39391
39392
39393
39394
39395
39396
39397
39398
39399
39400
39401
39402
39403
39404
39405
39406
39407
39408
39409
39410
39411
39412
39413
39414
39415
39416
39417
39418
39419
39420
39421
39422
39423
39424
39425
39426
39427
39428
39429
39430
39431
39432
39433
39434
39435
39436
39437
39438
39439
39440
39441
39442
39443
39444
39445
39446
39447
39448
39449
39450
39451
39452
39453
39454
39455
39456
39457
39458
39459
39460
39461
39462
39463
39464
39465
39466
39467
39468
39469
39470
39471
39472
39473
39474
39475
39476
39477
39478
39479
39480
39481
39482
39483
39484
39485
39486
39487
39488
39489
39490
39491
39492
39493
39494
39495
39496
39497
39498
39499
39500
39501
39502
39503
39504
39505
39506
39507
39508
39509
39510
39511
39512
39513
39514
39515
39516
39517
39518
39519
39520
39521
39522
39523
39524
39525
39526
39527
39528
39529
39530
39531
39532
39533
39534
39535
39536
39537
39538
39539
39540
39541
39542
39543
39544
39545
39546
39547
39548
39549
39550
39551
39552
39553
39554
39555
39556
39557
39558
39559
39560
39561
39562
39563
39564
39565
39566
39567
39568
39569
39570
39571
39572
39573
39574
39575
39576
39577
39578
39579
39580
39581
39582
39583
39584
39585
39586
39587
39588
39589
39590
39591
39592
39593
39594
39595
39596
39597
39598
39599
39600
39601
39602
39603
39604
39605
39606
39607
39608
39609
39610
39611
39612
39613
39614
39615
39616
39617
39618
39619
39620
39621
39622
39623
39624
39625
39626
39627
39628
39629
39630
39631
39632
39633
39634
39635
39636
39637
39638
39639
39640
39641
39642
39643
39644
39645
39646
39647
39648
39649
39650
39651
39652
39653
39654
39655
39656
39657
39658
39659
39660
39661
39662
39663
39664
39665
39666
39667
39668
39669
39670
39671
39672
39673
39674
39675
39676
39677
39678
39679
39680
39681
39682
39683
39684
39685
39686
39687
39688
39689
39690
39691
39692
39693
39694
39695
39696
39697
39698
39699
39700
39701
39702
39703
39704
39705
39706
39707
39708
39709
39710
39711
39712
39713
39714
39715
39716
39717
39718
39719
39720
39721
39722
39723
39724
39725
39726
39727
39728
39729
39730
39731
39732
39733
39734
39735
39736
39737
39738
39739
39740
39741
39742
39743
39744
39745
39746
39747
39748
39749
39750
39751
39752
39753
39754
39755
39756
39757
39758
39759
39760
39761
39762
39763
39764
39765
39766
39767
39768
39769
39770
39771
39772
39773
39774
39775
39776
39777
39778
39779
39780
39781
39782
39783
39784
39785
39786
39787
39788
39789
39790
39791
39792
39793
39794
39795
39796
39797
39798
39799
39800
39801
39802
39803
39804
39805
39806
39807
39808
39809
39810
39811
39812
39813
39814
39815
39816
39817
39818
39819
39820
39821
39822
39823
39824
39825
39826
39827
39828
39829
39830
39831
39832
39833
39834
39835
39836
39837
39838
39839
39840
39841
39842
39843
39844
39845
39846
39847
39848
39849
39850
39851
39852
39853
39854
39855
39856
39857
39858
39859
39860
39861
39862
39863
39864
39865
39866
39867
39868
39869
39870
39871
39872
39873
39874
39875
39876
39877
39878
39879
39880
39881
39882
39883
39884
39885
39886
39887
39888
39889
39890
39891
39892
39893
39894
39895
39896
39897
39898
39899
39900
39901
39902
39903
39904
39905
39906
39907
39908
39909
39910
39911
39912
39913
39914
39915
39916
39917
39918
39919
39920
39921
39922
39923
39924
39925
39926
39927
39928
39929
39930
39931
39932
39933
39934
39935
39936
39937
39938
39939
39940
39941
39942
39943
39944
39945
39946
39947
39948
39949
39950
39951
39952
39953
39954
39955
39956
39957
39958
39959
39960
39961
39962
39963
39964
39965
39966
39967
39968
39969
39970
39971
39972
39973
39974
39975
39976
39977
39978
39979
39980
39981
39982
39983
39984
39985
39986
39987
39988
39989
39990
39991
39992
39993
39994
39995
39996
39997
39998
39999
40000
40001
40002
40003
40004
40005
40006
40007
40008
40009
40010
40011
40012
40013
40014
40015
40016
40017
40018
40019
40020
40021
40022
40023
40024
40025
40026
40027
40028
40029
40030
40031
40032
40033
40034
40035
40036
40037
40038
40039
40040
40041
40042
40043
40044
40045
40046
40047
40048
40049
40050
40051
40052
40053
40054
40055
40056
40057
40058
40059
40060
40061
40062
40063
40064
40065
40066
40067
40068
40069
40070
40071
40072
40073
40074
40075
40076
40077
40078
40079
40080
40081
40082
40083
40084
40085
40086
40087
40088
40089
40090
40091
40092
40093
40094
40095
40096
40097
40098
40099
40100
40101
40102
40103
40104
40105
40106
40107
40108
40109
40110
40111
40112
40113
40114
40115
40116
40117
40118
40119
40120
40121
40122
40123
40124
40125
40126
40127
40128
40129
40130
40131
40132
40133
40134
40135
40136
40137
40138
40139
40140
40141
40142
40143
40144
40145
40146
40147
40148
40149
40150
40151
40152
40153
40154
40155
40156
40157
40158
40159
40160
40161
40162
40163
40164
40165
40166
40167
40168
40169
40170
40171
40172
40173
40174
40175
40176
40177
40178
40179
40180
40181
40182
40183
40184
40185
40186
40187
40188
40189
40190
40191
40192
40193
40194
40195
40196
40197
40198
40199
40200
40201
40202
40203
40204
40205
40206
40207
40208
40209
40210
40211
40212
40213
40214
40215
40216
40217
40218
40219
40220
40221
40222
40223
40224
40225
40226
40227
40228
40229
40230
40231
40232
40233
40234
40235
40236
40237
40238
40239
40240
40241
40242
40243
40244
40245
40246
40247
40248
40249
40250
40251
40252
40253
40254
40255
40256
40257
40258
40259
40260
40261
40262
40263
40264
40265
40266
40267
40268
40269
40270
40271
40272
40273
40274
40275
40276
40277
40278
40279
40280
40281
40282
40283
40284
40285
40286
40287
40288
40289
40290
40291
40292
40293
40294
40295
40296
40297
40298
40299
40300
40301
40302
40303
40304
40305
40306
40307
40308
40309
40310
40311
40312
40313
40314
40315
40316
40317
40318
40319
40320
40321
40322
40323
40324
40325
40326
40327
40328
40329
40330
40331
40332
40333
40334
40335
40336
40337
40338
40339
40340
40341
40342
40343
40344
40345
40346
40347
40348
40349
40350
40351
40352
40353
40354
40355
40356
40357
40358
40359
40360
40361
40362
40363
40364
40365
40366
40367
40368
40369
40370
40371
40372
40373
40374
40375
40376
40377
40378
40379
40380
40381
40382
40383
40384
40385
40386
40387
40388
40389
40390
40391
40392
40393
40394
40395
40396
40397
40398
40399
40400
40401
40402
40403
40404
40405
40406
40407
40408
40409
40410
40411
40412
40413
40414
40415
40416
40417
40418
40419
40420
40421
40422
40423
40424
40425
40426
40427
40428
40429
40430
40431
40432
40433
40434
40435
40436
40437
40438
40439
40440
40441
40442
40443
40444
40445
40446
40447
40448
40449
40450
40451
40452
40453
40454
40455
40456
40457
40458
40459
40460
40461
40462
40463
40464
40465
40466
40467
40468
40469
40470
40471
40472
40473
40474
40475
40476
40477
40478
40479
40480
40481
40482
40483
40484
40485
40486
40487
40488
40489
40490
40491
40492
40493
40494
40495
40496
40497
40498
40499
40500
40501
40502
40503
40504
40505
40506
40507
40508
40509
40510
40511
40512
40513
40514
40515
40516
40517
40518
40519
40520
40521
40522
40523
40524
40525
40526
40527
40528
40529
40530
40531
40532
40533
40534
40535
40536
40537
40538
40539
40540
40541
40542
40543
40544
40545
40546
40547
40548
40549
40550
40551
40552
40553
40554
40555
40556
40557
40558
40559
40560
40561
40562
40563
40564
40565
40566
40567
40568
40569
40570
40571
40572
40573
40574
40575
40576
40577
40578
40579
40580
40581
40582
40583
40584
40585
40586
40587
40588
40589
40590
40591
40592
40593
40594
40595
40596
40597
40598
40599
40600
40601
40602
40603
40604
40605
40606
40607
40608
40609
40610
40611
40612
40613
40614
40615
40616
40617
40618
40619
40620
40621
40622
40623
40624
40625
40626
40627
40628
40629
40630
40631
40632
40633
40634
40635
40636
40637
40638
40639
40640
40641
40642
40643
40644
40645
40646
40647
40648
40649
40650
40651
40652
40653
40654
40655
40656
40657
40658
40659
40660
40661
40662
40663
40664
40665
40666
40667
40668
40669
40670
40671
40672
40673
40674
40675
40676
40677
40678
40679
40680
40681
40682
40683
40684
40685
40686
40687
40688
40689
40690
40691
40692
40693
40694
40695
40696
40697
40698
40699
40700
40701
40702
40703
40704
40705
40706
40707
40708
40709
40710
40711
40712
40713
40714
40715
40716
40717
40718
40719
40720
40721
40722
40723
40724
40725
40726
40727
40728
40729
40730
40731
40732
40733
40734
40735
40736
40737
40738
40739
40740
40741
40742
40743
40744
40745
40746
40747
40748
40749
40750
40751
40752
40753
40754
40755
40756
40757
40758
40759
40760
40761
40762
40763
40764
40765
40766
40767
40768
40769
40770
40771
40772
40773
40774
40775
40776
40777
40778
40779
40780
40781
40782
40783
40784
40785
40786
40787
40788
40789
40790
40791
40792
40793
40794
40795
40796
40797
40798
40799
40800
40801
40802
40803
40804
40805
40806
40807
40808
40809
40810
40811
40812
40813
40814
40815
40816
40817
40818
40819
40820
40821
40822
40823
40824
40825
40826
40827
40828
40829
40830
40831
40832
40833
40834
40835
40836
40837
40838
40839
40840
40841
40842
40843
40844
40845
40846
40847
40848
40849
40850
40851
40852
40853
40854
40855
40856
40857
40858
40859
40860
40861
40862
40863
40864
40865
40866
40867
40868
40869
40870
40871
40872
40873
40874
40875
40876
40877
40878
40879
40880
40881
40882
40883
40884
40885
40886
40887
40888
40889
40890
40891
40892
40893
40894
40895
40896
40897
40898
40899
40900
40901
40902
40903
40904
40905
40906
40907
40908
40909
40910
40911
40912
40913
40914
40915
40916
40917
40918
40919
40920
40921
40922
40923
40924
40925
40926
40927
40928
40929
40930
40931
40932
40933
40934
40935
40936
40937
40938
40939
40940
40941
40942
40943
40944
40945
40946
40947
40948
40949
40950
40951
40952
40953
40954
40955
40956
40957
40958
40959
40960
40961
40962
40963
40964
40965
40966
40967
40968
40969
40970
40971
40972
40973
40974
40975
40976
40977
40978
40979
40980
40981
40982
40983
40984
40985
40986
40987
40988
40989
40990
40991
40992
40993
40994
40995
40996
40997
40998
40999
41000
41001
41002
41003
41004
41005
41006
41007
41008
41009
41010
41011
41012
41013
41014
41015
41016
41017
41018
41019
41020
41021
41022
41023
41024
41025
41026
41027
41028
41029
41030
41031
41032
41033
41034
41035
41036
41037
41038
41039
41040
41041
41042
41043
41044
41045
41046
41047
41048
41049
41050
41051
41052
41053
41054
41055
41056
41057
41058
41059
41060
41061
41062
41063
41064
41065
41066
41067
41068
41069
41070
41071
41072
41073
41074
41075
41076
41077
41078
41079
41080
41081
41082
41083
41084
41085
41086
41087
41088
41089
41090
41091
41092
41093
41094
41095
41096
41097
41098
41099
41100
41101
41102
41103
41104
41105
41106
41107
41108
41109
41110
41111
41112
41113
41114
41115
41116
41117
41118
41119
41120
41121
41122
41123
41124
41125
41126
41127
41128
41129
41130
41131
41132
41133
41134
41135
41136
41137
41138
41139
41140
41141
41142
41143
41144
41145
41146
41147
41148
41149
41150
41151
41152
41153
41154
41155
41156
41157
41158
41159
41160
41161
41162
41163
41164
41165
41166
41167
41168
41169
41170
41171
41172
41173
41174
41175
41176
41177
41178
41179
41180
41181
41182
41183
41184
41185
41186
41187
41188
41189
41190
41191
41192
41193
41194
41195
41196
41197
41198
41199
41200
41201
41202
41203
41204
41205
41206
41207
41208
41209
41210
41211
41212
41213
41214
41215
41216
41217
41218
41219
41220
41221
41222
41223
41224
41225
41226
41227
41228
41229
41230
41231
41232
41233
41234
41235
41236
41237
41238
41239
41240
41241
41242
41243
41244
41245
41246
41247
41248
41249
41250
41251
41252
41253
41254
41255
41256
41257
41258
41259
41260
41261
41262
41263
41264
41265
41266
41267
41268
41269
41270
41271
41272
41273
41274
41275
41276
41277
41278
41279
41280
41281
41282
41283
41284
41285
41286
41287
41288
41289
41290
41291
41292
41293
41294
41295
41296
41297
41298
41299
41300
41301
41302
41303
41304
41305
41306
41307
41308
41309
41310
41311
41312
41313
41314
41315
41316
41317
41318
41319
41320
41321
41322
41323
41324
41325
41326
41327
41328
41329
41330
41331
41332
41333
41334
41335
41336
41337
41338
41339
41340
41341
41342
41343
41344
41345
41346
41347
41348
41349
41350
41351
41352
41353
41354
41355
41356
41357
41358
41359
41360
41361
41362
41363
41364
41365
41366
41367
41368
41369
41370
41371
41372
41373
41374
41375
41376
41377
41378
41379
41380
41381
41382
41383
41384
41385
41386
41387
41388
41389
41390
41391
41392
41393
41394
41395
41396
41397
41398
41399
41400
41401
41402
41403
41404
41405
41406
41407
41408
41409
41410
41411
41412
41413
41414
41415
41416
41417
41418
41419
41420
41421
41422
41423
41424
41425
41426
41427
41428
41429
41430
41431
41432
41433
41434
41435
41436
41437
41438
41439
41440
41441
41442
41443
41444
41445
41446
41447
41448
41449
41450
41451
41452
41453
41454
41455
41456
41457
41458
41459
41460
41461
41462
41463
41464
41465
41466
41467
41468
41469
41470
41471
41472
41473
41474
41475
41476
41477
41478
41479
41480
41481
41482
41483
41484
41485
41486
41487
41488
41489
41490
41491
41492
41493
41494
41495
41496
41497
41498
41499
41500
41501
41502
41503
41504
41505
41506
41507
41508
41509
41510
41511
41512
41513
41514
41515
41516
41517
41518
41519
41520
41521
41522
41523
41524
41525
41526
41527
41528
41529
41530
41531
41532
41533
41534
41535
41536
41537
41538
41539
41540
41541
41542
41543
41544
41545
41546
41547
41548
41549
41550
41551
41552
41553
41554
41555
41556
41557
41558
41559
41560
41561
41562
41563
41564
41565
41566
41567
41568
41569
41570
41571
41572
41573
41574
41575
41576
41577
41578
41579
41580
41581
41582
41583
41584
41585
41586
41587
41588
41589
41590
41591
41592
41593
41594
41595
41596
41597
41598
41599
41600
41601
41602
41603
41604
41605
41606
41607
41608
41609
41610
41611
41612
41613
41614
41615
41616
41617
41618
41619
41620
41621
41622
41623
41624
41625
41626
41627
41628
41629
41630
41631
41632
41633
41634
41635
41636
41637
41638
41639
41640
41641
41642
41643
41644
41645
41646
41647
41648
41649
41650
41651
41652
41653
41654
41655
41656
41657
41658
41659
41660
41661
41662
41663
41664
41665
41666
41667
41668
41669
41670
41671
41672
41673
41674
41675
41676
41677
41678
41679
41680
41681
41682
41683
41684
41685
41686
41687
41688
41689
41690
41691
41692
41693
41694
41695
41696
41697
41698
41699
41700
41701
41702
41703
41704
41705
41706
41707
41708
41709
41710
41711
41712
41713
41714
41715
41716
41717
41718
41719
41720
41721
41722
41723
41724
41725
41726
41727
41728
41729
41730
41731
41732
41733
41734
41735
41736
41737
41738
41739
41740
41741
41742
41743
41744
41745
41746
41747
41748
41749
41750
41751
41752
41753
41754
41755
41756
41757
41758
41759
41760
41761
41762
41763
41764
41765
41766
41767
41768
41769
41770
41771
41772
41773
41774
41775
41776
41777
41778
41779
41780
41781
41782
41783
41784
41785
41786
41787
41788
41789
41790
41791
41792
41793
41794
41795
41796
41797
41798
41799
41800
41801
41802
41803
41804
41805
41806
41807
41808
41809
41810
41811
41812
41813
41814
41815
41816
41817
41818
41819
41820
41821
41822
41823
41824
41825
41826
41827
41828
41829
41830
41831
41832
41833
41834
41835
41836
41837
41838
41839
41840
41841
41842
41843
41844
41845
41846
41847
41848
41849
41850
41851
41852
41853
41854
41855
41856
41857
41858
41859
41860
41861
41862
41863
41864
41865
41866
41867
41868
41869
41870
41871
41872
41873
41874
41875
41876
41877
41878
41879
41880
41881
41882
41883
41884
41885
41886
41887
41888
41889
41890
41891
41892
41893
41894
41895
41896
41897
41898
41899
41900
41901
41902
41903
41904
41905
41906
41907
41908
41909
41910
41911
41912
41913
41914
41915
41916
41917
41918
41919
41920
41921
41922
41923
41924
41925
41926
41927
41928
41929
41930
41931
41932
41933
41934
41935
41936
41937
41938
41939
41940
41941
41942
41943
41944
41945
41946
41947
41948
41949
41950
41951
41952
41953
41954
41955
41956
41957
41958
41959
41960
41961
41962
41963
41964
41965
41966
41967
41968
41969
41970
41971
41972
41973
41974
41975
41976
41977
41978
41979
41980
41981
41982
41983
41984
41985
41986
41987
41988
41989
41990
41991
41992
41993
41994
41995
41996
41997
41998
41999
42000
42001
42002
42003
42004
42005
42006
42007
42008
42009
42010
42011
42012
42013
42014
42015
42016
42017
42018
42019
42020
42021
42022
42023
42024
42025
42026
42027
42028
42029
42030
42031
42032
42033
42034
42035
42036
42037
42038
42039
42040
42041
42042
42043
42044
42045
42046
42047
42048
42049
42050
42051
42052
42053
42054
42055
42056
42057
42058
42059
42060
42061
42062
42063
42064
42065
42066
42067
42068
42069
42070
42071
42072
42073
42074
42075
42076
42077
42078
42079
42080
42081
42082
42083
42084
42085
42086
42087
42088
42089
42090
42091
42092
42093
42094
42095
42096
42097
42098
42099
42100
42101
42102
42103
42104
42105
42106
42107
42108
42109
42110
42111
42112
42113
42114
42115
42116
42117
42118
42119
42120
42121
42122
42123
42124
42125
42126
42127
42128
42129
42130
42131
42132
42133
42134
42135
42136
42137
42138
42139
42140
42141
42142
42143
42144
42145
42146
42147
42148
42149
42150
42151
42152
42153
42154
42155
42156
42157
42158
42159
42160
42161
42162
42163
42164
42165
42166
42167
42168
42169
42170
42171
42172
42173
42174
42175
42176
42177
42178
42179
42180
42181
42182
42183
42184
42185
42186
42187
42188
42189
42190
42191
42192
42193
42194
42195
42196
42197
42198
42199
42200
42201
42202
42203
42204
42205
42206
42207
42208
42209
42210
42211
42212
42213
42214
42215
42216
42217
42218
42219
42220
42221
42222
42223
42224
42225
42226
42227
42228
42229
42230
42231
42232
42233
42234
42235
42236
42237
42238
42239
42240
42241
42242
42243
42244
42245
42246
42247
42248
42249
42250
42251
42252
42253
42254
42255
42256
42257
42258
42259
42260
42261
42262
42263
42264
42265
42266
42267
42268
42269
42270
42271
42272
42273
42274
42275
42276
42277
42278
42279
42280
42281
42282
42283
42284
42285
42286
42287
42288
42289
42290
42291
42292
42293
42294
42295
42296
42297
42298
42299
42300
42301
42302
42303
42304
42305
42306
42307
42308
42309
42310
42311
42312
42313
42314
42315
42316
42317
42318
42319
42320
42321
42322
42323
42324
42325
42326
42327
42328
42329
42330
42331
42332
42333
42334
42335
42336
42337
42338
42339
42340
42341
42342
42343
42344
42345
42346
42347
42348
42349
42350
42351
42352
42353
42354
42355
42356
42357
42358
42359
42360
42361
42362
42363
42364
42365
42366
42367
42368
42369
42370
42371
42372
42373
42374
42375
42376
42377
42378
42379
42380
42381
42382
42383
42384
42385
42386
42387
42388
42389
42390
42391
42392
42393
42394
42395
42396
42397
42398
42399
42400
42401
42402
42403
42404
42405
42406
42407
42408
42409
42410
42411
42412
42413
42414
42415
42416
42417
42418
42419
42420
42421
42422
42423
42424
42425
42426
42427
42428
42429
42430
42431
42432
42433
42434
42435
42436
42437
42438
42439
42440
42441
42442
42443
42444
42445
42446
42447
42448
42449
42450
42451
42452
42453
42454
42455
42456
42457
42458
42459
42460
42461
42462
42463
42464
42465
42466
42467
42468
42469
42470
42471
42472
42473
42474
42475
42476
42477
42478
42479
42480
42481
42482
42483
42484
42485
42486
42487
42488
42489
42490
42491
42492
42493
42494
42495
42496
42497
42498
42499
42500
42501
42502
42503
42504
42505
42506
42507
42508
42509
42510
42511
42512
42513
42514
42515
42516
42517
42518
42519
42520
42521
42522
42523
42524
42525
42526
42527
42528
42529
42530
42531
42532
42533
42534
42535
42536
42537
42538
42539
42540
42541
42542
42543
42544
42545
42546
42547
42548
42549
42550
42551
42552
42553
42554
42555
42556
42557
42558
42559
42560
42561
42562
42563
42564
42565
42566
42567
42568
42569
42570
42571
42572
42573
42574
42575
42576
42577
42578
42579
42580
42581
42582
42583
42584
42585
42586
42587
42588
42589
42590
42591
42592
42593
42594
42595
42596
42597
42598
42599
42600
42601
42602
42603
42604
42605
42606
42607
42608
42609
42610
42611
42612
42613
42614
42615
42616
42617
42618
42619
42620
42621
42622
42623
42624
42625
42626
42627
42628
42629
42630
42631
42632
42633
42634
42635
42636
42637
42638
42639
42640
42641
42642
42643
42644
42645
42646
42647
42648
42649
42650
42651
42652
42653
42654
42655
42656
42657
42658
42659
42660
42661
42662
42663
42664
42665
42666
42667
42668
42669
42670
42671
42672
42673
42674
42675
42676
42677
42678
42679
42680
42681
42682
42683
42684
42685
42686
42687
42688
42689
42690
42691
42692
42693
42694
42695
42696
42697
42698
42699
42700
42701
42702
42703
42704
42705
42706
42707
42708
42709
42710
42711
42712
42713
42714
42715
42716
42717
42718
42719
42720
42721
42722
42723
42724
42725
42726
42727
42728
42729
42730
42731
42732
42733
42734
42735
42736
42737
42738
42739
42740
42741
42742
42743
42744
42745
42746
42747
42748
42749
42750
42751
42752
42753
42754
42755
42756
42757
42758
42759
42760
42761
42762
42763
42764
42765
42766
42767
42768
42769
42770
42771
42772
42773
42774
42775
42776
42777
42778
42779
42780
42781
42782
42783
42784
42785
42786
42787
42788
42789
42790
42791
42792
42793
42794
42795
42796
42797
42798
42799
42800
42801
42802
42803
42804
42805
42806
42807
42808
42809
42810
42811
42812
42813
42814
42815
42816
42817
42818
42819
42820
42821
42822
42823
42824
42825
42826
42827
42828
42829
42830
42831
42832
42833
42834
42835
42836
42837
42838
42839
42840
42841
42842
42843
42844
42845
42846
42847
42848
42849
42850
42851
42852
42853
42854
42855
42856
42857
42858
42859
42860
42861
42862
42863
42864
42865
42866
42867
42868
42869
42870
42871
42872
42873
42874
42875
42876
42877
42878
42879
42880
42881
42882
42883
42884
42885
42886
42887
42888
42889
42890
42891
42892
42893
42894
42895
42896
42897
42898
42899
42900
42901
42902
42903
42904
42905
42906
42907
42908
42909
42910
42911
42912
42913
42914
42915
42916
42917
42918
42919
42920
42921
42922
42923
42924
42925
42926
42927
42928
42929
42930
42931
42932
42933
42934
42935
42936
42937
42938
42939
42940
42941
42942
42943
42944
42945
42946
42947
42948
42949
42950
42951
42952
42953
42954
42955
42956
42957
42958
42959
42960
42961
42962
42963
42964
42965
42966
42967
42968
42969
42970
42971
42972
42973
42974
42975
42976
42977
42978
42979
42980
42981
42982
42983
42984
42985
42986
42987
42988
42989
42990
42991
42992
42993
42994
42995
42996
42997
42998
42999
43000
43001
43002
43003
43004
43005
43006
43007
43008
43009
43010
43011
43012
43013
43014
43015
43016
43017
43018
43019
43020
43021
43022
43023
43024
43025
43026
43027
43028
43029
43030
43031
43032
43033
43034
43035
43036
43037
43038
43039
43040
43041
43042
43043
43044
43045
43046
43047
43048
43049
43050
43051
43052
43053
43054
43055
43056
43057
43058
43059
43060
43061
43062
43063
43064
43065
43066
43067
43068
43069
43070
43071
43072
43073
43074
43075
43076
43077
43078
43079
43080
43081
43082
43083
43084
43085
43086
43087
43088
43089
43090
43091
43092
43093
43094
43095
43096
43097
43098
43099
43100
43101
43102
43103
43104
43105
43106
43107
43108
43109
43110
43111
43112
43113
43114
43115
43116
43117
43118
43119
43120
43121
43122
43123
43124
43125
43126
43127
43128
43129
43130
43131
43132
43133
43134
43135
43136
43137
43138
43139
43140
43141
43142
43143
43144
43145
43146
43147
43148
43149
43150
43151
43152
43153
43154
43155
43156
43157
43158
43159
43160
43161
43162
43163
43164
43165
43166
43167
43168
43169
43170
43171
43172
43173
43174
43175
43176
43177
43178
43179
43180
43181
43182
43183
43184
43185
43186
43187
43188
43189
43190
43191
43192
43193
43194
43195
43196
43197
43198
43199
43200
43201
43202
43203
43204
43205
43206
43207
43208
43209
43210
43211
43212
43213
43214
43215
43216
43217
43218
43219
43220
43221
43222
43223
43224
43225
43226
43227
43228
43229
43230
43231
43232
43233
43234
43235
43236
43237
43238
43239
43240
43241
43242
43243
43244
43245
43246
43247
43248
43249
43250
43251
43252
43253
43254
43255
43256
43257
43258
43259
43260
43261
43262
43263
43264
43265
43266
43267
43268
43269
43270
43271
43272
43273
43274
43275
43276
43277
43278
43279
43280
43281
43282
43283
43284
43285
43286
43287
43288
43289
43290
43291
43292
43293
43294
43295
43296
43297
43298
43299
43300
43301
43302
43303
43304
43305
43306
43307
43308
43309
43310
43311
43312
43313
43314
43315
43316
43317
43318
43319
43320
43321
43322
43323
43324
43325
43326
43327
43328
43329
43330
43331
43332
43333
43334
43335
43336
43337
43338
43339
43340
43341
43342
43343
43344
43345
43346
43347
43348
43349
43350
43351
43352
43353
43354
43355
43356
43357
43358
43359
43360
43361
43362
43363
43364
43365
43366
43367
43368
43369
43370
43371
43372
43373
43374
43375
43376
43377
43378
43379
43380
43381
43382
43383
43384
43385
43386
43387
43388
43389
43390
43391
43392
43393
43394
43395
43396
43397
43398
43399
43400
43401
43402
43403
43404
43405
43406
43407
43408
43409
43410
43411
43412
43413
43414
43415
43416
43417
43418
43419
43420
43421
43422
43423
43424
43425
43426
43427
43428
43429
43430
43431
43432
43433
43434
43435
43436
43437
43438
43439
43440
43441
43442
43443
43444
43445
43446
43447
43448
43449
43450
43451
43452
43453
43454
43455
43456
43457
43458
43459
43460
43461
43462
43463
43464
43465
43466
43467
43468
43469
43470
43471
43472
43473
43474
43475
43476
43477
43478
43479
43480
43481
43482
43483
43484
43485
43486
43487
43488
43489
43490
43491
43492
43493
43494
43495
43496
43497
43498
43499
43500
43501
43502
43503
43504
43505
43506
43507
43508
43509
43510
43511
43512
43513
43514
43515
43516
43517
43518
43519
43520
43521
43522
43523
43524
43525
43526
43527
43528
43529
43530
43531
43532
43533
43534
43535
43536
43537
43538
43539
43540
43541
43542
43543
43544
43545
43546
43547
43548
43549
43550
43551
43552
43553
43554
43555
43556
43557
43558
43559
43560
43561
43562
43563
43564
43565
43566
43567
43568
43569
43570
43571
43572
43573
43574
43575
43576
43577
43578
43579
43580
43581
43582
43583
43584
43585
43586
43587
43588
43589
43590
43591
43592
43593
43594
43595
43596
43597
43598
43599
43600
43601
43602
43603
43604
43605
43606
43607
43608
43609
43610
43611
43612
43613
43614
43615
43616
43617
43618
43619
43620
43621
43622
43623
43624
43625
43626
43627
43628
43629
43630
43631
43632
43633
43634
43635
43636
43637
43638
43639
43640
43641
43642
43643
43644
43645
43646
43647
43648
43649
43650
43651
43652
43653
43654
43655
43656
43657
43658
43659
43660
43661
43662
43663
43664
43665
43666
43667
43668
43669
43670
43671
43672
43673
43674
43675
43676
43677
43678
43679
43680
43681
43682
43683
43684
43685
43686
43687
43688
43689
43690
43691
43692
43693
43694
43695
43696
43697
43698
43699
43700
43701
43702
43703
43704
43705
43706
43707
43708
43709
43710
43711
43712
43713
43714
43715
43716
43717
43718
43719
43720
43721
43722
43723
43724
43725
43726
43727
43728
43729
43730
43731
43732
43733
43734
43735
43736
43737
43738
43739
43740
43741
43742
43743
43744
43745
43746
43747
43748
43749
43750
43751
43752
43753
43754
43755
43756
43757
43758
43759
43760
43761
43762
43763
43764
43765
43766
43767
43768
43769
43770
43771
43772
43773
43774
43775
43776
43777
43778
43779
43780
43781
43782
43783
43784
43785
43786
43787
43788
43789
43790
43791
43792
43793
43794
43795
43796
43797
43798
43799
43800
43801
43802
43803
43804
43805
43806
43807
43808
43809
43810
43811
43812
43813
43814
43815
43816
43817
43818
43819
43820
43821
43822
43823
43824
43825
43826
43827
43828
43829
43830
43831
43832
43833
43834
43835
43836
43837
43838
43839
43840
43841
43842
43843
43844
43845
43846
43847
43848
43849
43850
43851
43852
43853
43854
43855
43856
43857
43858
43859
43860
43861
43862
43863
43864
43865
43866
43867
43868
43869
43870
43871
43872
43873
43874
43875
43876
43877
43878
43879
43880
43881
43882
43883
43884
43885
43886
43887
43888
43889
43890
43891
43892
43893
43894
43895
43896
43897
43898
43899
43900
43901
43902
43903
43904
43905
43906
43907
43908
43909
43910
43911
43912
43913
43914
43915
43916
43917
43918
43919
43920
43921
43922
43923
43924
43925
43926
43927
43928
43929
43930
43931
43932
43933
43934
43935
43936
43937
43938
43939
43940
43941
43942
43943
43944
43945
43946
43947
43948
43949
43950
43951
43952
43953
43954
43955
43956
43957
43958
43959
43960
43961
43962
43963
43964
43965
43966
43967
43968
43969
43970
43971
43972
43973
43974
43975
43976
43977
43978
43979
43980
43981
43982
43983
43984
43985
43986
43987
43988
43989
43990
43991
43992
43993
43994
43995
43996
43997
43998
43999
44000
44001
44002
44003
44004
44005
44006
44007
44008
44009
44010
44011
44012
44013
44014
44015
44016
44017
44018
44019
44020
44021
44022
44023
44024
44025
44026
44027
44028
44029
44030
44031
44032
44033
44034
44035
44036
44037
44038
44039
44040
44041
44042
44043
44044
44045
44046
44047
44048
44049
44050
44051
44052
44053
44054
44055
44056
44057
44058
44059
44060
44061
44062
44063
44064
44065
44066
44067
44068
44069
44070
44071
44072
44073
44074
44075
44076
44077
44078
44079
44080
44081
44082
44083
44084
44085
44086
44087
44088
44089
44090
44091
44092
44093
44094
44095
44096
44097
44098
44099
44100
44101
44102
44103
44104
44105
44106
44107
44108
44109
44110
44111
44112
44113
44114
44115
44116
44117
44118
44119
44120
44121
44122
44123
44124
44125
44126
44127
44128
44129
44130
44131
44132
44133
44134
44135
44136
44137
44138
44139
44140
44141
44142
44143
44144
44145
44146
44147
44148
44149
44150
44151
44152
44153
44154
44155
44156
44157
44158
44159
44160
44161
44162
44163
44164
44165
44166
44167
44168
44169
44170
44171
44172
44173
44174
44175
44176
44177
44178
44179
44180
44181
44182
44183
44184
44185
44186
44187
44188
44189
44190
44191
44192
44193
44194
44195
44196
44197
44198
44199
44200
44201
44202
44203
44204
44205
44206
44207
44208
44209
44210
44211
44212
44213
44214
44215
44216
44217
44218
44219
44220
44221
44222
44223
44224
44225
44226
44227
44228
44229
44230
44231
44232
44233
44234
44235
44236
44237
44238
44239
44240
44241
44242
44243
44244
44245
44246
44247
44248
44249
44250
44251
44252
44253
44254
44255
44256
44257
44258
44259
44260
44261
44262
44263
44264
44265
44266
44267
44268
44269
44270
44271
44272
44273
44274
44275
44276
44277
44278
44279
44280
44281
44282
44283
44284
44285
44286
44287
44288
44289
44290
44291
44292
44293
44294
44295
44296
44297
44298
44299
44300
44301
44302
44303
44304
44305
44306
44307
44308
44309
44310
44311
44312
44313
44314
44315
44316
44317
44318
44319
44320
44321
44322
44323
44324
44325
44326
44327
44328
44329
44330
44331
44332
44333
44334
44335
44336
44337
44338
44339
44340
44341
44342
44343
44344
44345
44346
44347
44348
44349
44350
44351
44352
44353
44354
44355
44356
44357
44358
44359
44360
44361
44362
44363
44364
44365
44366
44367
44368
44369
44370
44371
44372
44373
44374
44375
44376
44377
44378
44379
44380
44381
44382
44383
44384
44385
44386
44387
44388
44389
44390
44391
44392
44393
44394
44395
44396
44397
44398
44399
44400
44401
44402
44403
44404
44405
44406
44407
44408
44409
44410
44411
44412
44413
44414
44415
44416
44417
44418
44419
44420
44421
44422
44423
44424
44425
44426
44427
44428
44429
44430
44431
44432
44433
44434
44435
44436
44437
44438
44439
44440
44441
44442
44443
44444
44445
44446
44447
44448
44449
44450
44451
44452
44453
44454
44455
44456
44457
44458
44459
44460
44461
44462
44463
44464
44465
44466
44467
44468
44469
44470
44471
44472
44473
44474
44475
44476
44477
44478
44479
44480
44481
44482
44483
44484
44485
44486
44487
44488
44489
44490
44491
44492
44493
44494
44495
44496
44497
44498
44499
44500
44501
44502
44503
44504
44505
44506
44507
44508
44509
44510
44511
44512
44513
44514
44515
44516
44517
44518
44519
44520
44521
44522
44523
44524
44525
44526
44527
44528
44529
44530
44531
44532
44533
44534
44535
44536
44537
44538
44539
44540
44541
44542
44543
44544
44545
44546
44547
44548
44549
44550
44551
44552
44553
44554
44555
44556
44557
44558
44559
44560
44561
44562
44563
44564
44565
44566
44567
44568
44569
44570
44571
44572
44573
44574
44575
44576
44577
44578
44579
44580
44581
44582
44583
44584
44585
44586
44587
44588
44589
44590
44591
44592
44593
44594
44595
44596
44597
44598
44599
44600
44601
44602
44603
44604
44605
44606
44607
44608
44609
44610
44611
44612
44613
44614
44615
44616
44617
44618
44619
44620
44621
44622
44623
44624
44625
44626
44627
44628
44629
44630
44631
44632
44633
44634
44635
44636
44637
44638
44639
44640
44641
44642
44643
44644
44645
44646
44647
44648
44649
44650
44651
44652
44653
44654
44655
44656
44657
44658
44659
44660
44661
44662
44663
44664
44665
44666
44667
44668
44669
44670
44671
44672
44673
44674
44675
44676
44677
44678
44679
44680
44681
44682
44683
44684
44685
44686
44687
44688
44689
44690
44691
44692
44693
44694
44695
44696
44697
44698
44699
44700
44701
44702
44703
44704
44705
44706
44707
44708
44709
44710
44711
44712
44713
44714
44715
44716
44717
44718
44719
44720
44721
44722
44723
44724
44725
44726
44727
44728
44729
44730
44731
44732
44733
44734
44735
44736
44737
44738
44739
44740
44741
44742
44743
44744
44745
44746
44747
44748
44749
44750
44751
44752
44753
44754
44755
44756
44757
44758
44759
44760
44761
44762
44763
44764
44765
44766
44767
44768
44769
44770
44771
44772
44773
44774
44775
44776
44777
44778
44779
44780
44781
44782
44783
44784
44785
44786
44787
44788
44789
44790
44791
44792
44793
44794
44795
44796
44797
44798
44799
44800
44801
44802
44803
44804
44805
44806
44807
44808
44809
44810
44811
44812
44813
44814
44815
44816
44817
44818
44819
44820
44821
44822
44823
44824
44825
44826
44827
44828
44829
44830
44831
44832
44833
44834
44835
44836
44837
44838
44839
44840
44841
44842
44843
44844
44845
44846
44847
44848
44849
44850
44851
44852
44853
44854
44855
44856
44857
44858
44859
44860
44861
44862
44863
44864
44865
44866
44867
44868
44869
44870
44871
44872
44873
44874
44875
44876
44877
44878
44879
44880
44881
44882
44883
44884
44885
44886
44887
44888
44889
44890
44891
44892
44893
44894
44895
44896
44897
44898
44899
44900
44901
44902
44903
44904
44905
44906
44907
44908
44909
44910
44911
44912
44913
44914
44915
44916
44917
44918
44919
44920
44921
44922
44923
44924
44925
44926
44927
44928
44929
44930
44931
44932
44933
44934
44935
44936
44937
44938
44939
44940
44941
44942
44943
44944
44945
44946
44947
44948
44949
44950
44951
44952
44953
44954
44955
44956
44957
44958
44959
44960
44961
44962
44963
44964
44965
44966
44967
44968
44969
44970
44971
44972
44973
44974
44975
44976
44977
44978
44979
44980
44981
44982
44983
44984
44985
44986
44987
44988
44989
44990
44991
44992
44993
44994
44995
44996
44997
44998
44999
45000
45001
45002
45003
45004
45005
45006
45007
45008
45009
45010
45011
45012
45013
45014
45015
45016
45017
45018
45019
45020
45021
45022
45023
45024
45025
45026
45027
45028
45029
45030
45031
45032
45033
45034
45035
45036
45037
45038
45039
45040
45041
45042
45043
45044
45045
45046
45047
45048
45049
45050
45051
45052
45053
45054
45055
45056
45057
45058
45059
45060
45061
45062
45063
45064
45065
45066
45067
45068
45069
45070
45071
45072
45073
45074
45075
45076
45077
45078
45079
45080
45081
45082
45083
45084
45085
45086
45087
45088
45089
45090
45091
45092
45093
45094
45095
45096
45097
45098
45099
45100
45101
45102
45103
45104
45105
45106
45107
45108
45109
45110
45111
45112
45113
45114
45115
45116
45117
45118
45119
45120
45121
45122
45123
45124
45125
45126
45127
45128
45129
45130
45131
45132
45133
45134
45135
45136
45137
45138
45139
45140
45141
45142
45143
45144
45145
45146
45147
45148
45149
45150
45151
45152
45153
45154
45155
45156
45157
45158
45159
45160
45161
45162
45163
45164
45165
45166
45167
45168
45169
45170
45171
45172
45173
45174
45175
45176
45177
45178
45179
45180
45181
45182
45183
45184
45185
45186
45187
45188
45189
45190
45191
45192
45193
45194
45195
45196
45197
45198
45199
45200
45201
45202
45203
45204
45205
45206
45207
45208
45209
45210
45211
45212
45213
45214
45215
45216
45217
45218
45219
45220
45221
45222
45223
45224
45225
45226
45227
45228
45229
45230
45231
45232
45233
45234
45235
45236
45237
45238
45239
45240
45241
45242
45243
45244
45245
45246
45247
45248
45249
45250
45251
45252
45253
45254
45255
45256
45257
45258
45259
45260
45261
45262
45263
45264
45265
45266
45267
45268
45269
45270
45271
45272
45273
45274
45275
45276
45277
45278
45279
45280
45281
45282
45283
45284
45285
45286
45287
45288
45289
45290
45291
45292
45293
45294
45295
45296
45297
45298
45299
45300
45301
45302
45303
45304
45305
45306
45307
45308
45309
45310
45311
45312
45313
45314
45315
45316
45317
45318
45319
45320
45321
45322
45323
45324
45325
45326
45327
45328
45329
45330
45331
45332
45333
45334
45335
45336
45337
45338
45339
45340
45341
45342
45343
45344
45345
45346
45347
45348
45349
45350
45351
45352
45353
45354
45355
45356
45357
45358
45359
45360
45361
45362
45363
45364
45365
45366
45367
45368
45369
45370
45371
45372
45373
45374
45375
45376
45377
45378
45379
45380
45381
45382
45383
45384
45385
45386
45387
45388
45389
45390
45391
45392
45393
45394
45395
45396
45397
45398
45399
45400
45401
45402
45403
45404
45405
45406
45407
45408
45409
45410
45411
45412
45413
45414
45415
45416
45417
45418
45419
45420
45421
45422
45423
45424
45425
45426
45427
45428
45429
45430
45431
45432
45433
45434
45435
45436
45437
45438
45439
45440
45441
45442
45443
45444
45445
45446
45447
45448
45449
45450
45451
45452
45453
45454
45455
45456
45457
45458
45459
45460
45461
45462
45463
45464
45465
45466
45467
45468
45469
45470
45471
45472
45473
45474
45475
45476
45477
45478
45479
45480
45481
45482
45483
45484
45485
45486
45487
45488
45489
45490
45491
45492
45493
45494
45495
45496
45497
45498
45499
45500
45501
45502
45503
45504
45505
45506
45507
45508
45509
45510
45511
45512
45513
45514
45515
45516
45517
45518
45519
45520
45521
45522
45523
45524
45525
45526
45527
45528
45529
45530
45531
45532
45533
45534
45535
45536
45537
45538
45539
45540
45541
45542
45543
45544
45545
45546
45547
45548
45549
45550
45551
45552
45553
45554
45555
45556
45557
45558
45559
45560
45561
45562
45563
45564
45565
45566
45567
45568
45569
45570
45571
45572
45573
45574
45575
45576
45577
45578
45579
45580
45581
45582
45583
45584
45585
45586
45587
45588
45589
45590
45591
45592
45593
45594
45595
45596
45597
45598
45599
45600
45601
45602
45603
45604
45605
45606
45607
45608
45609
45610
45611
45612
45613
45614
45615
45616
45617
45618
45619
45620
45621
45622
45623
45624
45625
45626
45627
45628
45629
45630
45631
45632
45633
45634
45635
45636
45637
45638
45639
45640
45641
45642
45643
45644
45645
45646
45647
45648
45649
45650
45651
45652
45653
45654
45655
45656
45657
45658
45659
45660
45661
45662
45663
45664
45665
45666
45667
45668
45669
45670
45671
45672
45673
45674
45675
45676
45677
45678
45679
45680
45681
45682
45683
45684
45685
45686
45687
45688
45689
45690
45691
45692
45693
45694
45695
45696
45697
45698
45699
45700
45701
45702
45703
45704
45705
45706
45707
45708
45709
45710
45711
45712
45713
45714
45715
45716
45717
45718
45719
45720
45721
45722
45723
45724
45725
45726
45727
45728
45729
45730
45731
45732
45733
45734
45735
45736
45737
45738
45739
45740
45741
45742
45743
45744
45745
45746
45747
45748
45749
45750
45751
45752
45753
45754
45755
45756
45757
45758
45759
45760
45761
45762
45763
45764
45765
45766
45767
45768
45769
45770
45771
45772
45773
45774
45775
45776
45777
45778
45779
45780
45781
45782
45783
45784
45785
45786
45787
45788
45789
45790
45791
45792
45793
45794
45795
45796
45797
45798
45799
45800
45801
45802
45803
45804
45805
45806
45807
45808
45809
45810
45811
45812
45813
45814
45815
45816
45817
45818
45819
45820
45821
45822
45823
45824
45825
45826
45827
45828
45829
45830
45831
45832
45833
45834
45835
45836
45837
45838
45839
45840
45841
45842
45843
45844
45845
45846
45847
45848
45849
45850
45851
45852
45853
45854
45855
45856
45857
45858
45859
45860
45861
45862
45863
45864
45865
45866
45867
45868
45869
45870
45871
45872
45873
45874
45875
45876
45877
45878
45879
45880
45881
45882
45883
45884
45885
45886
45887
45888
45889
45890
45891
45892
45893
45894
45895
45896
45897
45898
45899
45900
45901
45902
45903
45904
45905
45906
45907
45908
45909
45910
45911
45912
45913
45914
45915
45916
45917
45918
45919
45920
45921
45922
45923
45924
45925
45926
45927
45928
45929
45930
45931
45932
45933
45934
45935
45936
45937
45938
45939
45940
45941
45942
45943
45944
45945
45946
45947
45948
45949
45950
45951
45952
45953
45954
45955
45956
45957
45958
45959
45960
45961
45962
45963
45964
45965
45966
45967
45968
45969
45970
45971
45972
45973
45974
45975
45976
45977
45978
45979
45980
45981
45982
45983
45984
45985
45986
45987
45988
45989
45990
45991
45992
45993
45994
45995
45996
45997
45998
45999
46000
46001
46002
46003
46004
46005
46006
46007
46008
46009
46010
46011
46012
46013
46014
46015
46016
46017
46018
46019
46020
46021
46022
46023
46024
46025
46026
46027
46028
46029
46030
46031
46032
46033
46034
46035
46036
46037
46038
46039
46040
46041
46042
46043
46044
46045
46046
46047
46048
46049
46050
46051
46052
46053
46054
46055
46056
46057
46058
46059
46060
46061
46062
46063
46064
46065
46066
46067
46068
46069
46070
46071
46072
46073
46074
46075
46076
46077
46078
46079
46080
46081
46082
46083
46084
46085
46086
46087
46088
46089
46090
46091
46092
46093
46094
46095
46096
46097
46098
46099
46100
46101
46102
46103
46104
46105
46106
46107
46108
46109
46110
46111
46112
46113
46114
46115
46116
46117
46118
46119
46120
46121
46122
46123
46124
46125
46126
46127
46128
46129
46130
46131
46132
46133
46134
46135
46136
46137
46138
46139
46140
46141
46142
46143
46144
46145
46146
46147
46148
46149
46150
46151
46152
46153
46154
46155
46156
46157
46158
46159
46160
46161
46162
46163
46164
46165
46166
46167
46168
46169
46170
46171
46172
46173
46174
46175
46176
46177
46178
46179
46180
46181
46182
46183
46184
46185
46186
46187
46188
46189
46190
46191
46192
46193
46194
46195
46196
46197
46198
46199
46200
46201
46202
46203
46204
46205
46206
46207
46208
46209
46210
46211
46212
46213
46214
46215
46216
46217
46218
46219
46220
46221
46222
46223
46224
46225
46226
46227
46228
46229
46230
46231
46232
46233
46234
46235
46236
46237
46238
46239
46240
46241
46242
46243
46244
46245
46246
46247
46248
46249
46250
46251
46252
46253
46254
46255
46256
46257
46258
46259
46260
46261
46262
46263
46264
46265
46266
46267
46268
46269
46270
46271
46272
46273
46274
46275
46276
46277
46278
46279
46280
46281
46282
46283
46284
46285
46286
46287
46288
46289
46290
46291
46292
46293
46294
46295
46296
46297
46298
46299
46300
46301
46302
46303
46304
46305
46306
46307
46308
46309
46310
46311
46312
46313
46314
46315
46316
46317
46318
46319
46320
46321
46322
46323
46324
46325
46326
46327
46328
46329
46330
46331
46332
46333
46334
46335
46336
46337
46338
46339
46340
46341
46342
46343
46344
46345
46346
46347
46348
46349
46350
46351
46352
46353
46354
46355
46356
46357
46358
46359
46360
46361
46362
46363
46364
46365
46366
46367
46368
46369
46370
46371
46372
46373
46374
46375
46376
46377
46378
46379
46380
46381
46382
46383
46384
46385
46386
46387
46388
46389
46390
46391
46392
46393
46394
46395
46396
46397
46398
46399
46400
46401
46402
46403
46404
46405
46406
46407
46408
46409
46410
46411
46412
46413
46414
46415
46416
46417
46418
46419
46420
46421
46422
46423
46424
46425
46426
46427
46428
46429
46430
46431
46432
46433
46434
46435
46436
46437
46438
46439
46440
46441
46442
46443
46444
46445
46446
46447
46448
46449
46450
46451
46452
46453
46454
46455
46456
46457
46458
46459
46460
46461
46462
46463
46464
46465
46466
46467
46468
46469
46470
46471
46472
46473
46474
46475
46476
46477
46478
46479
46480
46481
46482
46483
46484
46485
46486
46487
46488
46489
46490
46491
46492
46493
46494
46495
46496
46497
46498
46499
46500
46501
46502
46503
46504
46505
46506
46507
46508
46509
46510
46511
46512
46513
46514
46515
46516
46517
46518
46519
46520
46521
46522
46523
46524
46525
46526
46527
46528
46529
46530
46531
46532
46533
46534
46535
46536
46537
46538
46539
46540
46541
46542
46543
46544
46545
46546
46547
46548
46549
46550
46551
46552
46553
46554
46555
46556
46557
46558
46559
46560
46561
46562
46563
46564
46565
46566
46567
46568
46569
46570
46571
46572
46573
46574
46575
46576
46577
46578
46579
46580
46581
46582
46583
46584
46585
46586
46587
46588
46589
46590
46591
46592
46593
46594
46595
46596
46597
46598
46599
46600
46601
46602
46603
46604
46605
46606
46607
46608
46609
46610
46611
46612
46613
46614
46615
46616
46617
46618
46619
46620
46621
46622
46623
46624
46625
46626
46627
46628
46629
46630
46631
46632
46633
46634
46635
46636
46637
46638
46639
46640
46641
46642
46643
46644
46645
46646
46647
46648
46649
46650
46651
46652
46653
46654
46655
46656
46657
46658
46659
46660
46661
46662
46663
46664
46665
46666
46667
46668
46669
46670
46671
46672
46673
46674
46675
46676
46677
46678
46679
46680
46681
46682
46683
46684
46685
46686
46687
46688
46689
46690
46691
46692
46693
46694
46695
46696
46697
46698
46699
46700
46701
46702
46703
46704
46705
46706
46707
46708
46709
46710
46711
46712
46713
46714
46715
46716
46717
46718
46719
46720
46721
46722
46723
46724
46725
46726
46727
46728
46729
46730
46731
46732
46733
46734
46735
46736
46737
46738
46739
46740
46741
46742
46743
46744
46745
46746
46747
46748
46749
46750
46751
46752
46753
46754
46755
46756
46757
46758
46759
46760
46761
46762
46763
46764
46765
46766
46767
46768
46769
46770
46771
46772
46773
46774
46775
46776
46777
46778
46779
46780
46781
46782
46783
46784
46785
46786
46787
46788
46789
46790
46791
46792
46793
46794
46795
46796
46797
46798
46799
46800
46801
46802
46803
46804
46805
46806
46807
46808
46809
46810
46811
46812
46813
46814
46815
46816
46817
46818
46819
46820
46821
46822
46823
46824
46825
46826
46827
46828
46829
46830
46831
46832
46833
46834
46835
46836
46837
46838
46839
46840
46841
46842
46843
46844
46845
46846
46847
46848
46849
46850
46851
46852
46853
46854
46855
46856
46857
46858
46859
46860
46861
46862
46863
46864
46865
46866
46867
46868
46869
46870
46871
46872
46873
46874
46875
46876
46877
46878
46879
46880
46881
46882
46883
46884
46885
46886
46887
46888
46889
46890
46891
46892
46893
46894
46895
46896
46897
46898
46899
46900
46901
46902
46903
46904
46905
46906
46907
46908
46909
46910
46911
46912
46913
46914
46915
46916
46917
46918
46919
46920
46921
46922
46923
46924
46925
46926
46927
46928
46929
46930
46931
46932
46933
46934
46935
46936
46937
46938
46939
46940
46941
46942
46943
46944
46945
46946
46947
46948
46949
46950
46951
46952
46953
46954
46955
46956
46957
46958
46959
46960
46961
46962
46963
46964
46965
46966
46967
46968
46969
46970
46971
46972
46973
46974
46975
46976
46977
46978
46979
46980
46981
46982
46983
46984
46985
46986
46987
46988
46989
46990
46991
46992
46993
46994
46995
46996
46997
46998
46999
47000
47001
47002
47003
47004
47005
47006
47007
47008
47009
47010
47011
47012
47013
47014
47015
47016
47017
47018
47019
47020
47021
47022
47023
47024
47025
47026
47027
47028
47029
47030
47031
47032
47033
47034
47035
47036
47037
47038
47039
47040
47041
47042
47043
47044
47045
47046
47047
47048
47049
47050
47051
47052
47053
47054
47055
47056
47057
47058
47059
47060
47061
47062
47063
47064
47065
47066
47067
47068
47069
47070
47071
47072
47073
47074
47075
47076
47077
47078
47079
47080
47081
47082
47083
47084
47085
47086
47087
47088
47089
47090
47091
47092
47093
47094
47095
47096
47097
47098
47099
47100
47101
47102
47103
47104
47105
47106
47107
47108
47109
47110
47111
47112
47113
47114
47115
47116
47117
47118
47119
47120
47121
47122
47123
47124
47125
47126
47127
47128
47129
47130
47131
47132
47133
47134
47135
47136
47137
47138
47139
47140
47141
47142
47143
47144
47145
47146
47147
47148
47149
47150
47151
47152
47153
47154
47155
47156
47157
47158
47159
47160
47161
47162
47163
47164
47165
47166
47167
47168
47169
47170
47171
47172
47173
47174
47175
47176
47177
47178
47179
47180
47181
47182
47183
47184
47185
47186
47187
47188
47189
47190
47191
47192
47193
47194
47195
47196
47197
47198
47199
47200
47201
47202
47203
47204
47205
47206
47207
47208
47209
47210
47211
47212
47213
47214
47215
47216
47217
47218
47219
47220
47221
47222
47223
47224
47225
47226
47227
47228
47229
47230
47231
47232
47233
47234
47235
47236
47237
47238
47239
47240
47241
47242
47243
47244
47245
47246
47247
47248
47249
47250
47251
47252
47253
47254
47255
47256
47257
47258
47259
47260
47261
47262
47263
47264
47265
47266
47267
47268
47269
47270
47271
47272
47273
47274
47275
47276
47277
47278
47279
47280
47281
47282
47283
47284
47285
47286
47287
47288
47289
47290
47291
47292
47293
47294
47295
47296
47297
47298
47299
47300
47301
47302
47303
47304
47305
47306
47307
47308
47309
47310
47311
47312
47313
47314
47315
47316
47317
47318
47319
47320
47321
47322
47323
47324
47325
47326
47327
47328
47329
47330
47331
47332
47333
47334
47335
47336
47337
47338
47339
47340
47341
47342
47343
47344
47345
47346
47347
47348
47349
47350
47351
47352
47353
47354
47355
47356
47357
47358
47359
47360
47361
47362
47363
47364
47365
47366
47367
47368
47369
47370
47371
47372
47373
47374
47375
47376
47377
47378
47379
47380
47381
47382
47383
47384
47385
47386
47387
47388
47389
47390
47391
47392
47393
47394
47395
47396
47397
47398
47399
47400
47401
47402
47403
47404
47405
47406
47407
47408
47409
47410
47411
47412
47413
47414
47415
47416
47417
47418
47419
47420
47421
47422
47423
47424
47425
47426
47427
47428
47429
47430
47431
47432
47433
47434
47435
47436
47437
47438
47439
47440
47441
47442
47443
47444
47445
47446
47447
47448
47449
47450
47451
47452
47453
47454
47455
47456
47457
47458
47459
47460
47461
47462
47463
47464
47465
47466
47467
47468
47469
47470
47471
47472
47473
47474
47475
47476
47477
47478
47479
47480
47481
47482
47483
47484
47485
47486
47487
47488
47489
47490
47491
47492
47493
47494
47495
47496
47497
47498
47499
47500
47501
47502
47503
47504
47505
47506
47507
47508
47509
47510
47511
47512
47513
47514
47515
47516
47517
47518
47519
47520
47521
47522
47523
47524
47525
47526
47527
47528
47529
47530
47531
47532
47533
47534
47535
47536
47537
47538
47539
47540
47541
47542
47543
47544
47545
47546
47547
47548
47549
47550
47551
47552
47553
47554
47555
47556
47557
47558
47559
47560
47561
47562
47563
47564
47565
47566
47567
47568
47569
47570
47571
47572
47573
47574
47575
47576
47577
47578
47579
47580
47581
47582
47583
47584
47585
47586
47587
47588
47589
47590
47591
47592
47593
47594
47595
47596
47597
47598
47599
47600
47601
47602
47603
47604
47605
47606
47607
47608
47609
47610
47611
47612
47613
47614
47615
47616
47617
47618
47619
47620
47621
47622
47623
47624
47625
47626
47627
47628
47629
47630
47631
47632
47633
47634
47635
47636
47637
47638
47639
47640
47641
47642
47643
47644
47645
47646
47647
47648
47649
47650
47651
47652
47653
47654
47655
47656
47657
47658
47659
47660
47661
47662
47663
47664
47665
47666
47667
47668
47669
47670
47671
47672
47673
47674
47675
47676
47677
47678
47679
47680
47681
47682
47683
47684
47685
47686
47687
47688
47689
47690
47691
47692
47693
47694
47695
47696
47697
47698
47699
47700
47701
47702
47703
47704
47705
47706
47707
47708
47709
47710
47711
47712
47713
47714
47715
47716
47717
47718
47719
47720
47721
47722
47723
47724
47725
47726
47727
47728
47729
47730
47731
47732
47733
47734
47735
47736
47737
47738
47739
47740
47741
47742
47743
47744
47745
47746
47747
47748
47749
47750
47751
47752
47753
47754
47755
47756
47757
47758
47759
47760
47761
47762
47763
47764
47765
47766
47767
47768
47769
47770
47771
47772
47773
47774
47775
47776
47777
47778
47779
47780
47781
47782
47783
47784
47785
47786
47787
47788
47789
47790
47791
47792
47793
47794
47795
47796
47797
47798
47799
47800
47801
47802
47803
47804
47805
47806
47807
47808
47809
47810
47811
47812
47813
47814
47815
47816
47817
47818
47819
47820
47821
47822
47823
47824
47825
47826
47827
47828
47829
47830
47831
47832
47833
47834
47835
47836
47837
47838
47839
47840
47841
47842
47843
47844
47845
47846
47847
47848
47849
47850
47851
47852
47853
47854
47855
47856
47857
47858
47859
47860
47861
47862
47863
47864
47865
47866
47867
47868
47869
47870
47871
47872
47873
47874
47875
47876
47877
47878
47879
47880
47881
47882
47883
47884
47885
47886
47887
47888
47889
47890
47891
47892
47893
47894
47895
47896
47897
47898
47899
47900
47901
47902
47903
47904
47905
47906
47907
47908
47909
47910
47911
47912
47913
47914
47915
47916
47917
47918
47919
47920
47921
47922
47923
47924
47925
47926
47927
47928
47929
47930
47931
47932
47933
47934
47935
47936
47937
47938
47939
47940
47941
47942
47943
47944
47945
47946
47947
47948
47949
47950
47951
47952
47953
47954
47955
47956
47957
47958
47959
47960
47961
47962
47963
47964
47965
47966
47967
47968
47969
47970
47971
47972
47973
47974
47975
47976
47977
47978
47979
47980
47981
47982
47983
47984
47985
47986
47987
47988
47989
47990
47991
47992
47993
47994
47995
47996
47997
47998
47999
48000
48001
48002
48003
48004
48005
48006
48007
48008
48009
48010
48011
48012
48013
48014
48015
48016
48017
48018
48019
48020
48021
48022
48023
48024
48025
48026
48027
48028
48029
48030
48031
48032
48033
48034
48035
48036
48037
48038
48039
48040
48041
48042
48043
48044
48045
48046
48047
48048
48049
48050
48051
48052
48053
48054
48055
48056
48057
48058
48059
48060
48061
48062
48063
48064
48065
48066
48067
48068
48069
48070
48071
48072
48073
48074
48075
48076
48077
48078
48079
48080
48081
48082
48083
48084
48085
48086
48087
48088
48089
48090
48091
48092
48093
48094
48095
48096
48097
48098
48099
48100
48101
48102
48103
48104
48105
48106
48107
48108
48109
48110
48111
48112
48113
48114
48115
48116
48117
48118
48119
48120
48121
48122
48123
48124
48125
48126
48127
48128
48129
48130
48131
48132
48133
48134
48135
48136
48137
48138
48139
48140
48141
48142
48143
48144
48145
48146
48147
48148
48149
48150
48151
48152
48153
48154
48155
48156
48157
48158
48159
48160
48161
48162
48163
48164
48165
48166
48167
48168
48169
48170
48171
48172
48173
48174
48175
48176
48177
48178
48179
48180
48181
48182
48183
48184
48185
48186
48187
48188
48189
48190
48191
48192
48193
48194
48195
48196
48197
48198
48199
48200
48201
48202
48203
48204
48205
48206
48207
48208
48209
48210
48211
48212
48213
48214
48215
48216
48217
48218
48219
48220
48221
48222
48223
48224
48225
48226
48227
48228
48229
48230
48231
48232
48233
48234
48235
48236
48237
48238
48239
48240
48241
48242
48243
48244
48245
48246
48247
48248
48249
48250
48251
48252
48253
48254
48255
48256
48257
48258
48259
48260
48261
48262
48263
48264
48265
48266
48267
48268
48269
48270
48271
48272
48273
48274
48275
48276
48277
48278
48279
48280
48281
48282
48283
48284
48285
48286
48287
48288
48289
48290
48291
48292
48293
48294
48295
48296
48297
48298
48299
48300
48301
48302
48303
48304
48305
48306
48307
48308
48309
48310
48311
48312
48313
48314
48315
48316
48317
48318
48319
48320
48321
48322
48323
48324
48325
48326
48327
48328
48329
48330
48331
48332
48333
48334
48335
48336
48337
48338
48339
48340
48341
48342
48343
48344
48345
48346
48347
48348
48349
48350
48351
48352
48353
48354
48355
48356
48357
48358
48359
48360
48361
48362
48363
48364
48365
48366
48367
48368
48369
48370
48371
48372
48373
48374
48375
48376
48377
48378
48379
48380
48381
48382
48383
48384
48385
48386
48387
48388
48389
48390
48391
48392
48393
48394
48395
48396
48397
48398
48399
48400
48401
48402
48403
48404
48405
48406
48407
48408
48409
48410
48411
48412
48413
48414
48415
48416
48417
48418
48419
48420
48421
48422
48423
48424
48425
48426
48427
48428
48429
48430
48431
48432
48433
48434
48435
48436
48437
48438
48439
48440
48441
48442
48443
48444
48445
48446
48447
48448
48449
48450
48451
48452
48453
48454
48455
48456
48457
48458
48459
48460
48461
48462
48463
48464
48465
48466
48467
48468
48469
48470
48471
48472
48473
48474
48475
48476
48477
48478
48479
48480
48481
48482
48483
48484
48485
48486
48487
48488
48489
48490
48491
48492
48493
48494
48495
48496
48497
48498
48499
48500
48501
48502
48503
48504
48505
48506
48507
48508
48509
48510
48511
48512
48513
48514
48515
48516
48517
48518
48519
48520
48521
48522
48523
48524
48525
48526
48527
48528
48529
48530
48531
48532
48533
48534
48535
48536
48537
48538
48539
48540
48541
48542
48543
48544
48545
48546
48547
48548
48549
48550
48551
48552
48553
48554
48555
48556
48557
48558
48559
48560
48561
48562
48563
48564
48565
48566
48567
48568
48569
48570
48571
48572
48573
48574
48575
48576
48577
48578
48579
48580
48581
48582
48583
48584
48585
48586
48587
48588
48589
48590
48591
48592
48593
48594
48595
48596
48597
48598
48599
48600
48601
48602
48603
48604
48605
48606
48607
48608
48609
48610
48611
48612
48613
48614
48615
48616
48617
48618
48619
48620
48621
48622
48623
48624
48625
48626
48627
48628
48629
48630
48631
48632
48633
48634
48635
48636
48637
48638
48639
48640
48641
48642
48643
48644
48645
48646
48647
48648
48649
48650
48651
48652
48653
48654
48655
48656
48657
48658
48659
48660
48661
48662
48663
48664
48665
48666
48667
48668
48669
48670
48671
48672
48673
48674
48675
48676
48677
48678
48679
48680
48681
48682
48683
48684
48685
48686
48687
48688
48689
48690
48691
48692
48693
48694
48695
48696
48697
48698
48699
48700
48701
48702
48703
48704
48705
48706
48707
48708
48709
48710
48711
48712
48713
48714
48715
48716
48717
48718
48719
48720
48721
48722
48723
48724
48725
48726
48727
48728
48729
48730
48731
48732
48733
48734
48735
48736
48737
48738
48739
48740
48741
48742
48743
48744
48745
48746
48747
48748
48749
48750
48751
48752
48753
48754
48755
48756
48757
48758
48759
48760
48761
48762
48763
48764
48765
48766
48767
48768
48769
48770
48771
48772
48773
48774
48775
48776
48777
48778
48779
48780
48781
48782
48783
48784
48785
48786
48787
48788
48789
48790
48791
48792
48793
48794
48795
48796
48797
48798
48799
48800
48801
48802
48803
48804
48805
48806
48807
48808
48809
48810
48811
48812
48813
48814
48815
48816
48817
48818
48819
48820
48821
48822
48823
48824
48825
48826
48827
48828
48829
48830
48831
48832
48833
48834
48835
48836
48837
48838
48839
48840
48841
48842
48843
48844
48845
48846
48847
48848
48849
48850
48851
48852
48853
48854
48855
48856
48857
48858
48859
48860
48861
48862
48863
48864
48865
48866
48867
48868
48869
48870
48871
48872
48873
48874
48875
48876
48877
48878
48879
48880
48881
48882
48883
48884
48885
48886
48887
48888
48889
48890
48891
48892
48893
48894
48895
48896
48897
48898
48899
48900
48901
48902
48903
48904
48905
48906
48907
48908
48909
48910
48911
48912
48913
48914
48915
48916
48917
48918
48919
48920
48921
48922
48923
48924
48925
48926
48927
48928
48929
48930
48931
48932
48933
48934
48935
48936
48937
48938
48939
48940
48941
48942
48943
48944
48945
48946
48947
48948
48949
48950
48951
48952
48953
48954
48955
48956
48957
48958
48959
48960
48961
48962
48963
48964
48965
48966
48967
48968
48969
48970
48971
48972
48973
48974
48975
48976
48977
48978
48979
48980
48981
48982
48983
48984
48985
48986
48987
48988
48989
48990
48991
48992
48993
48994
48995
48996
48997
48998
48999
49000
49001
49002
49003
49004
49005
49006
49007
49008
49009
49010
49011
49012
49013
49014
49015
49016
49017
49018
49019
49020
49021
49022
49023
49024
49025
49026
49027
49028
49029
49030
49031
49032
49033
49034
49035
49036
49037
49038
49039
49040
49041
49042
49043
49044
49045
49046
49047
49048
49049
49050
49051
49052
49053
49054
49055
49056
49057
49058
49059
49060
49061
49062
49063
49064
49065
49066
49067
49068
49069
49070
49071
49072
49073
49074
49075
49076
49077
49078
49079
49080
49081
49082
49083
49084
49085
49086
49087
49088
49089
49090
49091
49092
49093
49094
49095
49096
49097
49098
49099
49100
49101
49102
49103
49104
49105
49106
49107
49108
49109
49110
49111
49112
49113
49114
49115
49116
49117
49118
49119
49120
49121
49122
49123
49124
49125
49126
49127
49128
49129
49130
49131
49132
49133
49134
49135
49136
49137
49138
49139
49140
49141
49142
49143
49144
49145
49146
49147
49148
49149
49150
49151
49152
49153
49154
49155
49156
49157
49158
49159
49160
49161
49162
49163
49164
49165
49166
49167
49168
49169
49170
49171
49172
49173
49174
49175
49176
49177
49178
49179
49180
49181
49182
49183
49184
49185
49186
49187
49188
49189
49190
49191
49192
49193
49194
49195
49196
49197
49198
49199
49200
49201
49202
49203
49204
49205
49206
49207
49208
49209
49210
49211
49212
49213
49214
49215
49216
49217
49218
49219
49220
49221
49222
49223
49224
49225
49226
49227
49228
49229
49230
49231
49232
49233
49234
49235
49236
49237
49238
49239
49240
49241
49242
49243
49244
49245
49246
49247
49248
49249
49250
49251
49252
49253
49254
49255
49256
49257
49258
49259
49260
49261
49262
49263
49264
49265
49266
49267
49268
49269
49270
49271
49272
49273
49274
49275
49276
49277
49278
49279
49280
49281
49282
49283
49284
49285
49286
49287
49288
49289
49290
49291
49292
49293
49294
49295
49296
49297
49298
49299
49300
49301
49302
49303
49304
49305
49306
49307
49308
49309
49310
49311
49312
49313
49314
49315
49316
49317
49318
49319
49320
49321
49322
49323
49324
49325
49326
49327
49328
49329
49330
49331
49332
49333
49334
49335
49336
49337
49338
49339
49340
49341
49342
49343
49344
49345
49346
49347
49348
49349
49350
49351
49352
49353
49354
49355
49356
49357
49358
49359
49360
49361
49362
49363
49364
49365
49366
49367
49368
49369
49370
49371
49372
49373
49374
49375
49376
49377
49378
49379
49380
49381
49382
49383
49384
49385
49386
49387
49388
49389
49390
49391
49392
49393
49394
49395
49396
49397
49398
49399
49400
49401
49402
49403
49404
49405
49406
49407
49408
49409
49410
49411
49412
49413
49414
49415
49416
49417
49418
49419
49420
49421
49422
49423
49424
49425
49426
49427
49428
49429
49430
49431
49432
49433
49434
49435
49436
49437
49438
49439
49440
49441
49442
49443
49444
49445
49446
49447
49448
49449
49450
49451
49452
49453
49454
49455
49456
49457
49458
49459
49460
49461
49462
49463
49464
49465
49466
49467
49468
49469
49470
49471
49472
49473
49474
49475
49476
49477
49478
49479
49480
49481
49482
49483
49484
49485
49486
49487
49488
49489
49490
49491
49492
49493
49494
49495
49496
49497
49498
49499
49500
49501
49502
49503
49504
49505
49506
49507
49508
49509
49510
49511
49512
49513
49514
49515
49516
49517
49518
49519
49520
49521
49522
49523
49524
49525
49526
49527
49528
49529
49530
49531
49532
49533
49534
49535
49536
49537
49538
49539
49540
49541
49542
49543
49544
49545
49546
49547
49548
49549
49550
49551
49552
49553
49554
49555
49556
49557
49558
49559
49560
49561
49562
49563
49564
49565
49566
49567
49568
49569
49570
49571
49572
49573
49574
49575
49576
49577
49578
49579
49580
49581
49582
49583
49584
49585
49586
49587
49588
49589
49590
49591
49592
49593
49594
49595
49596
49597
49598
49599
49600
49601
49602
49603
49604
49605
49606
49607
49608
49609
49610
49611
49612
49613
49614
49615
49616
49617
49618
49619
49620
49621
49622
49623
49624
49625
49626
49627
49628
49629
49630
49631
49632
49633
49634
49635
49636
49637
49638
49639
49640
49641
49642
49643
49644
49645
49646
49647
49648
49649
49650
49651
49652
49653
49654
49655
49656
49657
49658
49659
49660
49661
49662
49663
49664
49665
49666
49667
49668
49669
49670
49671
49672
49673
49674
49675
49676
49677
49678
49679
49680
49681
49682
49683
49684
49685
49686
49687
49688
49689
49690
49691
49692
49693
49694
49695
49696
49697
49698
49699
49700
49701
49702
49703
49704
49705
49706
49707
49708
49709
49710
49711
49712
49713
49714
49715
49716
49717
49718
49719
49720
49721
49722
49723
49724
49725
49726
49727
49728
49729
49730
49731
49732
49733
49734
49735
49736
49737
49738
49739
49740
49741
49742
49743
49744
49745
49746
49747
49748
49749
49750
49751
49752
49753
49754
49755
49756
49757
49758
49759
49760
49761
49762
49763
49764
49765
49766
49767
49768
49769
49770
49771
49772
49773
49774
49775
49776
49777
49778
49779
49780
49781
49782
49783
49784
49785
49786
49787
49788
49789
49790
49791
49792
49793
49794
49795
49796
49797
49798
49799
49800
49801
49802
49803
49804
49805
49806
49807
49808
49809
49810
49811
49812
49813
49814
49815
49816
49817
49818
49819
49820
49821
49822
49823
49824
49825
49826
49827
49828
49829
49830
49831
49832
49833
49834
49835
49836
49837
49838
49839
49840
49841
49842
49843
49844
49845
49846
49847
49848
49849
49850
49851
49852
49853
49854
49855
49856
49857
49858
49859
49860
49861
49862
49863
49864
49865
49866
49867
49868
49869
49870
49871
49872
49873
49874
49875
49876
49877
49878
49879
49880
49881
49882
49883
49884
49885
49886
49887
49888
49889
49890
49891
49892
49893
49894
49895
49896
49897
49898
49899
49900
49901
49902
49903
49904
49905
49906
49907
49908
49909
49910
49911
49912
49913
49914
49915
49916
49917
49918
49919
49920
49921
49922
49923
49924
49925
49926
49927
49928
49929
49930
49931
49932
49933
49934
49935
49936
49937
49938
49939
49940
49941
49942
49943
49944
49945
49946
49947
49948
49949
49950
49951
49952
49953
49954
49955
49956
49957
49958
49959
49960
49961
49962
49963
49964
49965
49966
49967
49968
49969
49970
49971
49972
49973
49974
49975
49976
49977
49978
49979
49980
49981
49982
49983
49984
49985
49986
49987
49988
49989
49990
49991
49992
49993
49994
49995
49996
49997
49998
49999
50000
50001
50002
50003
50004
50005
50006
50007
50008
50009
50010
50011
50012
50013
50014
50015
50016
50017
50018
50019
50020
50021
50022
50023
50024
50025
50026
50027
50028
50029
50030
50031
50032
50033
50034
50035
50036
50037
50038
50039
50040
50041
50042
50043
50044
50045
50046
50047
50048
50049
50050
50051
50052
50053
50054
50055
50056
50057
50058
50059
50060
50061
50062
50063
50064
50065
50066
50067
50068
50069
50070
50071
50072
50073
50074
50075
50076
50077
50078
50079
50080
50081
50082
50083
50084
50085
50086
50087
50088
50089
50090
50091
50092
50093
50094
50095
50096
50097
50098
50099
50100
50101
50102
50103
50104
50105
50106
50107
50108
50109
50110
50111
50112
50113
50114
50115
50116
50117
50118
50119
50120
50121
50122
50123
50124
50125
50126
50127
50128
50129
50130
50131
50132
50133
50134
50135
50136
50137
50138
50139
50140
50141
50142
50143
50144
50145
50146
50147
50148
50149
50150
50151
50152
50153
50154
50155
50156
50157
50158
50159
50160
50161
50162
50163
50164
50165
50166
50167
50168
50169
50170
50171
50172
50173
50174
50175
50176
50177
50178
50179
50180
50181
50182
50183
50184
50185
50186
50187
50188
50189
50190
50191
50192
50193
50194
50195
50196
50197
50198
50199
50200
50201
50202
50203
50204
50205
50206
50207
50208
50209
50210
50211
50212
50213
50214
50215
50216
50217
50218
50219
50220
50221
50222
50223
50224
50225
50226
50227
50228
50229
50230
50231
50232
50233
50234
50235
50236
50237
50238
50239
50240
50241
50242
50243
50244
50245
50246
50247
50248
50249
50250
50251
50252
50253
50254
50255
50256
50257
50258
50259
50260
50261
50262
50263
50264
50265
50266
50267
50268
50269
50270
50271
50272
50273
50274
50275
50276
50277
50278
50279
50280
50281
50282
50283
50284
50285
50286
50287
50288
50289
50290
50291
50292
50293
50294
50295
50296
50297
50298
50299
50300
50301
50302
50303
50304
50305
50306
50307
50308
50309
50310
50311
50312
50313
50314
50315
50316
50317
50318
50319
50320
50321
50322
50323
50324
50325
50326
50327
50328
50329
50330
50331
50332
50333
50334
50335
50336
50337
50338
50339
50340
50341
50342
50343
50344
50345
50346
50347
50348
50349
50350
50351
50352
50353
50354
50355
50356
50357
50358
50359
50360
50361
50362
50363
50364
50365
50366
50367
50368
50369
50370
50371
50372
50373
50374
50375
50376
50377
50378
50379
50380
50381
50382
50383
50384
50385
50386
50387
50388
50389
50390
50391
50392
50393
50394
50395
50396
50397
50398
50399
50400
50401
50402
50403
50404
50405
50406
50407
50408
50409
50410
50411
50412
50413
50414
50415
50416
50417
50418
50419
50420
50421
50422
50423
50424
50425
50426
50427
50428
50429
50430
50431
50432
50433
50434
50435
50436
50437
50438
50439
50440
50441
50442
50443
50444
50445
50446
50447
50448
50449
50450
50451
50452
50453
50454
50455
50456
50457
50458
50459
50460
50461
50462
50463
50464
50465
50466
50467
50468
50469
50470
50471
50472
50473
50474
50475
50476
50477
50478
50479
50480
50481
50482
50483
50484
50485
50486
50487
50488
50489
50490
50491
50492
50493
50494
50495
50496
50497
50498
50499
50500
50501
50502
50503
50504
50505
50506
50507
50508
50509
50510
50511
50512
50513
50514
50515
50516
50517
50518
50519
50520
50521
50522
50523
50524
50525
50526
50527
50528
50529
50530
50531
50532
50533
50534
50535
50536
50537
50538
50539
50540
50541
50542
50543
50544
50545
50546
50547
50548
50549
50550
50551
50552
50553
50554
50555
50556
50557
50558
50559
50560
50561
50562
50563
50564
50565
50566
50567
50568
50569
50570
50571
50572
50573
50574
50575
50576
50577
50578
50579
50580
50581
50582
50583
50584
50585
50586
50587
50588
50589
50590
50591
50592
50593
50594
50595
50596
50597
50598
50599
50600
50601
50602
50603
50604
50605
50606
50607
50608
50609
50610
50611
50612
50613
50614
50615
50616
50617
50618
50619
50620
50621
50622
50623
50624
50625
50626
50627
50628
50629
50630
50631
50632
50633
50634
50635
50636
50637
50638
50639
50640
50641
50642
50643
50644
50645
50646
50647
50648
50649
50650
50651
50652
50653
50654
50655
50656
50657
50658
50659
50660
50661
50662
50663
50664
50665
50666
50667
50668
50669
50670
50671
50672
50673
50674
50675
50676
50677
50678
50679
50680
50681
50682
50683
50684
50685
50686
50687
50688
50689
50690
50691
50692
50693
50694
50695
50696
50697
50698
50699
50700
50701
50702
50703
50704
50705
50706
50707
50708
50709
50710
50711
50712
50713
50714
50715
50716
50717
50718
50719
50720
50721
50722
50723
50724
50725
50726
50727
50728
50729
50730
50731
50732
50733
50734
50735
50736
50737
50738
50739
50740
50741
50742
50743
50744
50745
50746
50747
50748
50749
50750
50751
50752
50753
50754
50755
50756
50757
50758
50759
50760
50761
50762
50763
50764
50765
50766
50767
50768
50769
50770
50771
50772
50773
50774
50775
50776
50777
50778
50779
50780
50781
50782
50783
50784
50785
50786
50787
50788
50789
50790
50791
50792
50793
50794
50795
50796
50797
50798
50799
50800
50801
50802
50803
50804
50805
50806
50807
50808
50809
50810
50811
50812
50813
50814
50815
50816
50817
50818
50819
50820
50821
50822
50823
50824
50825
50826
50827
50828
50829
50830
50831
50832
50833
50834
50835
50836
50837
50838
50839
50840
50841
50842
50843
50844
50845
50846
50847
50848
50849
50850
50851
50852
50853
50854
50855
50856
50857
50858
50859
50860
50861
50862
50863
50864
50865
50866
50867
50868
50869
50870
50871
50872
50873
50874
50875
50876
50877
50878
50879
50880
50881
50882
50883
50884
50885
50886
50887
50888
50889
50890
50891
50892
50893
50894
50895
50896
50897
50898
50899
50900
50901
50902
50903
50904
50905
50906
50907
50908
50909
50910
50911
50912
50913
50914
50915
50916
50917
50918
50919
50920
50921
50922
50923
50924
50925
50926
50927
50928
50929
50930
50931
50932
50933
50934
50935
50936
50937
50938
50939
50940
50941
50942
50943
50944
50945
50946
50947
50948
50949
50950
50951
50952
50953
50954
50955
50956
50957
50958
50959
50960
50961
50962
50963
50964
50965
50966
50967
50968
50969
50970
50971
50972
50973
50974
50975
50976
50977
50978
50979
50980
50981
50982
50983
50984
50985
50986
50987
50988
50989
50990
50991
50992
50993
50994
50995
50996
50997
50998
50999
51000
51001
51002
51003
51004
51005
51006
51007
51008
51009
51010
51011
51012
51013
51014
51015
51016
51017
51018
51019
51020
51021
51022
51023
51024
51025
51026
51027
51028
51029
51030
51031
51032
51033
51034
51035
51036
51037
51038
51039
51040
51041
51042
51043
51044
51045
51046
51047
51048
51049
51050
51051
51052
51053
51054
51055
51056
51057
51058
51059
51060
51061
51062
51063
51064
51065
51066
51067
51068
51069
51070
51071
51072
51073
51074
51075
51076
51077
51078
51079
51080
51081
51082
51083
51084
51085
51086
51087
51088
51089
51090
51091
51092
51093
51094
51095
51096
51097
51098
51099
51100
51101
51102
51103
51104
51105
51106
51107
51108
51109
51110
51111
51112
51113
51114
51115
51116
51117
51118
51119
51120
51121
51122
51123
51124
51125
51126
51127
51128
51129
51130
51131
51132
51133
51134
51135
51136
51137
51138
51139
51140
51141
51142
51143
51144
51145
51146
51147
51148
51149
51150
51151
51152
51153
51154
51155
51156
51157
51158
51159
51160
51161
51162
51163
51164
51165
51166
51167
51168
51169
51170
51171
51172
51173
51174
51175
51176
51177
51178
51179
51180
51181
51182
51183
51184
51185
51186
51187
51188
51189
51190
51191
51192
51193
51194
51195
51196
51197
51198
51199
51200
51201
51202
51203
51204
51205
51206
51207
51208
51209
51210
51211
51212
51213
51214
51215
51216
51217
51218
51219
51220
51221
51222
51223
51224
51225
51226
51227
51228
51229
51230
51231
51232
51233
51234
51235
51236
51237
51238
51239
51240
51241
51242
51243
51244
51245
51246
51247
51248
51249
51250
51251
51252
51253
51254
51255
51256
51257
51258
51259
51260
51261
51262
51263
51264
51265
51266
51267
51268
51269
51270
51271
51272
51273
51274
51275
51276
51277
51278
51279
51280
51281
51282
51283
51284
51285
51286
51287
51288
51289
51290
51291
51292
51293
51294
51295
51296
51297
51298
51299
51300
51301
51302
51303
51304
51305
51306
51307
51308
51309
51310
51311
51312
51313
51314
51315
51316
51317
51318
51319
51320
51321
51322
51323
51324
51325
51326
51327
51328
51329
51330
51331
51332
51333
51334
51335
51336
51337
51338
51339
51340
51341
51342
51343
51344
51345
51346
51347
51348
51349
51350
51351
51352
51353
51354
51355
51356
51357
51358
51359
51360
51361
51362
51363
51364
51365
51366
51367
51368
51369
51370
51371
51372
51373
51374
51375
51376
51377
51378
51379
51380
51381
51382
51383
51384
51385
51386
51387
51388
51389
51390
51391
51392
51393
51394
51395
51396
51397
51398
51399
51400
51401
51402
51403
51404
51405
51406
51407
51408
51409
51410
51411
51412
51413
51414
51415
51416
51417
51418
51419
51420
51421
51422
51423
51424
51425
51426
51427
51428
51429
51430
51431
51432
51433
51434
51435
51436
51437
51438
51439
51440
51441
51442
51443
51444
51445
51446
51447
51448
51449
51450
51451
51452
51453
51454
51455
51456
51457
51458
51459
51460
51461
51462
51463
51464
51465
51466
51467
51468
51469
51470
51471
51472
51473
51474
51475
51476
51477
51478
51479
51480
51481
51482
51483
51484
51485
51486
51487
51488
51489
51490
51491
51492
51493
51494
51495
51496
51497
51498
51499
51500
51501
51502
51503
51504
51505
51506
51507
51508
51509
51510
51511
51512
51513
51514
51515
51516
51517
51518
51519
51520
51521
51522
51523
51524
51525
51526
51527
51528
51529
51530
51531
51532
51533
51534
51535
51536
51537
51538
51539
51540
51541
51542
51543
51544
51545
51546
51547
51548
51549
51550
51551
51552
51553
51554
51555
51556
51557
51558
51559
51560
51561
51562
51563
51564
51565
51566
51567
51568
51569
51570
51571
51572
51573
51574
51575
51576
51577
51578
51579
51580
51581
51582
51583
51584
51585
51586
51587
51588
51589
51590
51591
51592
51593
51594
51595
51596
51597
51598
51599
51600
51601
51602
51603
51604
51605
51606
51607
51608
51609
51610
51611
51612
51613
51614
51615
51616
51617
51618
51619
51620
51621
51622
51623
51624
51625
51626
51627
51628
51629
51630
51631
51632
51633
51634
51635
51636
51637
51638
51639
51640
51641
51642
51643
51644
51645
51646
51647
51648
51649
51650
51651
51652
51653
51654
51655
51656
51657
51658
51659
51660
51661
51662
51663
51664
51665
51666
51667
51668
51669
51670
51671
51672
51673
51674
51675
51676
51677
51678
51679
51680
51681
51682
51683
51684
51685
51686
51687
51688
51689
51690
51691
51692
51693
51694
51695
51696
51697
51698
51699
51700
51701
51702
51703
51704
51705
51706
51707
51708
51709
51710
51711
51712
51713
51714
51715
51716
51717
51718
51719
51720
51721
51722
51723
51724
51725
51726
51727
51728
51729
51730
51731
51732
51733
51734
51735
51736
51737
51738
51739
51740
51741
51742
51743
51744
51745
51746
51747
51748
51749
51750
51751
51752
51753
51754
51755
51756
51757
51758
51759
51760
51761
51762
51763
51764
51765
51766
51767
51768
51769
51770
51771
51772
51773
51774
51775
51776
51777
51778
51779
51780
51781
51782
51783
51784
51785
51786
51787
51788
51789
51790
51791
51792
51793
51794
51795
51796
51797
51798
51799
51800
51801
51802
51803
51804
51805
51806
51807
51808
51809
51810
51811
51812
51813
51814
51815
51816
51817
51818
51819
51820
51821
51822
51823
51824
51825
51826
51827
51828
51829
51830
51831
51832
51833
51834
51835
51836
51837
51838
51839
51840
51841
51842
51843
51844
51845
51846
51847
51848
51849
51850
51851
51852
51853
51854
51855
51856
51857
51858
51859
51860
51861
51862
51863
51864
51865
51866
51867
51868
51869
51870
51871
51872
51873
51874
51875
51876
51877
51878
51879
51880
51881
51882
51883
51884
51885
51886
51887
51888
51889
51890
51891
51892
51893
51894
51895
51896
51897
51898
51899
51900
51901
51902
51903
51904
51905
51906
51907
51908
51909
51910
51911
51912
51913
51914
51915
51916
51917
51918
51919
51920
51921
51922
51923
51924
51925
51926
51927
51928
51929
51930
51931
51932
51933
51934
51935
51936
51937
51938
51939
51940
51941
51942
51943
51944
51945
51946
51947
51948
51949
51950
51951
51952
51953
51954
51955
51956
51957
51958
51959
51960
51961
51962
51963
51964
51965
51966
51967
51968
51969
51970
51971
51972
51973
51974
51975
51976
51977
51978
51979
51980
51981
51982
51983
51984
51985
51986
51987
51988
51989
51990
51991
51992
51993
51994
51995
51996
51997
51998
51999
52000
52001
52002
52003
52004
52005
52006
52007
52008
52009
52010
52011
52012
52013
52014
52015
52016
52017
52018
52019
52020
52021
52022
52023
52024
52025
52026
52027
52028
52029
52030
52031
52032
52033
52034
52035
52036
52037
52038
52039
52040
52041
52042
52043
52044
52045
52046
52047
52048
52049
52050
52051
52052
52053
52054
52055
52056
52057
52058
52059
52060
52061
52062
52063
52064
52065
52066
52067
52068
52069
52070
52071
52072
52073
52074
52075
52076
52077
52078
52079
52080
52081
52082
52083
52084
52085
52086
52087
52088
52089
52090
52091
52092
52093
52094
52095
52096
52097
52098
52099
52100
52101
52102
52103
52104
52105
52106
52107
52108
52109
52110
52111
52112
52113
52114
52115
52116
52117
52118
52119
52120
52121
52122
52123
52124
52125
52126
52127
52128
52129
52130
52131
52132
52133
52134
52135
52136
52137
52138
52139
52140
52141
52142
52143
52144
52145
52146
52147
52148
52149
52150
52151
52152
52153
52154
52155
52156
52157
52158
52159
52160
52161
52162
52163
52164
52165
52166
52167
52168
52169
52170
52171
52172
52173
52174
52175
52176
52177
52178
52179
52180
52181
52182
52183
52184
52185
52186
52187
52188
52189
52190
52191
52192
52193
52194
52195
52196
52197
52198
52199
52200
52201
52202
52203
52204
52205
52206
52207
52208
52209
52210
52211
52212
52213
52214
52215
52216
52217
52218
52219
52220
52221
52222
52223
52224
52225
52226
52227
52228
52229
52230
52231
52232
52233
52234
52235
52236
52237
52238
52239
52240
52241
52242
52243
52244
52245
52246
52247
52248
52249
52250
52251
52252
52253
52254
52255
52256
52257
52258
52259
52260
52261
52262
52263
52264
52265
52266
52267
52268
52269
52270
52271
52272
52273
52274
52275
52276
52277
52278
52279
52280
52281
52282
52283
52284
52285
52286
52287
52288
52289
52290
52291
52292
52293
52294
52295
52296
52297
52298
52299
52300
52301
52302
52303
52304
52305
52306
52307
52308
52309
52310
52311
52312
52313
52314
52315
52316
52317
52318
52319
52320
52321
52322
52323
52324
52325
52326
52327
52328
52329
52330
52331
52332
52333
52334
52335
52336
52337
52338
52339
52340
52341
52342
52343
52344
52345
52346
52347
52348
52349
52350
52351
52352
52353
52354
52355
52356
52357
52358
52359
52360
52361
52362
52363
52364
52365
52366
52367
52368
52369
52370
52371
52372
52373
52374
52375
52376
52377
52378
52379
52380
52381
52382
52383
52384
52385
52386
52387
52388
52389
52390
52391
52392
52393
52394
52395
52396
52397
52398
52399
52400
52401
52402
52403
52404
52405
52406
52407
52408
52409
52410
52411
52412
52413
52414
52415
52416
52417
52418
52419
52420
52421
52422
52423
52424
52425
52426
52427
52428
52429
52430
52431
52432
52433
52434
52435
52436
52437
52438
52439
52440
52441
52442
52443
52444
52445
52446
52447
52448
52449
52450
52451
52452
52453
52454
52455
52456
52457
52458
52459
52460
52461
52462
52463
52464
52465
52466
52467
52468
52469
52470
52471
52472
52473
52474
52475
52476
52477
52478
52479
52480
52481
52482
52483
52484
52485
52486
52487
52488
52489
52490
52491
52492
52493
52494
52495
52496
52497
52498
52499
52500
52501
52502
52503
52504
52505
52506
52507
52508
52509
52510
52511
52512
52513
52514
52515
52516
52517
52518
52519
52520
52521
52522
52523
52524
52525
52526
52527
52528
52529
52530
52531
52532
52533
52534
52535
52536
52537
52538
52539
52540
52541
52542
52543
52544
52545
52546
52547
52548
52549
52550
52551
52552
52553
52554
52555
52556
52557
52558
52559
52560
52561
52562
52563
52564
52565
52566
52567
52568
52569
52570
52571
52572
52573
52574
52575
52576
52577
52578
52579
52580
52581
52582
52583
52584
52585
52586
52587
52588
52589
52590
52591
52592
52593
52594
52595
52596
52597
52598
52599
52600
52601
52602
52603
52604
52605
52606
52607
52608
52609
52610
52611
52612
52613
52614
52615
52616
52617
52618
52619
52620
52621
52622
52623
52624
52625
52626
52627
52628
52629
52630
52631
52632
52633
52634
52635
52636
52637
52638
52639
52640
52641
52642
52643
52644
52645
52646
52647
52648
52649
52650
52651
52652
52653
52654
52655
52656
52657
52658
52659
52660
52661
52662
52663
52664
52665
52666
52667
52668
52669
52670
52671
52672
52673
52674
52675
52676
52677
52678
52679
52680
52681
52682
52683
52684
52685
52686
52687
52688
52689
52690
52691
52692
52693
52694
52695
52696
52697
52698
52699
52700
52701
52702
52703
52704
52705
52706
52707
52708
52709
52710
52711
52712
52713
52714
52715
52716
52717
52718
52719
52720
52721
52722
52723
52724
52725
52726
52727
52728
52729
52730
52731
52732
52733
52734
52735
52736
52737
52738
52739
52740
52741
52742
52743
52744
52745
52746
52747
52748
52749
52750
52751
52752
52753
52754
52755
52756
52757
52758
52759
52760
52761
52762
52763
52764
52765
52766
52767
52768
52769
52770
52771
52772
52773
52774
52775
52776
52777
52778
52779
52780
52781
52782
52783
52784
52785
52786
52787
52788
52789
52790
52791
52792
52793
52794
52795
52796
52797
52798
52799
52800
52801
52802
52803
52804
52805
52806
52807
52808
52809
52810
52811
52812
52813
52814
52815
52816
52817
52818
52819
52820
52821
52822
52823
52824
52825
52826
52827
52828
52829
52830
52831
52832
52833
52834
52835
52836
52837
52838
52839
52840
52841
52842
52843
52844
52845
52846
52847
52848
52849
52850
52851
52852
52853
52854
52855
52856
52857
52858
52859
52860
52861
52862
52863
52864
52865
52866
52867
52868
52869
52870
52871
52872
52873
52874
52875
52876
52877
52878
52879
52880
52881
52882
52883
52884
52885
52886
52887
52888
52889
52890
52891
52892
52893
52894
52895
52896
52897
52898
52899
52900
52901
52902
52903
52904
52905
52906
52907
52908
52909
52910
52911
52912
52913
52914
52915
52916
52917
52918
52919
52920
52921
52922
52923
52924
52925
52926
52927
52928
52929
52930
52931
52932
52933
52934
52935
52936
52937
52938
52939
52940
52941
52942
52943
52944
52945
52946
52947
52948
52949
52950
52951
52952
52953
52954
52955
52956
52957
52958
52959
52960
52961
52962
52963
52964
52965
52966
52967
52968
52969
52970
52971
52972
52973
52974
52975
52976
52977
52978
52979
52980
52981
52982
52983
52984
52985
52986
52987
52988
52989
52990
52991
52992
52993
52994
52995
52996
52997
52998
52999
53000
53001
53002
53003
53004
53005
53006
53007
53008
53009
53010
53011
53012
53013
53014
53015
53016
53017
53018
53019
53020
53021
53022
53023
53024
53025
53026
53027
53028
53029
53030
53031
53032
53033
53034
53035
53036
53037
53038
53039
53040
53041
53042
53043
53044
53045
53046
53047
53048
53049
53050
53051
53052
53053
53054
53055
53056
53057
53058
53059
53060
53061
53062
53063
53064
53065
53066
53067
53068
53069
53070
53071
53072
53073
53074
53075
53076
53077
53078
53079
53080
53081
53082
53083
53084
53085
53086
53087
53088
53089
53090
53091
53092
53093
53094
53095
53096
53097
53098
53099
53100
53101
53102
53103
53104
53105
53106
53107
53108
53109
53110
53111
53112
53113
53114
53115
53116
53117
53118
53119
53120
53121
53122
53123
53124
53125
53126
53127
53128
53129
53130
53131
53132
53133
53134
53135
53136
53137
53138
53139
53140
53141
53142
53143
53144
53145
53146
53147
53148
53149
53150
53151
53152
53153
53154
53155
53156
53157
53158
53159
53160
53161
53162
53163
53164
53165
53166
53167
53168
53169
53170
53171
53172
53173
53174
53175
53176
53177
53178
53179
53180
53181
53182
53183
53184
53185
53186
53187
53188
53189
53190
53191
53192
53193
53194
53195
53196
53197
53198
53199
53200
53201
53202
53203
53204
53205
53206
53207
53208
53209
53210
53211
53212
53213
53214
53215
53216
53217
53218
53219
53220
53221
53222
53223
53224
53225
53226
53227
53228
53229
53230
53231
53232
53233
53234
53235
53236
53237
53238
53239
53240
53241
53242
53243
53244
53245
53246
53247
53248
53249
53250
53251
53252
53253
53254
53255
53256
53257
53258
53259
53260
53261
53262
53263
53264
53265
53266
53267
53268
53269
53270
53271
53272
53273
53274
53275
53276
53277
53278
53279
53280
53281
53282
53283
53284
53285
53286
53287
53288
53289
53290
53291
53292
53293
53294
53295
53296
53297
53298
53299
53300
53301
53302
53303
53304
53305
53306
53307
53308
53309
53310
53311
53312
53313
53314
53315
53316
53317
53318
53319
53320
53321
53322
53323
53324
53325
53326
53327
53328
53329
53330
53331
53332
53333
53334
53335
53336
53337
53338
53339
53340
53341
53342
53343
53344
53345
53346
53347
53348
53349
53350
53351
53352
53353
53354
53355
53356
53357
53358
53359
53360
53361
53362
53363
53364
53365
53366
53367
53368
53369
53370
53371
53372
53373
53374
53375
53376
53377
53378
53379
53380
53381
53382
53383
53384
53385
53386
53387
53388
53389
53390
53391
53392
53393
53394
53395
53396
53397
53398
53399
53400
53401
53402
53403
53404
53405
53406
53407
53408
53409
53410
53411
53412
53413
53414
53415
53416
53417
53418
53419
53420
53421
53422
53423
53424
53425
53426
53427
53428
53429
53430
53431
53432
53433
53434
53435
53436
53437
53438
53439
53440
53441
53442
53443
53444
53445
53446
53447
53448
53449
53450
53451
53452
53453
53454
53455
53456
53457
53458
53459
53460
53461
53462
53463
53464
53465
53466
53467
53468
53469
53470
53471
53472
53473
53474
53475
53476
53477
53478
53479
53480
53481
53482
53483
53484
53485
53486
53487
53488
53489
53490
53491
53492
53493
53494
53495
53496
53497
53498
53499
53500
53501
53502
53503
53504
53505
53506
53507
53508
53509
53510
53511
53512
53513
53514
53515
53516
53517
53518
53519
53520
53521
53522
53523
53524
53525
53526
53527
53528
53529
53530
53531
53532
53533
53534
53535
53536
53537
53538
53539
53540
53541
53542
53543
53544
53545
53546
53547
53548
53549
53550
53551
53552
53553
53554
53555
53556
53557
53558
53559
53560
53561
53562
53563
53564
53565
53566
53567
53568
53569
53570
53571
53572
53573
53574
53575
53576
53577
53578
53579
53580
53581
53582
53583
53584
53585
53586
53587
53588
53589
53590
53591
53592
53593
53594
53595
53596
53597
53598
53599
53600
53601
53602
53603
53604
53605
53606
53607
53608
53609
53610
53611
53612
53613
53614
53615
53616
53617
53618
53619
53620
53621
53622
53623
53624
53625
53626
53627
53628
53629
53630
53631
53632
53633
53634
53635
53636
53637
53638
53639
53640
53641
53642
53643
53644
53645
53646
53647
53648
53649
53650
53651
53652
53653
53654
53655
53656
53657
53658
53659
53660
53661
53662
53663
53664
53665
53666
53667
53668
53669
53670
53671
53672
53673
53674
53675
53676
53677
53678
53679
53680
53681
53682
53683
53684
53685
53686
53687
53688
53689
53690
53691
53692
53693
53694
53695
53696
53697
53698
53699
53700
53701
53702
53703
53704
53705
53706
53707
53708
53709
53710
53711
53712
53713
53714
53715
53716
53717
53718
53719
53720
53721
53722
53723
53724
53725
53726
53727
53728
53729
53730
53731
53732
53733
53734
53735
53736
53737
53738
53739
53740
53741
53742
53743
53744
53745
53746
53747
53748
53749
53750
53751
53752
53753
53754
53755
53756
53757
53758
53759
53760
53761
53762
53763
53764
53765
53766
53767
53768
53769
53770
53771
53772
53773
53774
53775
53776
53777
53778
53779
53780
53781
53782
53783
53784
53785
53786
53787
53788
53789
53790
53791
53792
53793
53794
53795
53796
53797
53798
53799
53800
53801
53802
53803
53804
53805
53806
53807
53808
53809
53810
53811
53812
53813
53814
53815
53816
53817
53818
53819
53820
53821
53822
53823
53824
53825
53826
53827
53828
53829
53830
53831
53832
53833
53834
53835
53836
53837
53838
53839
53840
53841
53842
53843
53844
53845
53846
53847
53848
53849
53850
53851
53852
53853
53854
53855
53856
53857
53858
53859
53860
53861
53862
53863
53864
53865
53866
53867
53868
53869
53870
53871
53872
53873
53874
53875
53876
53877
53878
53879
53880
53881
53882
53883
53884
53885
53886
53887
53888
53889
53890
53891
53892
53893
53894
53895
53896
53897
53898
53899
53900
53901
53902
53903
53904
53905
53906
53907
53908
53909
53910
53911
53912
53913
53914
53915
53916
53917
53918
53919
53920
53921
53922
53923
53924
53925
53926
53927
53928
53929
53930
53931
53932
53933
53934
53935
53936
53937
53938
53939
53940
53941
53942
53943
53944
53945
53946
53947
53948
53949
53950
53951
53952
53953
53954
53955
53956
53957
53958
53959
53960
53961
53962
53963
53964
53965
53966
53967
53968
53969
53970
53971
53972
53973
53974
53975
53976
53977
53978
53979
53980
53981
53982
53983
53984
53985
53986
53987
53988
53989
53990
53991
53992
53993
53994
53995
53996
53997
53998
53999
54000
54001
54002
54003
54004
54005
54006
54007
54008
54009
54010
54011
54012
54013
54014
54015
54016
54017
54018
54019
54020
54021
54022
54023
54024
54025
54026
54027
54028
54029
54030
54031
54032
54033
54034
54035
54036
54037
54038
54039
54040
54041
54042
54043
54044
54045
54046
54047
54048
54049
54050
54051
54052
54053
54054
54055
54056
54057
54058
54059
54060
54061
54062
54063
54064
54065
54066
54067
54068
54069
54070
54071
54072
54073
54074
54075
54076
54077
54078
54079
54080
54081
54082
54083
54084
54085
54086
54087
54088
54089
54090
54091
54092
54093
54094
54095
54096
54097
54098
54099
54100
54101
54102
54103
54104
54105
54106
54107
54108
54109
54110
54111
54112
54113
54114
54115
54116
54117
54118
54119
54120
54121
54122
54123
54124
54125
54126
54127
54128
54129
54130
54131
54132
54133
54134
54135
54136
54137
54138
54139
54140
54141
54142
54143
54144
54145
54146
54147
54148
54149
54150
54151
54152
54153
54154
54155
54156
54157
54158
54159
54160
54161
54162
54163
54164
54165
54166
54167
54168
54169
54170
54171
54172
54173
54174
54175
54176
54177
54178
54179
54180
54181
54182
54183
54184
54185
54186
54187
54188
54189
54190
54191
54192
54193
54194
54195
54196
54197
54198
54199
54200
54201
54202
54203
54204
54205
54206
54207
54208
54209
54210
54211
54212
54213
54214
54215
54216
54217
54218
54219
54220
54221
54222
54223
54224
54225
54226
54227
54228
54229
54230
54231
54232
54233
54234
54235
54236
54237
54238
54239
54240
54241
54242
54243
54244
54245
54246
54247
54248
54249
54250
54251
54252
54253
54254
54255
54256
54257
54258
54259
54260
54261
54262
54263
54264
54265
54266
54267
54268
54269
54270
54271
54272
54273
54274
54275
54276
54277
54278
54279
54280
54281
54282
54283
54284
54285
54286
54287
54288
54289
54290
54291
54292
54293
54294
54295
54296
54297
54298
54299
54300
54301
54302
54303
54304
54305
54306
54307
54308
54309
54310
54311
54312
54313
54314
54315
54316
54317
54318
54319
54320
54321
54322
54323
54324
54325
54326
54327
54328
54329
54330
54331
54332
54333
54334
54335
54336
54337
54338
54339
54340
54341
54342
54343
54344
54345
54346
54347
54348
54349
54350
54351
54352
54353
54354
54355
54356
54357
54358
54359
54360
54361
54362
54363
54364
54365
54366
54367
54368
54369
54370
54371
54372
54373
54374
54375
54376
54377
54378
54379
54380
54381
54382
54383
54384
54385
54386
54387
54388
54389
54390
54391
54392
54393
54394
54395
54396
54397
54398
54399
54400
54401
54402
54403
54404
54405
54406
54407
54408
54409
54410
54411
54412
54413
54414
54415
54416
54417
54418
54419
54420
54421
54422
54423
54424
54425
54426
54427
54428
54429
54430
54431
54432
54433
54434
54435
54436
54437
54438
54439
54440
54441
54442
54443
54444
54445
54446
54447
54448
54449
54450
54451
54452
54453
54454
54455
54456
54457
54458
54459
54460
54461
54462
54463
54464
54465
54466
54467
54468
54469
54470
54471
54472
54473
54474
54475
54476
54477
54478
54479
54480
54481
54482
54483
54484
54485
54486
54487
54488
54489
54490
54491
54492
54493
54494
54495
54496
54497
54498
54499
54500
54501
54502
54503
54504
54505
54506
54507
54508
54509
54510
54511
54512
54513
54514
54515
54516
54517
54518
54519
54520
54521
54522
54523
54524
54525
54526
54527
54528
54529
54530
54531
54532
54533
54534
54535
54536
54537
54538
54539
54540
54541
54542
54543
54544
54545
54546
54547
54548
54549
54550
54551
54552
54553
54554
54555
54556
54557
54558
54559
54560
54561
54562
54563
54564
54565
54566
54567
54568
54569
54570
54571
54572
54573
54574
54575
54576
54577
54578
54579
54580
54581
54582
54583
54584
54585
54586
54587
54588
54589
54590
54591
54592
54593
54594
54595
54596
54597
54598
54599
54600
54601
54602
54603
54604
54605
54606
54607
54608
54609
54610
54611
54612
54613
54614
54615
54616
54617
54618
54619
54620
54621
54622
54623
54624
54625
54626
54627
54628
54629
54630
54631
54632
54633
54634
54635
54636
54637
54638
54639
54640
54641
54642
54643
54644
54645
54646
54647
54648
54649
54650
54651
54652
54653
54654
54655
54656
54657
54658
54659
54660
54661
54662
54663
54664
54665
54666
54667
54668
54669
54670
54671
54672
54673
54674
54675
54676
54677
54678
54679
54680
54681
54682
54683
54684
54685
54686
54687
54688
54689
54690
54691
54692
54693
54694
54695
54696
54697
54698
54699
54700
54701
54702
54703
54704
54705
54706
54707
54708
54709
54710
54711
54712
54713
54714
54715
54716
54717
54718
54719
54720
54721
54722
54723
54724
54725
54726
54727
54728
54729
54730
54731
54732
54733
54734
54735
54736
54737
54738
54739
54740
54741
54742
54743
54744
54745
54746
54747
54748
54749
54750
54751
54752
54753
54754
54755
54756
54757
54758
54759
54760
54761
54762
54763
54764
54765
54766
54767
54768
54769
54770
54771
54772
54773
54774
54775
54776
54777
54778
54779
54780
54781
54782
54783
54784
54785
54786
54787
54788
54789
54790
54791
54792
54793
54794
54795
54796
54797
54798
54799
54800
54801
54802
54803
54804
54805
54806
54807
54808
54809
54810
54811
54812
54813
54814
54815
54816
54817
54818
54819
54820
54821
54822
54823
54824
54825
54826
54827
54828
54829
54830
54831
54832
54833
54834
54835
54836
54837
54838
54839
54840
54841
54842
54843
54844
54845
54846
54847
54848
54849
54850
54851
54852
54853
54854
54855
54856
54857
54858
54859
54860
54861
54862
54863
54864
54865
54866
54867
54868
54869
54870
54871
54872
54873
54874
54875
54876
54877
54878
54879
54880
54881
54882
54883
54884
54885
54886
54887
54888
54889
54890
54891
54892
54893
54894
54895
54896
54897
54898
54899
54900
54901
54902
54903
54904
54905
54906
54907
54908
54909
54910
54911
54912
54913
54914
54915
54916
54917
54918
54919
54920
54921
54922
54923
54924
54925
54926
54927
54928
54929
54930
54931
54932
54933
54934
54935
54936
54937
54938
54939
54940
54941
54942
54943
54944
54945
54946
54947
54948
54949
54950
54951
54952
54953
54954
54955
54956
54957
54958
54959
54960
54961
54962
54963
54964
54965
54966
54967
54968
54969
54970
54971
54972
54973
54974
54975
54976
54977
54978
54979
54980
54981
54982
54983
54984
54985
54986
54987
54988
54989
54990
54991
54992
54993
54994
54995
54996
54997
54998
54999
55000
55001
55002
55003
55004
55005
55006
55007
55008
55009
55010
55011
55012
55013
55014
55015
55016
55017
55018
55019
55020
55021
55022
55023
55024
55025
55026
55027
55028
55029
55030
55031
55032
55033
55034
55035
55036
55037
55038
55039
55040
55041
55042
55043
55044
55045
55046
55047
55048
55049
55050
55051
55052
55053
55054
55055
55056
55057
55058
55059
55060
55061
55062
55063
55064
55065
55066
55067
55068
55069
55070
55071
55072
55073
55074
55075
55076
55077
55078
55079
55080
55081
55082
55083
55084
55085
55086
55087
55088
55089
55090
55091
55092
55093
55094
55095
55096
55097
55098
55099
55100
55101
55102
55103
55104
55105
55106
55107
55108
55109
55110
55111
55112
55113
55114
55115
55116
55117
55118
55119
55120
55121
55122
55123
55124
55125
55126
55127
55128
55129
55130
55131
55132
55133
55134
55135
55136
55137
55138
55139
55140
55141
55142
55143
55144
55145
55146
55147
55148
55149
55150
55151
55152
55153
55154
55155
55156
55157
55158
55159
55160
55161
55162
55163
55164
55165
55166
55167
55168
55169
55170
55171
55172
55173
55174
55175
55176
55177
55178
55179
55180
55181
55182
55183
55184
55185
55186
55187
55188
55189
55190
55191
55192
55193
55194
55195
55196
55197
55198
55199
55200
55201
55202
55203
55204
55205
55206
55207
55208
55209
55210
55211
55212
55213
55214
55215
55216
55217
55218
55219
55220
55221
55222
55223
55224
55225
55226
55227
55228
55229
55230
55231
55232
55233
55234
55235
55236
55237
55238
55239
55240
55241
55242
55243
55244
55245
55246
55247
55248
55249
55250
55251
55252
55253
55254
55255
55256
55257
55258
55259
55260
55261
55262
55263
55264
55265
55266
55267
55268
55269
55270
55271
55272
55273
55274
55275
55276
55277
55278
55279
55280
55281
55282
55283
55284
55285
55286
55287
55288
55289
55290
55291
55292
55293
55294
55295
55296
55297
55298
55299
55300
55301
55302
55303
55304
55305
55306
55307
55308
55309
55310
55311
55312
55313
55314
55315
55316
55317
55318
55319
55320
55321
55322
55323
55324
55325
55326
55327
55328
55329
55330
55331
55332
55333
55334
55335
55336
55337
55338
55339
55340
55341
55342
55343
55344
55345
55346
55347
55348
55349
55350
55351
55352
55353
55354
55355
55356
55357
55358
55359
55360
55361
55362
55363
55364
55365
55366
55367
55368
55369
55370
55371
55372
55373
55374
55375
55376
55377
55378
55379
55380
55381
55382
55383
55384
55385
55386
55387
55388
55389
55390
55391
55392
55393
55394
55395
55396
55397
55398
55399
55400
55401
55402
55403
55404
55405
55406
55407
55408
55409
55410
55411
55412
55413
55414
55415
55416
55417
55418
55419
55420
55421
55422
55423
55424
55425
55426
55427
55428
55429
55430
55431
55432
55433
55434
55435
55436
55437
55438
55439
55440
55441
55442
55443
55444
55445
55446
55447
55448
55449
55450
55451
55452
55453
55454
55455
55456
55457
55458
55459
55460
55461
55462
55463
55464
55465
55466
55467
55468
55469
55470
55471
55472
55473
55474
55475
55476
55477
55478
55479
55480
55481
55482
55483
55484
55485
55486
55487
55488
55489
55490
55491
55492
55493
55494
55495
55496
55497
55498
55499
55500
55501
55502
55503
55504
55505
55506
55507
55508
55509
55510
55511
55512
55513
55514
55515
55516
55517
55518
55519
55520
55521
55522
55523
55524
55525
55526
55527
55528
55529
55530
55531
55532
55533
55534
55535
55536
55537
55538
55539
55540
55541
55542
55543
55544
55545
55546
55547
55548
55549
55550
55551
55552
55553
55554
55555
55556
55557
55558
55559
55560
55561
55562
55563
55564
55565
55566
55567
55568
55569
55570
55571
55572
55573
55574
55575
55576
55577
55578
55579
55580
55581
55582
55583
55584
55585
55586
55587
55588
55589
55590
55591
55592
55593
55594
55595
55596
55597
55598
55599
55600
55601
55602
55603
55604
55605
55606
55607
55608
55609
55610
55611
55612
55613
55614
55615
55616
55617
55618
55619
55620
55621
55622
55623
55624
55625
55626
55627
55628
55629
55630
55631
55632
55633
55634
55635
55636
55637
55638
55639
55640
55641
55642
55643
55644
55645
55646
55647
55648
55649
55650
55651
55652
55653
55654
55655
55656
55657
55658
55659
55660
55661
55662
55663
55664
55665
55666
55667
55668
55669
55670
55671
55672
55673
55674
55675
55676
55677
55678
55679
55680
55681
55682
55683
55684
55685
55686
55687
55688
55689
55690
55691
55692
55693
55694
55695
55696
55697
55698
55699
55700
55701
55702
55703
55704
55705
55706
55707
55708
55709
55710
55711
55712
55713
55714
55715
55716
55717
55718
55719
55720
55721
55722
55723
55724
55725
55726
55727
55728
55729
55730
55731
55732
55733
55734
55735
55736
55737
55738
55739
55740
55741
55742
55743
55744
55745
55746
55747
55748
55749
55750
55751
55752
55753
55754
55755
55756
55757
55758
55759
55760
55761
55762
55763
55764
55765
55766
55767
55768
55769
55770
55771
55772
55773
55774
55775
55776
55777
55778
55779
55780
55781
55782
55783
55784
55785
55786
55787
55788
55789
55790
55791
55792
55793
55794
55795
55796
55797
55798
55799
55800
55801
55802
55803
55804
55805
55806
55807
55808
55809
55810
55811
55812
55813
55814
55815
55816
55817
55818
55819
55820
55821
55822
55823
55824
55825
55826
55827
55828
55829
55830
55831
55832
55833
55834
55835
55836
55837
55838
55839
55840
55841
55842
55843
55844
55845
55846
55847
55848
55849
55850
55851
55852
55853
55854
55855
55856
55857
55858
55859
55860
55861
55862
55863
55864
55865
55866
55867
55868
55869
55870
55871
55872
55873
55874
55875
55876
55877
55878
55879
55880
55881
55882
55883
55884
55885
55886
55887
55888
55889
55890
55891
55892
55893
55894
55895
55896
55897
55898
55899
55900
55901
55902
55903
55904
55905
55906
55907
55908
55909
55910
55911
55912
55913
55914
55915
55916
55917
55918
55919
55920
55921
55922
55923
55924
55925
55926
55927
55928
55929
55930
55931
55932
55933
55934
55935
55936
55937
55938
55939
55940
55941
55942
55943
55944
55945
55946
55947
55948
55949
55950
55951
55952
55953
55954
55955
55956
55957
55958
55959
55960
55961
55962
55963
55964
55965
55966
55967
55968
55969
55970
55971
55972
55973
55974
55975
55976
55977
55978
55979
55980
55981
55982
55983
55984
55985
55986
55987
55988
55989
55990
55991
55992
55993
55994
55995
55996
55997
55998
55999
56000
56001
56002
56003
56004
56005
56006
56007
56008
56009
56010
56011
56012
56013
56014
56015
56016
56017
56018
56019
56020
56021
56022
56023
56024
56025
56026
56027
56028
56029
56030
56031
56032
56033
56034
56035
56036
56037
56038
56039
56040
56041
56042
56043
56044
56045
56046
56047
56048
56049
56050
56051
56052
56053
56054
56055
56056
56057
56058
56059
56060
56061
56062
56063
56064
56065
56066
56067
56068
56069
56070
56071
56072
56073
56074
56075
56076
56077
56078
56079
56080
56081
56082
56083
56084
56085
56086
56087
56088
56089
56090
56091
56092
56093
56094
56095
56096
56097
56098
56099
56100
56101
56102
56103
56104
56105
56106
56107
56108
56109
56110
56111
56112
56113
56114
56115
56116
56117
56118
56119
56120
56121
56122
56123
56124
56125
56126
56127
56128
56129
56130
56131
56132
56133
56134
56135
56136
56137
56138
56139
56140
56141
56142
56143
56144
56145
56146
56147
56148
56149
56150
56151
56152
56153
56154
56155
56156
56157
56158
56159
56160
56161
56162
56163
56164
56165
56166
56167
56168
56169
56170
56171
56172
56173
56174
56175
56176
56177
56178
56179
56180
56181
56182
56183
56184
56185
56186
56187
56188
56189
56190
56191
56192
56193
56194
56195
56196
56197
56198
56199
56200
56201
56202
56203
56204
56205
56206
56207
56208
56209
56210
56211
56212
56213
56214
56215
56216
56217
56218
56219
56220
56221
56222
56223
56224
56225
56226
56227
56228
56229
56230
56231
56232
56233
56234
56235
56236
56237
56238
56239
56240
56241
56242
56243
56244
56245
56246
56247
56248
56249
56250
56251
56252
56253
56254
56255
56256
56257
56258
56259
56260
56261
56262
56263
56264
56265
56266
56267
56268
56269
56270
56271
56272
56273
56274
56275
56276
56277
56278
56279
56280
56281
56282
56283
56284
56285
56286
56287
56288
56289
56290
56291
56292
56293
56294
56295
56296
56297
56298
56299
56300
56301
56302
56303
56304
56305
56306
56307
56308
56309
56310
56311
56312
56313
56314
56315
56316
56317
56318
56319
56320
56321
56322
56323
56324
56325
56326
56327
56328
56329
56330
56331
56332
56333
56334
56335
56336
56337
56338
56339
56340
56341
56342
56343
56344
56345
56346
56347
56348
56349
56350
56351
56352
56353
56354
56355
56356
56357
56358
56359
56360
56361
56362
56363
56364
56365
56366
56367
56368
56369
56370
56371
56372
56373
56374
56375
56376
56377
56378
56379
56380
56381
56382
56383
56384
56385
56386
56387
56388
56389
56390
56391
56392
56393
56394
56395
56396
56397
56398
56399
56400
56401
56402
56403
56404
56405
56406
56407
56408
56409
56410
56411
56412
56413
56414
56415
56416
56417
56418
56419
56420
56421
56422
56423
56424
56425
56426
56427
56428
56429
56430
56431
56432
56433
56434
56435
56436
56437
56438
56439
56440
56441
56442
56443
56444
56445
56446
56447
56448
56449
56450
56451
56452
56453
56454
56455
56456
56457
56458
56459
56460
56461
56462
56463
56464
56465
56466
56467
56468
56469
56470
56471
56472
56473
56474
56475
56476
56477
56478
56479
56480
56481
56482
56483
56484
56485
56486
56487
56488
56489
56490
56491
56492
56493
56494
56495
56496
56497
56498
56499
56500
56501
56502
56503
56504
56505
56506
56507
56508
56509
56510
56511
56512
56513
56514
56515
56516
56517
56518
56519
56520
56521
56522
56523
56524
56525
56526
56527
56528
56529
56530
56531
56532
56533
56534
56535
56536
56537
56538
56539
56540
56541
56542
56543
56544
56545
56546
56547
56548
56549
56550
56551
56552
56553
56554
56555
56556
56557
56558
56559
56560
56561
56562
56563
56564
56565
56566
56567
56568
56569
56570
56571
56572
56573
56574
56575
56576
56577
56578
56579
56580
56581
56582
56583
56584
56585
56586
56587
56588
56589
56590
56591
56592
56593
56594
56595
56596
56597
56598
56599
56600
56601
56602
56603
56604
56605
56606
56607
56608
56609
56610
56611
56612
56613
56614
56615
56616
56617
56618
56619
56620
56621
56622
56623
56624
56625
56626
56627
56628
56629
56630
56631
56632
56633
56634
56635
56636
56637
56638
56639
56640
56641
56642
56643
56644
56645
56646
56647
56648
56649
56650
56651
56652
56653
56654
56655
56656
56657
56658
56659
56660
56661
56662
56663
56664
56665
56666
56667
56668
56669
56670
56671
56672
56673
56674
56675
56676
56677
56678
56679
56680
56681
56682
56683
56684
56685
56686
56687
56688
56689
56690
56691
56692
56693
56694
56695
56696
56697
56698
56699
56700
56701
56702
56703
56704
56705
56706
56707
56708
56709
56710
56711
56712
56713
56714
56715
56716
56717
56718
56719
56720
56721
56722
56723
56724
56725
56726
56727
56728
56729
56730
56731
56732
56733
56734
56735
56736
56737
56738
56739
56740
56741
56742
56743
56744
56745
56746
56747
56748
56749
56750
56751
56752
56753
56754
56755
56756
56757
56758
56759
56760
56761
56762
56763
56764
56765
56766
56767
56768
56769
56770
56771
56772
56773
56774
56775
56776
56777
56778
56779
56780
56781
56782
56783
56784
56785
56786
56787
56788
56789
56790
56791
56792
56793
56794
56795
56796
56797
56798
56799
56800
56801
56802
56803
56804
56805
56806
56807
56808
56809
56810
56811
56812
56813
56814
56815
56816
56817
56818
56819
56820
56821
56822
56823
56824
56825
56826
56827
56828
56829
56830
56831
56832
56833
56834
56835
56836
56837
56838
56839
56840
56841
56842
56843
56844
56845
56846
56847
56848
56849
56850
56851
56852
56853
56854
56855
56856
56857
56858
56859
56860
56861
56862
56863
56864
56865
56866
56867
56868
56869
56870
56871
56872
56873
56874
56875
56876
56877
56878
56879
56880
56881
56882
56883
56884
56885
56886
56887
56888
56889
56890
56891
56892
56893
56894
56895
56896
56897
56898
56899
56900
56901
56902
56903
56904
56905
56906
56907
56908
56909
56910
56911
56912
56913
56914
56915
56916
56917
56918
56919
56920
56921
56922
56923
56924
56925
56926
56927
56928
56929
56930
56931
56932
56933
56934
56935
56936
56937
56938
56939
56940
56941
56942
56943
56944
56945
56946
56947
56948
56949
56950
56951
56952
56953
56954
56955
56956
56957
56958
56959
56960
56961
56962
56963
56964
56965
56966
56967
56968
56969
56970
56971
56972
56973
56974
56975
56976
56977
56978
56979
56980
56981
56982
56983
56984
56985
56986
56987
56988
56989
56990
56991
56992
56993
56994
56995
56996
56997
56998
56999
57000
57001
57002
57003
57004
57005
57006
57007
57008
57009
57010
57011
57012
57013
57014
57015
57016
57017
57018
57019
57020
57021
57022
57023
57024
57025
57026
57027
57028
57029
57030
57031
57032
57033
57034
57035
57036
57037
57038
57039
57040
57041
57042
57043
57044
57045
57046
57047
57048
57049
57050
57051
57052
57053
57054
57055
57056
57057
57058
57059
57060
57061
57062
57063
57064
57065
57066
57067
57068
57069
57070
57071
57072
57073
57074
57075
57076
57077
57078
57079
57080
57081
57082
57083
57084
57085
57086
57087
57088
57089
57090
57091
57092
57093
57094
57095
57096
57097
57098
57099
57100
57101
57102
57103
57104
57105
57106
57107
57108
57109
57110
57111
57112
57113
57114
57115
57116
57117
57118
57119
57120
57121
57122
57123
57124
57125
57126
57127
57128
57129
57130
57131
57132
57133
57134
57135
57136
57137
57138
57139
57140
57141
57142
57143
57144
57145
57146
57147
57148
57149
57150
57151
57152
57153
57154
57155
57156
57157
57158
57159
57160
57161
57162
57163
57164
57165
57166
57167
57168
57169
57170
57171
57172
57173
57174
57175
57176
57177
57178
57179
57180
57181
57182
57183
57184
57185
57186
57187
57188
57189
57190
57191
57192
57193
57194
57195
57196
57197
57198
57199
57200
57201
57202
57203
57204
57205
57206
57207
57208
57209
57210
57211
57212
57213
57214
57215
57216
57217
57218
57219
57220
57221
57222
57223
57224
57225
57226
57227
57228
57229
57230
57231
57232
57233
57234
57235
57236
57237
57238
57239
57240
57241
57242
57243
57244
57245
57246
57247
57248
57249
57250
57251
57252
57253
57254
57255
57256
57257
57258
57259
57260
57261
57262
57263
57264
57265
57266
57267
57268
57269
57270
57271
57272
57273
57274
57275
57276
57277
57278
57279
57280
57281
57282
57283
57284
57285
57286
57287
57288
57289
57290
57291
57292
57293
57294
57295
57296
57297
57298
57299
57300
57301
57302
57303
57304
57305
57306
57307
57308
57309
57310
57311
57312
57313
57314
57315
57316
57317
57318
57319
57320
57321
57322
57323
57324
57325
57326
57327
57328
57329
57330
57331
57332
57333
57334
57335
57336
57337
57338
57339
57340
57341
57342
57343
57344
57345
57346
57347
57348
57349
57350
57351
57352
57353
57354
57355
57356
57357
57358
57359
57360
57361
57362
57363
57364
57365
57366
57367
57368
57369
57370
57371
57372
57373
57374
57375
57376
57377
57378
57379
57380
57381
57382
57383
57384
57385
57386
57387
57388
57389
57390
57391
57392
57393
57394
57395
57396
57397
57398
57399
57400
57401
57402
57403
57404
57405
57406
57407
57408
57409
57410
57411
57412
57413
57414
57415
57416
57417
57418
57419
57420
57421
57422
57423
57424
57425
57426
57427
57428
57429
57430
57431
57432
57433
57434
57435
57436
57437
57438
57439
57440
57441
57442
57443
57444
57445
57446
57447
57448
57449
57450
57451
57452
57453
57454
57455
57456
57457
57458
57459
57460
57461
57462
57463
57464
57465
57466
57467
57468
57469
57470
57471
57472
57473
57474
57475
57476
57477
57478
57479
57480
57481
57482
57483
57484
57485
57486
57487
57488
57489
57490
57491
57492
57493
57494
57495
57496
57497
57498
57499
57500
57501
57502
57503
57504
57505
57506
57507
57508
57509
57510
57511
57512
57513
57514
57515
57516
57517
57518
57519
57520
57521
57522
57523
57524
57525
57526
57527
57528
57529
57530
57531
57532
57533
57534
57535
57536
57537
57538
57539
57540
57541
57542
57543
57544
57545
57546
57547
57548
57549
57550
57551
57552
57553
57554
57555
57556
57557
57558
57559
57560
57561
57562
57563
57564
57565
57566
57567
57568
57569
57570
57571
57572
57573
57574
57575
57576
57577
57578
57579
57580
57581
57582
57583
57584
57585
57586
57587
57588
57589
57590
57591
57592
57593
57594
57595
57596
57597
57598
57599
57600
57601
57602
57603
57604
57605
57606
57607
57608
57609
57610
57611
57612
57613
57614
57615
57616
57617
57618
57619
57620
57621
57622
57623
57624
57625
57626
57627
57628
57629
57630
57631
57632
57633
57634
57635
57636
57637
57638
57639
57640
57641
57642
57643
57644
57645
57646
57647
57648
57649
57650
57651
57652
57653
57654
57655
57656
57657
57658
57659
57660
57661
57662
57663
57664
57665
57666
57667
57668
57669
57670
57671
57672
57673
57674
57675
57676
57677
57678
57679
57680
57681
57682
57683
57684
57685
57686
57687
57688
57689
57690
57691
57692
57693
57694
57695
57696
57697
57698
57699
57700
57701
57702
57703
57704
57705
57706
57707
57708
57709
57710
57711
57712
57713
57714
57715
57716
57717
57718
57719
57720
57721
57722
57723
57724
57725
57726
57727
57728
57729
57730
57731
57732
57733
57734
57735
57736
57737
57738
57739
57740
57741
57742
57743
57744
57745
57746
57747
57748
57749
57750
57751
57752
57753
57754
57755
57756
57757
57758
57759
57760
57761
57762
57763
57764
57765
57766
57767
57768
57769
57770
57771
57772
57773
57774
57775
57776
57777
57778
57779
57780
57781
57782
57783
57784
57785
57786
57787
57788
57789
57790
57791
57792
57793
57794
57795
57796
57797
57798
57799
57800
57801
57802
57803
57804
57805
57806
57807
57808
57809
57810
57811
57812
57813
57814
57815
57816
57817
57818
57819
57820
57821
57822
57823
57824
57825
57826
57827
57828
57829
57830
57831
57832
57833
57834
57835
57836
57837
57838
57839
57840
57841
57842
57843
57844
57845
57846
57847
57848
57849
57850
57851
57852
57853
57854
57855
57856
57857
57858
57859
57860
57861
57862
57863
57864
57865
57866
57867
57868
57869
57870
57871
57872
57873
57874
57875
57876
57877
57878
57879
57880
57881
57882
57883
57884
57885
57886
57887
57888
57889
57890
57891
57892
57893
57894
57895
57896
57897
57898
57899
57900
57901
57902
57903
57904
57905
57906
57907
57908
57909
57910
57911
57912
57913
57914
57915
57916
57917
57918
57919
57920
57921
57922
57923
57924
57925
57926
57927
57928
57929
57930
57931
57932
57933
57934
57935
57936
57937
57938
57939
57940
57941
57942
57943
57944
57945
57946
57947
57948
57949
57950
57951
57952
57953
57954
57955
57956
57957
57958
57959
57960
57961
57962
57963
57964
57965
57966
57967
57968
57969
57970
57971
57972
57973
57974
57975
57976
57977
57978
57979
57980
57981
57982
57983
57984
57985
57986
57987
57988
57989
57990
57991
57992
57993
57994
57995
57996
57997
57998
57999
58000
58001
58002
58003
58004
58005
58006
58007
58008
58009
58010
58011
58012
58013
58014
58015
58016
58017
58018
58019
58020
58021
58022
58023
58024
58025
58026
58027
58028
58029
58030
58031
58032
58033
58034
58035
58036
58037
58038
58039
58040
58041
58042
58043
58044
58045
58046
58047
58048
58049
58050
58051
58052
58053
58054
58055
58056
58057
58058
58059
58060
58061
58062
58063
58064
58065
58066
58067
58068
58069
58070
58071
58072
58073
58074
58075
58076
58077
58078
58079
58080
58081
58082
58083
58084
58085
58086
58087
58088
58089
58090
58091
58092
58093
58094
58095
58096
58097
58098
58099
58100
58101
58102
58103
58104
58105
58106
58107
58108
58109
58110
58111
58112
58113
58114
58115
58116
58117
58118
58119
58120
58121
58122
58123
58124
58125
58126
58127
58128
58129
58130
58131
58132
58133
58134
58135
58136
58137
58138
58139
58140
58141
58142
58143
58144
58145
58146
58147
58148
58149
58150
58151
58152
58153
58154
58155
58156
58157
58158
58159
58160
58161
58162
58163
58164
58165
58166
58167
58168
58169
58170
58171
58172
58173
58174
58175
58176
58177
58178
58179
58180
58181
58182
58183
58184
58185
58186
58187
58188
58189
58190
58191
58192
58193
58194
58195
58196
58197
58198
58199
58200
58201
58202
58203
58204
58205
58206
58207
58208
58209
58210
58211
58212
58213
58214
58215
58216
58217
58218
58219
58220
58221
58222
58223
58224
58225
58226
58227
58228
58229
58230
58231
58232
58233
58234
58235
58236
58237
58238
58239
58240
58241
58242
58243
58244
58245
58246
58247
58248
58249
58250
58251
58252
58253
58254
58255
58256
58257
58258
58259
58260
58261
58262
58263
58264
58265
58266
58267
58268
58269
58270
58271
58272
58273
58274
58275
58276
58277
58278
58279
58280
58281
58282
58283
58284
58285
58286
58287
58288
58289
58290
58291
58292
58293
58294
58295
58296
58297
58298
58299
58300
58301
58302
58303
58304
58305
58306
58307
58308
58309
58310
58311
58312
58313
58314
58315
58316
58317
58318
58319
58320
58321
58322
58323
58324
58325
58326
58327
58328
58329
58330
58331
58332
58333
58334
58335
58336
58337
58338
58339
58340
58341
58342
58343
58344
58345
58346
58347
58348
58349
58350
58351
58352
58353
58354
58355
58356
58357
58358
58359
58360
58361
58362
58363
58364
58365
58366
58367
58368
58369
58370
58371
58372
58373
58374
58375
58376
58377
58378
58379
58380
58381
58382
58383
58384
58385
58386
58387
58388
58389
58390
58391
58392
58393
58394
58395
58396
58397
58398
58399
58400
58401
58402
58403
58404
58405
58406
58407
58408
58409
58410
58411
58412
58413
58414
58415
58416
58417
58418
58419
58420
58421
58422
58423
58424
58425
58426
58427
58428
58429
58430
58431
58432
58433
58434
58435
58436
58437
58438
58439
58440
58441
58442
58443
58444
58445
58446
58447
58448
58449
58450
58451
58452
58453
58454
58455
58456
58457
58458
58459
58460
58461
58462
58463
58464
58465
58466
58467
58468
58469
58470
58471
58472
58473
58474
58475
58476
58477
58478
58479
58480
58481
58482
58483
58484
58485
58486
58487
58488
58489
58490
58491
58492
58493
58494
58495
58496
58497
58498
58499
58500
58501
58502
58503
58504
58505
58506
58507
58508
58509
58510
58511
58512
58513
58514
58515
58516
58517
58518
58519
58520
58521
58522
58523
58524
58525
58526
58527
58528
58529
58530
58531
58532
58533
58534
58535
58536
58537
58538
58539
58540
58541
58542
58543
58544
58545
58546
58547
58548
58549
58550
58551
58552
58553
58554
58555
58556
58557
58558
58559
58560
58561
58562
58563
58564
58565
58566
58567
58568
58569
58570
58571
58572
58573
58574
58575
58576
58577
58578
58579
58580
58581
58582
58583
58584
58585
58586
58587
58588
58589
58590
58591
58592
58593
58594
58595
58596
58597
58598
58599
58600
58601
58602
58603
58604
58605
58606
58607
58608
58609
58610
58611
58612
58613
58614
58615
58616
58617
58618
58619
58620
58621
58622
58623
58624
58625
58626
58627
58628
58629
58630
58631
58632
58633
58634
58635
58636
58637
58638
58639
58640
58641
58642
58643
58644
58645
58646
58647
58648
58649
58650
58651
58652
58653
58654
58655
58656
58657
58658
58659
58660
58661
58662
58663
58664
58665
58666
58667
58668
58669
58670
58671
58672
58673
58674
58675
58676
58677
58678
58679
58680
58681
58682
58683
58684
58685
58686
58687
58688
58689
58690
58691
58692
58693
58694
58695
58696
58697
58698
58699
58700
58701
58702
58703
58704
58705
58706
58707
58708
58709
58710
58711
58712
58713
58714
58715
58716
58717
58718
58719
58720
58721
58722
58723
58724
58725
58726
58727
58728
58729
58730
58731
58732
58733
58734
58735
58736
58737
58738
58739
58740
58741
58742
58743
58744
58745
58746
58747
58748
58749
58750
58751
58752
58753
58754
58755
58756
58757
58758
58759
58760
58761
58762
58763
58764
58765
58766
58767
58768
58769
58770
58771
58772
58773
58774
58775
58776
58777
58778
58779
58780
58781
58782
58783
58784
58785
58786
58787
58788
58789
58790
58791
58792
58793
58794
58795
58796
58797
58798
58799
58800
58801
58802
58803
58804
58805
58806
58807
58808
58809
58810
58811
58812
58813
58814
58815
58816
58817
58818
58819
58820
58821
58822
58823
58824
58825
58826
58827
58828
58829
58830
58831
58832
58833
58834
58835
58836
58837
58838
58839
58840
58841
58842
58843
58844
58845
58846
58847
58848
58849
58850
58851
58852
58853
58854
58855
58856
58857
58858
58859
58860
58861
58862
58863
58864
58865
58866
58867
58868
58869
58870
58871
58872
58873
58874
58875
58876
58877
58878
58879
58880
58881
58882
58883
58884
58885
58886
58887
58888
58889
58890
58891
58892
58893
58894
58895
58896
58897
58898
58899
58900
58901
58902
58903
58904
58905
58906
58907
58908
58909
58910
58911
58912
58913
58914
58915
58916
58917
58918
58919
58920
58921
58922
58923
58924
58925
58926
58927
58928
58929
58930
58931
58932
58933
58934
58935
58936
58937
58938
58939
58940
58941
58942
58943
58944
58945
58946
58947
58948
58949
58950
58951
58952
58953
58954
58955
58956
58957
58958
58959
58960
58961
58962
58963
58964
58965
58966
58967
58968
58969
58970
58971
58972
58973
58974
58975
58976
58977
58978
58979
58980
58981
58982
58983
58984
58985
58986
58987
58988
58989
58990
58991
58992
58993
58994
58995
58996
58997
58998
58999
59000
59001
59002
59003
59004
59005
59006
59007
59008
59009
59010
59011
59012
59013
59014
59015
59016
59017
59018
59019
59020
59021
59022
59023
59024
59025
59026
59027
59028
59029
59030
59031
59032
59033
59034
59035
59036
59037
59038
59039
59040
59041
59042
59043
59044
59045
59046
59047
59048
59049
59050
59051
59052
59053
59054
59055
59056
59057
59058
59059
59060
59061
59062
59063
59064
59065
59066
59067
59068
59069
59070
59071
59072
59073
59074
59075
59076
59077
59078
59079
59080
59081
59082
59083
59084
59085
59086
59087
59088
59089
59090
59091
59092
59093
59094
59095
59096
59097
59098
59099
59100
59101
59102
59103
59104
59105
59106
59107
59108
59109
59110
59111
59112
59113
59114
59115
59116
59117
59118
59119
59120
59121
59122
59123
59124
59125
59126
59127
59128
59129
59130
59131
59132
59133
59134
59135
59136
59137
59138
59139
59140
59141
59142
59143
59144
59145
59146
59147
59148
59149
59150
59151
59152
59153
59154
59155
59156
59157
59158
59159
59160
59161
59162
59163
59164
59165
59166
59167
59168
59169
59170
59171
59172
59173
59174
59175
59176
59177
59178
59179
59180
59181
59182
59183
59184
59185
59186
59187
59188
59189
59190
59191
59192
59193
59194
59195
59196
59197
59198
59199
59200
59201
59202
59203
59204
59205
59206
59207
59208
59209
59210
59211
59212
59213
59214
59215
59216
59217
59218
59219
59220
59221
59222
59223
59224
59225
59226
59227
59228
59229
59230
59231
59232
59233
59234
59235
59236
59237
59238
59239
59240
59241
59242
59243
59244
59245
59246
59247
59248
59249
59250
59251
59252
59253
59254
59255
59256
59257
59258
59259
59260
59261
59262
59263
59264
59265
59266
59267
59268
59269
59270
59271
59272
59273
59274
59275
59276
59277
59278
59279
59280
59281
59282
59283
59284
59285
59286
59287
59288
59289
59290
59291
59292
59293
59294
59295
59296
59297
59298
59299
59300
59301
59302
59303
59304
59305
59306
59307
59308
59309
59310
59311
59312
59313
59314
59315
59316
59317
59318
59319
59320
59321
59322
59323
59324
59325
59326
59327
59328
59329
59330
59331
59332
59333
59334
59335
59336
59337
59338
59339
59340
59341
59342
59343
59344
59345
59346
59347
59348
59349
59350
59351
59352
59353
59354
59355
59356
59357
59358
59359
59360
59361
59362
59363
59364
59365
59366
59367
59368
59369
59370
59371
59372
59373
59374
59375
59376
59377
59378
59379
59380
59381
59382
59383
59384
59385
59386
59387
59388
59389
59390
59391
59392
59393
59394
59395
59396
59397
59398
59399
59400
59401
59402
59403
59404
59405
59406
59407
59408
59409
59410
59411
59412
59413
59414
59415
59416
59417
59418
59419
59420
59421
59422
59423
59424
59425
59426
59427
59428
59429
59430
59431
59432
59433
59434
59435
59436
59437
59438
59439
59440
59441
59442
59443
59444
59445
59446
59447
59448
59449
59450
59451
59452
59453
59454
59455
59456
59457
59458
59459
59460
59461
59462
59463
59464
59465
59466
59467
59468
59469
59470
59471
59472
59473
59474
59475
59476
59477
59478
59479
59480
59481
59482
59483
59484
59485
59486
59487
59488
59489
59490
59491
59492
59493
59494
59495
59496
59497
59498
59499
59500
59501
59502
59503
59504
59505
59506
59507
59508
59509
59510
59511
59512
59513
59514
59515
59516
59517
59518
59519
59520
59521
59522
59523
59524
59525
59526
59527
59528
59529
59530
59531
59532
59533
59534
59535
59536
59537
59538
59539
59540
59541
59542
59543
59544
59545
59546
59547
59548
59549
59550
59551
59552
59553
59554
59555
59556
59557
59558
59559
59560
59561
59562
59563
59564
59565
59566
59567
59568
59569
59570
59571
59572
59573
59574
59575
59576
59577
59578
59579
59580
59581
59582
59583
59584
59585
59586
59587
59588
59589
59590
59591
59592
59593
59594
59595
59596
59597
59598
59599
59600
59601
59602
59603
59604
59605
59606
59607
59608
59609
59610
59611
59612
59613
59614
59615
59616
59617
59618
59619
59620
59621
59622
59623
59624
59625
59626
59627
59628
59629
59630
59631
59632
59633
59634
59635
59636
59637
59638
59639
59640
59641
59642
59643
59644
59645
59646
59647
59648
59649
59650
59651
59652
59653
59654
59655
59656
59657
59658
59659
59660
59661
59662
59663
59664
59665
59666
59667
59668
59669
59670
59671
59672
59673
59674
59675
59676
59677
59678
59679
59680
59681
59682
59683
59684
59685
59686
59687
59688
59689
59690
59691
59692
59693
59694
59695
59696
59697
59698
59699
59700
59701
59702
59703
59704
59705
59706
59707
59708
59709
59710
59711
59712
59713
59714
59715
59716
59717
59718
59719
59720
59721
59722
59723
59724
59725
59726
59727
59728
59729
59730
59731
59732
59733
59734
59735
59736
59737
59738
59739
59740
59741
59742
59743
59744
59745
59746
59747
59748
59749
59750
59751
59752
59753
59754
59755
59756
59757
59758
59759
59760
59761
59762
59763
59764
59765
59766
59767
59768
59769
59770
59771
59772
59773
59774
59775
59776
59777
59778
59779
59780
59781
59782
59783
59784
59785
59786
59787
59788
59789
59790
59791
59792
59793
59794
59795
59796
59797
59798
59799
59800
59801
59802
59803
59804
59805
59806
59807
59808
59809
59810
59811
59812
59813
59814
59815
59816
59817
59818
59819
59820
59821
59822
59823
59824
59825
59826
59827
59828
59829
59830
59831
59832
59833
59834
59835
59836
59837
59838
59839
59840
59841
59842
59843
59844
59845
59846
59847
59848
59849
59850
59851
59852
59853
59854
59855
59856
59857
59858
59859
59860
59861
59862
59863
59864
59865
59866
59867
59868
59869
59870
59871
59872
59873
59874
59875
59876
59877
59878
59879
59880
59881
59882
59883
59884
59885
59886
59887
59888
59889
59890
59891
59892
59893
59894
59895
59896
59897
59898
59899
59900
59901
59902
59903
59904
59905
59906
59907
59908
59909
59910
59911
59912
59913
59914
59915
59916
59917
59918
59919
59920
59921
59922
59923
59924
59925
59926
59927
59928
59929
59930
59931
59932
59933
59934
59935
59936
59937
59938
59939
59940
59941
59942
59943
59944
59945
59946
59947
59948
59949
59950
59951
59952
59953
59954
59955
59956
59957
59958
59959
59960
59961
59962
59963
59964
59965
59966
59967
59968
59969
59970
59971
59972
59973
59974
59975
59976
59977
59978
59979
59980
59981
59982
59983
59984
59985
59986
59987
59988
59989
59990
59991
59992
59993
59994
59995
59996
59997
59998
59999
60000
60001
60002
60003
60004
60005
60006
60007
60008
60009
60010
60011
60012
60013
60014
60015
60016
60017
60018
60019
60020
60021
60022
60023
60024
60025
60026
60027
60028
60029
60030
60031
60032
60033
60034
60035
60036
60037
60038
60039
60040
60041
60042
60043
60044
60045
60046
60047
60048
60049
60050
60051
60052
60053
60054
60055
60056
60057
60058
60059
60060
60061
60062
60063
60064
60065
60066
60067
60068
60069
60070
60071
60072
60073
60074
60075
60076
60077
60078
60079
60080
60081
60082
60083
60084
60085
60086
60087
60088
60089
60090
60091
60092
60093
60094
60095
60096
60097
60098
60099
60100
60101
60102
60103
60104
60105
60106
60107
60108
60109
60110
60111
60112
60113
60114
60115
60116
60117
60118
60119
60120
60121
60122
60123
60124
60125
60126
60127
60128
60129
60130
60131
60132
60133
60134
60135
60136
60137
60138
60139
60140
60141
60142
60143
60144
60145
60146
60147
60148
60149
60150
60151
60152
60153
60154
60155
60156
60157
60158
60159
60160
60161
60162
60163
60164
60165
60166
60167
60168
60169
60170
60171
60172
60173
60174
60175
60176
60177
60178
60179
60180
60181
60182
60183
60184
60185
60186
60187
60188
60189
60190
60191
60192
60193
60194
60195
60196
60197
60198
60199
60200
60201
60202
60203
60204
60205
60206
60207
60208
60209
60210
60211
60212
60213
60214
60215
60216
60217
60218
60219
60220
60221
60222
60223
60224
60225
60226
60227
60228
60229
60230
60231
60232
60233
60234
60235
60236
60237
60238
60239
60240
60241
60242
60243
60244
60245
60246
60247
60248
60249
60250
60251
60252
60253
60254
60255
60256
60257
60258
60259
60260
60261
60262
60263
60264
60265
60266
60267
60268
60269
60270
60271
60272
60273
60274
60275
60276
60277
60278
60279
60280
60281
60282
60283
60284
60285
60286
60287
60288
60289
60290
60291
60292
60293
60294
60295
60296
60297
60298
60299
60300
60301
60302
60303
60304
60305
60306
60307
60308
60309
60310
60311
60312
60313
60314
60315
60316
60317
60318
60319
60320
60321
60322
60323
60324
60325
60326
60327
60328
60329
60330
60331
60332
60333
60334
60335
60336
60337
60338
60339
60340
60341
60342
60343
60344
60345
60346
60347
60348
60349
60350
60351
60352
60353
60354
60355
60356
60357
60358
60359
60360
60361
60362
60363
60364
60365
60366
60367
60368
60369
60370
60371
60372
60373
60374
60375
60376
60377
60378
60379
60380
60381
60382
60383
60384
60385
60386
60387
60388
60389
60390
60391
60392
60393
60394
60395
60396
60397
60398
60399
60400
60401
60402
60403
60404
60405
60406
60407
60408
60409
60410
60411
60412
60413
60414
60415
60416
60417
60418
60419
60420
60421
60422
60423
60424
60425
60426
60427
60428
60429
60430
60431
60432
60433
60434
60435
60436
60437
60438
60439
60440
60441
60442
60443
60444
60445
60446
60447
60448
60449
60450
60451
60452
60453
60454
60455
60456
60457
60458
60459
60460
60461
60462
60463
60464
60465
60466
60467
60468
60469
60470
60471
60472
60473
60474
60475
60476
60477
60478
60479
60480
60481
60482
60483
60484
60485
60486
60487
60488
60489
60490
60491
60492
60493
60494
60495
60496
60497
60498
60499
60500
60501
60502
60503
60504
60505
60506
60507
60508
60509
60510
60511
60512
60513
60514
60515
60516
60517
60518
60519
60520
60521
60522
60523
60524
60525
60526
60527
60528
60529
60530
60531
60532
60533
60534
60535
60536
60537
60538
60539
60540
60541
60542
60543
60544
60545
60546
60547
60548
60549
60550
60551
60552
60553
60554
60555
60556
60557
60558
60559
60560
60561
60562
60563
60564
60565
60566
60567
60568
60569
60570
60571
60572
60573
60574
60575
60576
60577
60578
60579
60580
60581
60582
60583
60584
60585
60586
60587
60588
60589
60590
60591
60592
60593
60594
60595
60596
60597
60598
60599
60600
60601
60602
60603
60604
60605
60606
60607
60608
60609
60610
60611
60612
60613
60614
60615
60616
60617
60618
60619
60620
60621
60622
60623
60624
60625
60626
60627
60628
60629
60630
60631
60632
60633
60634
60635
60636
60637
60638
60639
60640
60641
60642
60643
60644
60645
60646
60647
60648
60649
60650
60651
60652
60653
60654
60655
60656
60657
60658
60659
60660
60661
60662
60663
60664
60665
60666
60667
60668
60669
60670
60671
60672
60673
60674
60675
60676
60677
60678
60679
60680
60681
60682
60683
60684
60685
60686
60687
60688
60689
60690
60691
60692
60693
60694
60695
60696
60697
60698
60699
60700
60701
60702
60703
60704
60705
60706
60707
60708
60709
60710
60711
60712
60713
60714
60715
60716
60717
60718
60719
60720
60721
60722
60723
60724
60725
60726
60727
60728
60729
60730
60731
60732
60733
60734
60735
60736
60737
60738
60739
60740
60741
60742
60743
60744
60745
60746
60747
60748
60749
60750
60751
60752
60753
60754
60755
60756
60757
60758
60759
60760
60761
60762
60763
60764
60765
60766
60767
60768
60769
60770
60771
60772
60773
60774
60775
60776
60777
60778
60779
60780
60781
60782
60783
60784
60785
60786
60787
60788
60789
60790
60791
60792
60793
60794
60795
60796
60797
60798
60799
60800
60801
60802
60803
60804
60805
60806
60807
60808
60809
60810
60811
60812
60813
60814
60815
60816
60817
60818
60819
60820
60821
60822
60823
60824
60825
60826
60827
60828
60829
60830
60831
60832
60833
60834
60835
60836
60837
60838
60839
60840
60841
60842
60843
60844
60845
60846
60847
60848
60849
60850
60851
60852
60853
60854
60855
60856
60857
60858
60859
60860
60861
60862
60863
60864
60865
60866
60867
60868
60869
60870
60871
60872
60873
60874
60875
60876
60877
60878
60879
60880
60881
60882
60883
60884
60885
60886
60887
60888
60889
60890
60891
60892
60893
60894
60895
60896
60897
60898
60899
60900
60901
60902
60903
60904
60905
60906
60907
60908
60909
60910
60911
60912
60913
60914
60915
60916
60917
60918
60919
60920
60921
60922
60923
60924
60925
60926
60927
60928
60929
60930
60931
60932
60933
60934
60935
60936
60937
60938
60939
60940
60941
60942
60943
60944
60945
60946
60947
60948
60949
60950
60951
60952
60953
60954
60955
60956
60957
60958
60959
60960
60961
60962
60963
60964
60965
60966
60967
60968
60969
60970
60971
60972
60973
60974
60975
60976
60977
60978
60979
60980
60981
60982
60983
60984
60985
60986
60987
60988
60989
60990
60991
60992
60993
60994
60995
60996
60997
60998
60999
61000
61001
61002
61003
61004
61005
61006
61007
61008
61009
61010
61011
61012
61013
61014
61015
61016
61017
61018
61019
61020
61021
61022
61023
61024
61025
61026
61027
61028
61029
61030
61031
61032
61033
61034
61035
61036
61037
61038
61039
61040
61041
61042
61043
61044
61045
61046
61047
61048
61049
61050
61051
61052
61053
61054
61055
61056
61057
61058
61059
61060
61061
61062
61063
61064
61065
61066
61067
61068
61069
61070
61071
61072
61073
61074
61075
61076
61077
61078
61079
61080
61081
61082
61083
61084
61085
61086
61087
61088
61089
61090
61091
61092
61093
61094
61095
61096
61097
61098
61099
61100
61101
61102
61103
61104
61105
61106
61107
61108
61109
61110
61111
61112
61113
61114
61115
61116
61117
61118
61119
61120
61121
61122
61123
61124
61125
61126
61127
61128
61129
61130
61131
61132
61133
61134
61135
61136
61137
61138
61139
61140
61141
61142
61143
61144
61145
61146
61147
61148
61149
61150
61151
61152
61153
61154
61155
61156
61157
61158
61159
61160
61161
61162
61163
61164
61165
61166
61167
61168
61169
61170
61171
61172
61173
61174
61175
61176
61177
61178
61179
61180
61181
61182
61183
61184
61185
61186
61187
61188
61189
61190
61191
61192
61193
61194
61195
61196
61197
61198
61199
61200
61201
61202
61203
61204
61205
61206
61207
61208
61209
61210
61211
61212
61213
61214
61215
61216
61217
61218
61219
61220
61221
61222
61223
61224
61225
61226
61227
61228
61229
61230
61231
61232
61233
61234
61235
61236
61237
61238
61239
61240
61241
61242
61243
61244
61245
61246
61247
61248
61249
61250
61251
61252
61253
61254
61255
61256
61257
61258
61259
61260
61261
61262
61263
61264
61265
61266
61267
61268
61269
61270
61271
61272
61273
61274
61275
61276
61277
61278
61279
61280
61281
61282
61283
61284
61285
61286
61287
61288
61289
61290
61291
61292
61293
61294
61295
61296
61297
61298
61299
61300
61301
61302
61303
61304
61305
61306
61307
61308
61309
61310
61311
61312
61313
61314
61315
61316
61317
61318
61319
61320
61321
61322
61323
61324
61325
61326
61327
61328
61329
61330
61331
61332
61333
61334
61335
61336
61337
61338
61339
61340
61341
61342
61343
61344
61345
61346
61347
61348
61349
61350
61351
61352
61353
61354
61355
61356
61357
61358
61359
61360
61361
61362
61363
61364
61365
61366
61367
61368
61369
61370
61371
61372
61373
61374
61375
61376
61377
61378
61379
61380
61381
61382
61383
61384
61385
61386
61387
61388
61389
61390
61391
61392
61393
61394
61395
61396
61397
61398
61399
61400
61401
61402
61403
61404
61405
61406
61407
61408
61409
61410
61411
61412
61413
61414
61415
61416
61417
61418
61419
61420
61421
61422
61423
61424
61425
61426
61427
61428
61429
61430
61431
61432
61433
61434
61435
61436
61437
61438
61439
61440
61441
61442
61443
61444
61445
61446
61447
61448
61449
61450
61451
61452
61453
61454
61455
61456
61457
61458
61459
61460
61461
61462
61463
61464
61465
61466
61467
61468
61469
61470
61471
61472
61473
61474
61475
61476
61477
61478
61479
61480
61481
61482
61483
61484
61485
61486
61487
61488
61489
61490
61491
61492
61493
61494
61495
61496
61497
61498
61499
61500
61501
61502
61503
61504
61505
61506
61507
61508
61509
61510
61511
61512
61513
61514
61515
61516
61517
61518
61519
61520
61521
61522
61523
61524
61525
61526
61527
61528
61529
61530
61531
61532
61533
61534
61535
61536
61537
61538
61539
61540
61541
61542
61543
61544
61545
61546
61547
61548
61549
61550
61551
61552
61553
61554
61555
61556
61557
61558
61559
61560
61561
61562
61563
61564
61565
61566
61567
61568
61569
61570
61571
61572
61573
61574
61575
61576
61577
61578
61579
61580
61581
61582
61583
61584
61585
61586
61587
61588
61589
61590
61591
61592
61593
61594
61595
61596
61597
61598
61599
61600
61601
61602
61603
61604
61605
61606
61607
61608
61609
61610
61611
61612
61613
61614
61615
61616
61617
61618
61619
61620
61621
61622
61623
61624
61625
61626
61627
61628
61629
61630
61631
61632
61633
61634
61635
61636
61637
61638
61639
61640
61641
61642
61643
61644
61645
61646
61647
61648
61649
61650
61651
61652
61653
61654
61655
61656
61657
61658
61659
61660
61661
61662
61663
61664
61665
61666
61667
61668
61669
61670
61671
61672
61673
61674
61675
61676
61677
61678
61679
61680
61681
61682
61683
61684
61685
61686
61687
61688
61689
61690
61691
61692
61693
61694
61695
61696
61697
61698
61699
61700
61701
61702
61703
61704
61705
61706
61707
61708
61709
61710
61711
61712
61713
61714
61715
61716
61717
61718
61719
61720
61721
61722
61723
61724
61725
61726
61727
61728
61729
61730
61731
61732
61733
61734
61735
61736
61737
61738
61739
61740
61741
61742
61743
61744
61745
61746
61747
61748
61749
61750
61751
61752
61753
61754
61755
61756
61757
61758
61759
61760
61761
61762
61763
61764
61765
61766
61767
61768
61769
61770
61771
61772
61773
61774
61775
61776
61777
61778
61779
61780
61781
61782
61783
61784
61785
61786
61787
61788
61789
61790
61791
61792
61793
61794
61795
61796
61797
61798
61799
61800
61801
61802
61803
61804
61805
61806
61807
61808
61809
61810
61811
61812
61813
61814
61815
61816
61817
61818
61819
61820
61821
61822
61823
61824
61825
61826
61827
61828
61829
61830
61831
61832
61833
61834
61835
61836
61837
61838
61839
61840
61841
61842
61843
61844
61845
61846
61847
61848
61849
61850
61851
61852
61853
61854
61855
61856
61857
61858
61859
61860
61861
61862
61863
61864
61865
61866
61867
61868
61869
61870
61871
61872
61873
61874
61875
61876
61877
61878
61879
61880
61881
61882
61883
61884
61885
61886
61887
61888
61889
61890
61891
61892
61893
61894
61895
61896
61897
61898
61899
61900
61901
61902
61903
61904
61905
61906
61907
61908
61909
61910
61911
61912
61913
61914
61915
61916
61917
61918
61919
61920
61921
61922
61923
61924
61925
61926
61927
61928
61929
61930
61931
61932
61933
61934
61935
61936
61937
61938
61939
61940
61941
61942
61943
61944
61945
61946
61947
61948
61949
61950
61951
61952
61953
61954
61955
61956
61957
61958
61959
61960
61961
61962
61963
61964
61965
61966
61967
61968
61969
61970
61971
61972
61973
61974
61975
61976
61977
61978
61979
61980
61981
61982
61983
61984
61985
61986
61987
61988
61989
61990
61991
61992
61993
61994
61995
61996
61997
61998
61999
62000
62001
62002
62003
62004
62005
62006
62007
62008
62009
62010
62011
62012
62013
62014
62015
62016
62017
62018
62019
62020
62021
62022
62023
62024
62025
62026
62027
62028
62029
62030
62031
62032
62033
62034
62035
62036
62037
62038
62039
62040
62041
62042
62043
62044
62045
62046
62047
62048
62049
62050
62051
62052
62053
62054
62055
62056
62057
62058
62059
62060
62061
62062
62063
62064
62065
62066
62067
62068
62069
62070
62071
62072
62073
62074
62075
62076
62077
62078
62079
62080
62081
62082
62083
62084
62085
62086
62087
62088
62089
62090
62091
62092
62093
62094
62095
62096
62097
62098
62099
62100
62101
62102
62103
62104
62105
62106
62107
62108
62109
62110
62111
62112
62113
62114
62115
62116
62117
62118
62119
62120
62121
62122
62123
62124
62125
62126
62127
62128
62129
62130
62131
62132
62133
62134
62135
62136
62137
62138
62139
62140
62141
62142
62143
62144
62145
62146
62147
62148
62149
62150
62151
62152
62153
62154
62155
62156
62157
62158
62159
62160
62161
62162
62163
62164
62165
62166
62167
62168
62169
62170
62171
62172
62173
62174
62175
62176
62177
62178
62179
62180
62181
62182
62183
62184
62185
62186
62187
62188
62189
62190
62191
62192
62193
62194
62195
62196
62197
62198
62199
62200
62201
62202
62203
62204
62205
62206
62207
62208
62209
62210
62211
62212
62213
62214
62215
62216
62217
62218
62219
62220
62221
62222
62223
62224
62225
62226
62227
62228
62229
62230
62231
62232
62233
62234
62235
62236
62237
62238
62239
62240
62241
62242
62243
62244
62245
62246
62247
62248
62249
62250
62251
62252
62253
62254
62255
62256
62257
62258
62259
62260
62261
62262
62263
62264
62265
62266
62267
62268
62269
62270
62271
62272
62273
62274
62275
62276
62277
62278
62279
62280
62281
62282
62283
62284
62285
62286
62287
62288
62289
62290
62291
62292
62293
62294
62295
62296
62297
62298
62299
62300
62301
62302
62303
62304
62305
62306
62307
62308
62309
62310
62311
62312
62313
62314
62315
62316
62317
62318
62319
62320
62321
62322
62323
62324
62325
62326
62327
62328
62329
62330
62331
62332
62333
62334
62335
62336
62337
62338
62339
62340
62341
62342
62343
62344
62345
62346
62347
62348
62349
62350
62351
62352
62353
62354
62355
62356
62357
62358
62359
62360
62361
62362
62363
62364
62365
62366
62367
62368
62369
62370
62371
62372
62373
62374
62375
62376
62377
62378
62379
62380
62381
62382
62383
62384
62385
62386
62387
62388
62389
62390
62391
62392
62393
62394
62395
62396
62397
62398
62399
62400
62401
62402
62403
62404
62405
62406
62407
62408
62409
62410
62411
62412
62413
62414
62415
62416
62417
62418
62419
62420
62421
62422
62423
62424
62425
62426
62427
62428
62429
62430
62431
62432
62433
62434
62435
62436
62437
62438
62439
62440
62441
62442
62443
62444
62445
62446
62447
62448
62449
62450
62451
62452
62453
62454
62455
62456
62457
62458
62459
62460
62461
62462
62463
62464
62465
62466
62467
62468
62469
62470
62471
62472
62473
62474
62475
62476
62477
62478
62479
62480
62481
62482
62483
62484
62485
62486
62487
62488
62489
62490
62491
62492
62493
62494
62495
62496
62497
62498
62499
62500
62501
62502
62503
62504
62505
62506
62507
62508
62509
62510
62511
62512
62513
62514
62515
62516
62517
62518
62519
62520
62521
62522
62523
62524
62525
62526
62527
62528
62529
62530
62531
62532
62533
62534
62535
62536
62537
62538
62539
62540
62541
62542
62543
62544
62545
62546
62547
62548
62549
62550
62551
62552
62553
62554
62555
62556
62557
62558
62559
62560
62561
62562
62563
62564
62565
62566
62567
62568
62569
62570
62571
62572
62573
62574
62575
62576
62577
62578
62579
62580
62581
62582
62583
62584
62585
62586
62587
62588
62589
62590
62591
62592
62593
62594
62595
62596
62597
62598
62599
62600
62601
62602
62603
62604
62605
62606
62607
62608
62609
62610
62611
62612
62613
62614
62615
62616
62617
62618
62619
62620
62621
62622
62623
62624
62625
62626
62627
62628
62629
62630
62631
62632
62633
62634
62635
62636
62637
62638
62639
62640
62641
62642
62643
62644
62645
62646
62647
62648
62649
62650
62651
62652
62653
62654
62655
62656
62657
62658
62659
62660
62661
62662
62663
62664
62665
62666
62667
62668
62669
62670
62671
62672
62673
62674
62675
62676
62677
62678
62679
62680
62681
62682
62683
62684
62685
62686
62687
62688
62689
62690
62691
62692
62693
62694
62695
62696
62697
62698
62699
62700
62701
62702
62703
62704
62705
62706
62707
62708
62709
62710
62711
62712
62713
62714
62715
62716
62717
62718
62719
62720
62721
62722
62723
62724
62725
62726
62727
62728
62729
62730
62731
62732
62733
62734
62735
62736
62737
62738
62739
62740
62741
62742
62743
62744
62745
62746
62747
62748
62749
62750
62751
62752
62753
62754
62755
62756
62757
62758
62759
62760
62761
62762
62763
62764
62765
62766
62767
62768
62769
62770
62771
62772
62773
62774
62775
62776
62777
62778
62779
62780
62781
62782
62783
62784
62785
62786
62787
62788
62789
62790
62791
62792
62793
62794
62795
62796
62797
62798
62799
62800
62801
62802
62803
62804
62805
62806
62807
62808
62809
62810
62811
62812
62813
62814
62815
62816
62817
62818
62819
62820
62821
62822
62823
62824
62825
62826
62827
62828
62829
62830
62831
62832
62833
62834
62835
62836
62837
62838
62839
62840
62841
62842
62843
62844
62845
62846
62847
62848
62849
62850
62851
62852
62853
62854
62855
62856
62857
62858
62859
62860
62861
62862
62863
62864
62865
62866
62867
62868
62869
62870
62871
62872
62873
62874
62875
62876
62877
62878
62879
62880
62881
62882
62883
62884
62885
62886
62887
62888
62889
62890
62891
62892
62893
62894
62895
62896
62897
62898
62899
62900
62901
62902
62903
62904
62905
62906
62907
62908
62909
62910
62911
62912
62913
62914
62915
62916
62917
62918
62919
62920
62921
62922
62923
62924
62925
62926
62927
62928
62929
62930
62931
62932
62933
62934
62935
62936
62937
62938
62939
62940
62941
62942
62943
62944
62945
62946
62947
62948
62949
62950
62951
62952
62953
62954
62955
62956
62957
62958
62959
62960
62961
62962
62963
62964
62965
62966
62967
62968
62969
62970
62971
62972
62973
62974
62975
62976
62977
62978
62979
62980
62981
62982
62983
62984
62985
62986
62987
62988
62989
62990
62991
62992
62993
62994
62995
62996
62997
62998
62999
63000
63001
63002
63003
63004
63005
63006
63007
63008
63009
63010
63011
63012
63013
63014
63015
63016
63017
63018
63019
63020
63021
63022
63023
63024
63025
63026
63027
63028
63029
63030
63031
63032
63033
63034
63035
63036
63037
63038
63039
63040
63041
63042
63043
63044
63045
63046
63047
63048
63049
63050
63051
63052
63053
63054
63055
63056
63057
63058
63059
63060
63061
63062
63063
63064
63065
63066
63067
63068
63069
63070
63071
63072
63073
63074
63075
63076
63077
63078
63079
63080
63081
63082
63083
63084
63085
63086
63087
63088
63089
63090
63091
63092
63093
63094
63095
63096
63097
63098
63099
63100
63101
63102
63103
63104
63105
63106
63107
63108
63109
63110
63111
63112
63113
63114
63115
63116
63117
63118
63119
63120
63121
63122
63123
63124
63125
63126
63127
63128
63129
63130
63131
63132
63133
63134
63135
63136
63137
63138
63139
63140
63141
63142
63143
63144
63145
63146
63147
63148
63149
63150
63151
63152
63153
63154
63155
63156
63157
63158
63159
63160
63161
63162
63163
63164
63165
63166
63167
63168
63169
63170
63171
63172
63173
63174
63175
63176
63177
63178
63179
63180
63181
63182
63183
63184
63185
63186
63187
63188
63189
63190
63191
63192
63193
63194
63195
63196
63197
63198
63199
63200
63201
63202
63203
63204
63205
63206
63207
63208
63209
63210
63211
63212
63213
63214
63215
63216
63217
63218
63219
63220
63221
63222
63223
63224
63225
63226
63227
63228
63229
63230
63231
63232
63233
63234
63235
63236
63237
63238
63239
63240
63241
63242
63243
63244
63245
63246
63247
63248
63249
63250
63251
63252
63253
63254
63255
63256
63257
63258
63259
63260
63261
63262
63263
63264
63265
63266
63267
63268
63269
63270
63271
63272
63273
63274
63275
63276
63277
63278
63279
63280
63281
63282
63283
63284
63285
63286
63287
63288
63289
63290
63291
63292
63293
63294
63295
63296
63297
63298
63299
63300
63301
63302
63303
63304
63305
63306
63307
63308
63309
63310
63311
63312
63313
63314
63315
63316
63317
63318
63319
63320
63321
63322
63323
63324
63325
63326
63327
63328
63329
63330
63331
63332
63333
63334
63335
63336
63337
63338
63339
63340
63341
63342
63343
63344
63345
63346
63347
63348
63349
63350
63351
63352
63353
63354
63355
63356
63357
63358
63359
63360
63361
63362
63363
63364
63365
63366
63367
63368
63369
63370
63371
63372
63373
63374
63375
63376
63377
63378
63379
63380
63381
63382
63383
63384
63385
63386
63387
63388
63389
63390
63391
63392
63393
63394
63395
63396
63397
63398
63399
63400
63401
63402
63403
63404
63405
63406
63407
63408
63409
63410
63411
63412
63413
63414
63415
63416
63417
63418
63419
63420
63421
63422
63423
63424
63425
63426
63427
63428
63429
63430
63431
63432
63433
63434
63435
63436
63437
63438
63439
63440
63441
63442
63443
63444
63445
63446
63447
63448
63449
63450
63451
63452
63453
63454
63455
63456
63457
63458
63459
63460
63461
63462
63463
63464
63465
63466
63467
63468
63469
63470
63471
63472
63473
63474
63475
63476
63477
63478
63479
63480
63481
63482
63483
63484
63485
63486
63487
63488
63489
63490
63491
63492
63493
63494
63495
63496
63497
63498
63499
63500
63501
63502
63503
63504
63505
63506
63507
63508
63509
63510
63511
63512
63513
63514
63515
63516
63517
63518
63519
63520
63521
63522
63523
63524
63525
63526
63527
63528
63529
63530
63531
63532
63533
63534
63535
63536
63537
63538
63539
63540
63541
63542
63543
63544
63545
63546
63547
63548
63549
63550
63551
63552
63553
63554
63555
63556
63557
63558
63559
63560
63561
63562
63563
63564
63565
63566
63567
63568
63569
63570
63571
63572
63573
63574
63575
63576
63577
63578
63579
63580
63581
63582
63583
63584
63585
63586
63587
63588
63589
63590
63591
63592
63593
63594
63595
63596
63597
63598
63599
63600
63601
63602
63603
63604
63605
63606
63607
63608
63609
63610
63611
63612
63613
63614
63615
63616
63617
63618
63619
63620
63621
63622
63623
63624
63625
63626
63627
63628
63629
63630
63631
63632
63633
63634
63635
63636
63637
63638
63639
63640
63641
63642
63643
63644
63645
63646
63647
63648
63649
63650
63651
63652
63653
63654
63655
63656
63657
63658
63659
63660
63661
63662
63663
63664
63665
63666
63667
63668
63669
63670
63671
63672
63673
63674
63675
63676
63677
63678
63679
63680
63681
63682
63683
63684
63685
63686
63687
63688
63689
63690
63691
63692
63693
63694
63695
63696
63697
63698
63699
63700
63701
63702
63703
63704
63705
63706
63707
63708
63709
63710
63711
63712
63713
63714
63715
63716
63717
63718
63719
63720
63721
63722
63723
63724
63725
63726
63727
63728
63729
63730
63731
63732
63733
63734
63735
63736
63737
63738
63739
63740
63741
63742
63743
63744
63745
63746
63747
63748
63749
63750
63751
63752
63753
63754
63755
63756
63757
63758
63759
63760
63761
63762
63763
63764
63765
63766
63767
63768
63769
63770
63771
63772
63773
63774
63775
63776
63777
63778
63779
63780
63781
63782
63783
63784
63785
63786
63787
63788
63789
63790
63791
63792
63793
63794
63795
63796
63797
63798
63799
63800
63801
63802
63803
63804
63805
63806
63807
63808
63809
63810
63811
63812
63813
63814
63815
63816
63817
63818
63819
63820
63821
63822
63823
63824
63825
63826
63827
63828
63829
63830
63831
63832
63833
63834
63835
63836
63837
63838
63839
63840
63841
63842
63843
63844
63845
63846
63847
63848
63849
63850
63851
63852
63853
63854
63855
63856
63857
63858
63859
63860
63861
63862
63863
63864
63865
63866
63867
63868
63869
63870
63871
63872
63873
63874
63875
63876
63877
63878
63879
63880
63881
63882
63883
63884
63885
63886
63887
63888
63889
63890
63891
63892
63893
63894
63895
63896
63897
63898
63899
63900
63901
63902
63903
63904
63905
63906
63907
63908
63909
63910
63911
63912
63913
63914
63915
63916
63917
63918
63919
63920
63921
63922
63923
63924
63925
63926
63927
63928
63929
63930
63931
63932
63933
63934
63935
63936
63937
63938
63939
63940
63941
63942
63943
63944
63945
63946
63947
63948
63949
63950
63951
63952
63953
63954
63955
63956
63957
63958
63959
63960
63961
63962
63963
63964
63965
63966
63967
63968
63969
63970
63971
63972
63973
63974
63975
63976
63977
63978
63979
63980
63981
63982
63983
63984
63985
63986
63987
63988
63989
63990
63991
63992
63993
63994
63995
63996
63997
63998
63999
64000
64001
64002
64003
64004
64005
64006
64007
64008
64009
64010
64011
64012
64013
64014
64015
64016
64017
64018
64019
64020
64021
64022
64023
64024
64025
64026
64027
64028
64029
64030
64031
64032
64033
64034
64035
64036
64037
64038
64039
64040
64041
64042
64043
64044
64045
64046
64047
64048
64049
64050
64051
64052
64053
64054
64055
64056
64057
64058
64059
64060
64061
64062
64063
64064
64065
64066
64067
64068
64069
64070
64071
64072
64073
64074
64075
64076
64077
64078
64079
64080
64081
64082
64083
64084
64085
64086
64087
64088
64089
64090
64091
64092
64093
64094
64095
64096
64097
64098
64099
64100
64101
64102
64103
64104
64105
64106
64107
64108
64109
64110
64111
64112
64113
64114
64115
64116
64117
64118
64119
64120
64121
64122
64123
64124
64125
64126
64127
64128
64129
64130
64131
64132
64133
64134
64135
64136
64137
64138
64139
64140
64141
64142
64143
64144
64145
64146
64147
64148
64149
64150
64151
64152
64153
64154
64155
64156
64157
64158
64159
64160
64161
64162
64163
64164
64165
64166
64167
64168
64169
64170
64171
64172
64173
64174
64175
64176
64177
64178
64179
64180
64181
64182
64183
64184
64185
64186
64187
64188
64189
64190
64191
64192
64193
64194
64195
64196
64197
64198
64199
64200
64201
64202
64203
64204
64205
64206
64207
64208
64209
64210
64211
64212
64213
64214
64215
64216
64217
64218
64219
64220
64221
64222
64223
64224
64225
64226
64227
64228
64229
64230
64231
64232
64233
64234
64235
64236
64237
64238
64239
64240
64241
64242
64243
64244
64245
64246
64247
64248
64249
64250
64251
64252
64253
64254
64255
64256
64257
64258
64259
64260
64261
64262
64263
64264
64265
64266
64267
64268
64269
64270
64271
64272
64273
64274
64275
64276
64277
64278
64279
64280
64281
64282
64283
64284
64285
64286
64287
64288
64289
64290
64291
64292
64293
64294
64295
64296
64297
64298
64299
64300
64301
64302
64303
64304
64305
64306
64307
64308
64309
64310
64311
64312
64313
64314
64315
64316
64317
64318
64319
64320
64321
64322
64323
64324
64325
64326
64327
64328
64329
64330
64331
64332
64333
64334
64335
64336
64337
64338
64339
64340
64341
64342
64343
64344
64345
64346
64347
64348
64349
64350
64351
64352
64353
64354
64355
64356
64357
64358
64359
64360
64361
64362
64363
64364
64365
64366
64367
64368
64369
64370
64371
64372
64373
64374
64375
64376
64377
64378
64379
64380
64381
64382
64383
64384
64385
64386
64387
64388
64389
64390
64391
64392
64393
64394
64395
64396
64397
64398
64399
64400
64401
64402
64403
64404
64405
64406
64407
64408
64409
64410
64411
64412
64413
64414
64415
64416
64417
64418
64419
64420
64421
64422
64423
64424
64425
64426
64427
64428
64429
64430
64431
64432
64433
64434
64435
64436
64437
64438
64439
64440
64441
64442
64443
64444
64445
64446
64447
64448
64449
64450
64451
64452
64453
64454
64455
64456
64457
64458
64459
64460
64461
64462
64463
64464
64465
64466
64467
64468
64469
64470
64471
64472
64473
64474
64475
64476
64477
64478
64479
64480
64481
64482
64483
64484
64485
64486
64487
64488
64489
64490
64491
64492
64493
64494
64495
64496
64497
64498
64499
64500
64501
64502
64503
64504
64505
64506
64507
64508
64509
64510
64511
64512
64513
64514
64515
64516
64517
64518
64519
64520
64521
64522
64523
64524
64525
64526
64527
64528
64529
64530
64531
64532
64533
64534
64535
64536
64537
64538
64539
64540
64541
64542
64543
64544
64545
64546
64547
64548
64549
64550
64551
64552
64553
64554
64555
64556
64557
64558
64559
64560
64561
64562
64563
64564
64565
64566
64567
64568
64569
64570
64571
64572
64573
64574
64575
64576
64577
64578
64579
64580
64581
64582
64583
64584
64585
64586
64587
64588
64589
64590
64591
64592
64593
64594
64595
64596
64597
64598
64599
64600
64601
64602
64603
64604
64605
64606
64607
64608
64609
64610
64611
64612
64613
64614
64615
64616
64617
64618
64619
64620
64621
64622
64623
64624
64625
64626
64627
64628
64629
64630
64631
64632
64633
64634
64635
64636
64637
64638
64639
64640
64641
64642
64643
64644
64645
64646
64647
64648
64649
64650
64651
64652
64653
64654
64655
64656
64657
64658
64659
64660
64661
64662
64663
64664
64665
64666
64667
64668
64669
64670
64671
64672
64673
64674
64675
64676
64677
64678
64679
64680
64681
64682
64683
64684
64685
64686
64687
64688
64689
64690
64691
64692
64693
64694
64695
64696
64697
64698
64699
64700
64701
64702
64703
64704
64705
64706
64707
64708
64709
64710
64711
64712
64713
64714
64715
64716
64717
64718
64719
64720
64721
64722
64723
64724
64725
64726
64727
64728
64729
64730
64731
64732
64733
64734
64735
64736
64737
64738
64739
64740
64741
64742
64743
64744
64745
64746
64747
64748
64749
64750
64751
64752
64753
64754
64755
64756
64757
64758
64759
64760
64761
64762
64763
64764
64765
64766
64767
64768
64769
64770
64771
64772
64773
64774
64775
64776
64777
64778
64779
64780
64781
64782
64783
64784
64785
64786
64787
64788
64789
64790
64791
64792
64793
64794
64795
64796
64797
64798
64799
64800
64801
64802
64803
64804
64805
64806
64807
64808
64809
64810
64811
64812
64813
64814
64815
64816
64817
64818
64819
64820
64821
64822
64823
64824
64825
64826
64827
64828
64829
64830
64831
64832
64833
64834
64835
64836
64837
64838
64839
64840
64841
64842
64843
64844
64845
64846
64847
64848
64849
64850
64851
64852
64853
64854
64855
64856
64857
64858
64859
64860
64861
64862
64863
64864
64865
64866
64867
64868
64869
64870
64871
64872
64873
64874
64875
64876
64877
64878
64879
64880
64881
64882
64883
64884
64885
64886
64887
64888
64889
64890
64891
64892
64893
64894
64895
64896
64897
64898
64899
64900
64901
64902
64903
64904
64905
64906
64907
64908
64909
64910
64911
64912
64913
64914
64915
64916
64917
64918
64919
64920
64921
64922
64923
64924
64925
64926
64927
64928
64929
64930
64931
64932
64933
64934
64935
64936
64937
64938
64939
64940
64941
64942
64943
64944
64945
64946
64947
64948
64949
64950
64951
64952
64953
64954
64955
64956
64957
64958
64959
64960
64961
64962
64963
64964
64965
64966
64967
64968
64969
64970
64971
64972
64973
64974
64975
64976
64977
64978
64979
64980
64981
64982
64983
64984
64985
64986
64987
64988
64989
64990
64991
64992
64993
64994
64995
64996
64997
64998
64999
65000
65001
65002
65003
65004
65005
65006
65007
65008
65009
65010
65011
65012
65013
65014
65015
65016
65017
65018
65019
65020
65021
65022
65023
65024
65025
65026
65027
65028
65029
65030
65031
65032
65033
65034
65035
65036
65037
65038
65039
65040
65041
65042
65043
65044
65045
65046
65047
65048
65049
65050
65051
65052
65053
65054
65055
65056
65057
65058
65059
65060
65061
65062
65063
65064
65065
65066
65067
65068
65069
65070
65071
65072
65073
65074
65075
65076
65077
65078
65079
65080
65081
65082
65083
65084
65085
65086
65087
65088
65089
65090
65091
65092
65093
65094
65095
65096
65097
65098
65099
65100
65101
65102
65103
65104
65105
65106
65107
65108
65109
65110
65111
65112
65113
65114
65115
65116
65117
65118
65119
65120
65121
65122
65123
65124
65125
65126
65127
65128
65129
65130
65131
65132
65133
65134
65135
65136
65137
65138
65139
65140
65141
65142
65143
65144
65145
65146
65147
65148
65149
65150
65151
65152
65153
65154
65155
65156
65157
65158
65159
65160
65161
65162
65163
65164
65165
65166
65167
65168
65169
65170
65171
65172
65173
65174
65175
65176
65177
65178
65179
65180
65181
65182
65183
65184
65185
65186
65187
65188
65189
65190
65191
65192
65193
65194
65195
65196
65197
65198
65199
65200
65201
65202
65203
65204
65205
65206
65207
65208
65209
65210
65211
65212
65213
65214
65215
65216
65217
65218
65219
65220
65221
65222
65223
65224
65225
65226
65227
65228
65229
65230
65231
65232
65233
65234
65235
65236
65237
65238
65239
65240
65241
65242
65243
65244
65245
65246
65247
65248
65249
65250
65251
65252
65253
65254
65255
65256
65257
65258
65259
65260
65261
65262
65263
65264
65265
65266
65267
65268
65269
65270
65271
65272
65273
65274
65275
65276
65277
65278
65279
65280
65281
65282
65283
65284
65285
65286
65287
65288
65289
65290
65291
65292
65293
65294
65295
65296
65297
65298
65299
65300
65301
65302
65303
65304
65305
65306
65307
65308
65309
65310
65311
65312
65313
65314
65315
65316
65317
65318
65319
65320
65321
65322
65323
65324
65325
65326
65327
65328
65329
65330
65331
65332
65333
65334
65335
65336
65337
65338
65339
65340
65341
65342
65343
65344
65345
65346
65347
65348
65349
65350
65351
65352
65353
65354
65355
65356
65357
65358
65359
65360
65361
65362
65363
65364
65365
65366
65367
65368
65369
65370
65371
65372
65373
65374
65375
65376
65377
65378
65379
65380
65381
65382
65383
65384
65385
65386
65387
65388
65389
65390
65391
65392
65393
65394
65395
65396
65397
65398
65399
65400
65401
65402
65403
65404
65405
65406
65407
65408
65409
65410
65411
65412
65413
65414
65415
65416
65417
65418
65419
65420
65421
65422
65423
65424
65425
65426
65427
65428
65429
65430
65431
65432
65433
65434
65435
65436
65437
65438
65439
65440
65441
65442
65443
65444
65445
65446
65447
65448
65449
65450
65451
65452
65453
65454
65455
65456
65457
65458
65459
65460
65461
65462
65463
65464
65465
65466
65467
65468
65469
65470
65471
65472
65473
65474
65475
65476
65477
65478
65479
65480
65481
65482
65483
65484
65485
65486
65487
65488
65489
65490
65491
65492
65493
65494
65495
65496
65497
65498
65499
65500
65501
65502
65503
65504
65505
65506
65507
65508
65509
65510
65511
65512
65513
65514
65515
65516
65517
65518
65519
65520
65521
65522
65523
65524
65525
65526
65527
65528
65529
65530
65531
65532
65533
65534
65535
65536
65537
65538
65539
65540
65541
65542
65543
65544
65545
65546
65547
65548
65549
65550
65551
65552
65553
65554
65555
65556
65557
65558
65559
65560
65561
65562
65563
65564
65565
65566
65567
65568
65569
65570
65571
65572
65573
65574
65575
65576
65577
65578
65579
65580
65581
65582
65583
65584
65585
65586
65587
65588
65589
65590
65591
65592
65593
65594
65595
65596
65597
65598
65599
65600
65601
65602
65603
65604
65605
65606
65607
65608
65609
65610
65611
65612
65613
65614
65615
65616
65617
65618
65619
65620
65621
65622
65623
65624
65625
65626
65627
65628
65629
65630
65631
65632
65633
65634
65635
65636
65637
65638
65639
65640
65641
65642
65643
65644
65645
65646
65647
65648
65649
65650
65651
65652
65653
65654
65655
65656
65657
65658
65659
65660
65661
65662
65663
65664
65665
65666
65667
65668
65669
65670
65671
65672
65673
65674
65675
65676
65677
65678
65679
65680
65681
65682
65683
65684
65685
65686
65687
65688
65689
65690
65691
65692
65693
65694
65695
65696
65697
65698
65699
65700
65701
65702
65703
65704
65705
65706
65707
65708
65709
65710
65711
65712
65713
65714
65715
65716
65717
65718
65719
65720
65721
65722
65723
65724
65725
65726
65727
65728
65729
65730
65731
65732
65733
65734
65735
65736
65737
65738
65739
65740
65741
65742
65743
65744
65745
65746
65747
65748
65749
65750
65751
65752
65753
65754
65755
65756
65757
65758
65759
65760
65761
65762
65763
65764
65765
65766
65767
65768
65769
65770
65771
65772
65773
65774
65775
65776
65777
65778
65779
65780
65781
65782
65783
65784
65785
65786
65787
65788
65789
65790
65791
65792
65793
65794
65795
65796
65797
65798
65799
65800
65801
65802
65803
65804
65805
65806
65807
65808
65809
65810
65811
65812
65813
65814
65815
65816
65817
65818
65819
65820
65821
65822
65823
65824
65825
65826
65827
65828
65829
65830
65831
65832
65833
65834
65835
65836
65837
65838
65839
65840
65841
65842
65843
65844
65845
65846
65847
65848
65849
65850
65851
65852
65853
65854
65855
65856
65857
65858
65859
65860
65861
65862
65863
65864
65865
65866
65867
65868
65869
65870
65871
65872
65873
65874
65875
65876
65877
65878
65879
65880
65881
65882
65883
65884
65885
65886
65887
65888
65889
65890
65891
65892
65893
65894
65895
65896
65897
65898
65899
65900
65901
65902
65903
65904
65905
65906
65907
65908
65909
65910
65911
65912
65913
65914
65915
65916
65917
65918
65919
65920
65921
65922
65923
65924
65925
65926
65927
65928
65929
65930
65931
65932
65933
65934
65935
65936
65937
65938
65939
65940
65941
65942
65943
65944
65945
65946
65947
65948
65949
65950
65951
65952
65953
65954
65955
65956
65957
65958
65959
65960
65961
65962
65963
65964
65965
65966
65967
65968
65969
65970
65971
65972
65973
65974
65975
65976
65977
65978
65979
65980
65981
65982
65983
65984
65985
65986
65987
65988
65989
65990
65991
65992
65993
65994
65995
65996
65997
65998
65999
66000
66001
66002
66003
66004
66005
66006
66007
66008
66009
66010
66011
66012
66013
66014
66015
66016
66017
66018
66019
66020
66021
66022
66023
66024
66025
66026
66027
66028
66029
66030
66031
66032
66033
66034
66035
66036
66037
66038
66039
66040
66041
66042
66043
66044
66045
66046
66047
66048
66049
66050
66051
66052
66053
66054
66055
66056
66057
66058
66059
66060
66061
66062
66063
66064
66065
66066
66067
66068
66069
66070
66071
66072
66073
66074
66075
66076
66077
66078
66079
66080
66081
66082
66083
66084
66085
66086
66087
66088
66089
66090
66091
66092
66093
66094
66095
66096
66097
66098
66099
66100
66101
66102
66103
66104
66105
66106
66107
66108
66109
66110
66111
66112
66113
66114
66115
66116
66117
66118
66119
66120
66121
66122
66123
66124
66125
66126
66127
66128
66129
66130
66131
66132
66133
66134
66135
66136
66137
66138
66139
66140
66141
66142
66143
66144
66145
66146
66147
66148
66149
66150
66151
66152
66153
66154
66155
66156
66157
66158
66159
66160
66161
66162
66163
66164
66165
66166
66167
66168
66169
66170
66171
66172
66173
66174
66175
66176
66177
66178
66179
66180
66181
66182
66183
66184
66185
66186
66187
66188
66189
66190
66191
66192
66193
66194
66195
66196
66197
66198
66199
66200
66201
66202
66203
66204
66205
66206
66207
66208
66209
66210
66211
66212
66213
66214
66215
66216
66217
66218
66219
66220
66221
66222
66223
66224
66225
66226
66227
66228
66229
66230
66231
66232
66233
66234
66235
66236
66237
66238
66239
66240
66241
66242
66243
66244
66245
66246
66247
66248
66249
66250
66251
66252
66253
66254
66255
66256
66257
66258
66259
66260
66261
66262
66263
66264
66265
66266
66267
66268
66269
66270
66271
66272
66273
66274
66275
66276
66277
66278
66279
66280
66281
66282
66283
66284
66285
66286
66287
66288
66289
66290
66291
66292
66293
66294
66295
66296
66297
66298
66299
66300
66301
66302
66303
66304
66305
66306
66307
66308
66309
66310
66311
66312
66313
66314
66315
66316
66317
66318
66319
66320
66321
66322
66323
66324
66325
66326
66327
66328
66329
66330
66331
66332
66333
66334
66335
66336
66337
66338
66339
66340
66341
66342
66343
66344
66345
66346
66347
66348
66349
66350
66351
66352
66353
66354
66355
66356
66357
66358
66359
66360
66361
66362
66363
66364
66365
66366
66367
66368
66369
66370
66371
66372
66373
66374
66375
66376
66377
66378
66379
66380
66381
66382
66383
66384
66385
66386
66387
66388
66389
66390
66391
66392
66393
66394
66395
66396
66397
66398
66399
66400
66401
66402
66403
66404
66405
66406
66407
66408
66409
66410
66411
66412
66413
66414
66415
66416
66417
66418
66419
66420
66421
66422
66423
66424
66425
66426
66427
66428
66429
66430
66431
66432
66433
66434
66435
66436
66437
66438
66439
66440
66441
66442
66443
66444
66445
66446
66447
66448
66449
66450
66451
66452
66453
66454
66455
66456
66457
66458
66459
66460
66461
66462
66463
66464
66465
66466
66467
66468
66469
66470
66471
66472
66473
66474
66475
66476
66477
66478
66479
66480
66481
66482
66483
66484
66485
66486
66487
66488
66489
66490
66491
66492
66493
66494
66495
66496
66497
66498
66499
66500
66501
66502
66503
66504
66505
66506
66507
66508
66509
66510
66511
66512
66513
66514
66515
66516
66517
66518
66519
66520
66521
66522
66523
66524
66525
66526
66527
66528
66529
66530
66531
66532
66533
66534
66535
66536
66537
66538
66539
66540
66541
66542
66543
66544
66545
66546
66547
66548
66549
66550
66551
66552
66553
66554
66555
66556
66557
66558
66559
66560
66561
66562
66563
66564
66565
66566
66567
66568
66569
66570
66571
66572
66573
66574
66575
66576
66577
66578
66579
66580
66581
66582
66583
66584
66585
66586
66587
66588
66589
66590
66591
66592
66593
66594
66595
66596
66597
66598
66599
66600
66601
66602
66603
66604
66605
66606
66607
66608
66609
66610
66611
66612
66613
66614
66615
66616
66617
66618
66619
66620
66621
66622
66623
66624
66625
66626
66627
66628
66629
66630
66631
66632
66633
66634
66635
66636
66637
66638
66639
66640
66641
66642
66643
66644
66645
66646
66647
66648
66649
66650
66651
66652
66653
66654
66655
66656
66657
66658
66659
66660
66661
66662
66663
66664
66665
66666
66667
66668
66669
66670
66671
66672
66673
66674
66675
66676
66677
66678
66679
66680
66681
66682
66683
66684
66685
66686
66687
66688
66689
66690
66691
66692
66693
66694
66695
66696
66697
66698
66699
66700
66701
66702
66703
66704
66705
66706
66707
66708
66709
66710
66711
66712
66713
66714
66715
66716
66717
66718
66719
66720
66721
66722
66723
66724
66725
66726
66727
66728
66729
66730
66731
66732
66733
66734
66735
66736
66737
66738
66739
66740
66741
66742
66743
66744
66745
66746
66747
66748
66749
66750
66751
66752
66753
66754
66755
66756
66757
66758
66759
66760
66761
66762
66763
66764
66765
66766
66767
66768
66769
66770
66771
66772
66773
66774
66775
66776
66777
66778
66779
66780
66781
66782
66783
66784
66785
66786
66787
66788
66789
66790
66791
66792
66793
66794
66795
66796
66797
66798
66799
66800
66801
66802
66803
66804
66805
66806
66807
66808
66809
66810
66811
66812
66813
66814
66815
66816
66817
66818
66819
66820
66821
66822
66823
66824
66825
66826
66827
66828
66829
66830
66831
66832
66833
66834
66835
66836
66837
66838
66839
66840
66841
66842
66843
66844
66845
66846
66847
66848
66849
66850
66851
66852
66853
66854
66855
66856
66857
66858
66859
66860
66861
66862
66863
66864
66865
66866
66867
66868
66869
66870
66871
66872
66873
66874
66875
66876
66877
66878
66879
66880
66881
66882
66883
66884
66885
66886
66887
66888
66889
66890
66891
66892
66893
66894
66895
66896
66897
66898
66899
66900
66901
66902
66903
66904
66905
66906
66907
66908
66909
66910
66911
66912
66913
66914
66915
66916
66917
66918
66919
66920
66921
66922
66923
66924
66925
66926
66927
66928
66929
66930
66931
66932
66933
66934
66935
66936
66937
66938
66939
66940
66941
66942
66943
66944
66945
66946
66947
66948
66949
66950
66951
66952
66953
66954
66955
66956
66957
66958
66959
66960
66961
66962
66963
66964
66965
66966
66967
66968
66969
66970
66971
66972
66973
66974
66975
66976
66977
66978
66979
66980
66981
66982
66983
66984
66985
66986
66987
66988
66989
66990
66991
66992
66993
66994
66995
66996
66997
66998
66999
67000
67001
67002
67003
67004
67005
67006
67007
67008
67009
67010
67011
67012
67013
67014
67015
67016
67017
67018
67019
67020
67021
67022
67023
67024
67025
67026
67027
67028
67029
67030
67031
67032
67033
67034
67035
67036
67037
67038
67039
67040
67041
67042
67043
67044
67045
67046
67047
67048
67049
67050
67051
67052
67053
67054
67055
67056
67057
67058
67059
67060
67061
67062
67063
67064
67065
67066
67067
67068
67069
67070
67071
67072
67073
67074
67075
67076
67077
67078
67079
67080
67081
67082
67083
67084
67085
67086
67087
67088
67089
67090
67091
67092
67093
67094
67095
67096
67097
67098
67099
67100
67101
67102
67103
67104
67105
67106
67107
67108
67109
67110
67111
67112
67113
67114
67115
67116
67117
67118
67119
67120
67121
67122
67123
67124
67125
67126
67127
67128
67129
67130
67131
67132
67133
67134
67135
67136
67137
67138
67139
67140
67141
67142
67143
67144
67145
67146
67147
67148
67149
67150
67151
67152
67153
67154
67155
67156
67157
67158
67159
67160
67161
67162
67163
67164
67165
67166
67167
67168
67169
67170
67171
67172
67173
67174
67175
67176
67177
67178
67179
67180
67181
67182
67183
67184
67185
67186
67187
67188
67189
67190
67191
67192
67193
67194
67195
67196
67197
67198
67199
67200
67201
67202
67203
67204
67205
67206
67207
67208
67209
67210
67211
67212
67213
67214
67215
67216
67217
67218
67219
67220
67221
67222
67223
67224
67225
67226
67227
67228
67229
67230
67231
67232
67233
67234
67235
67236
67237
67238
67239
67240
67241
67242
67243
67244
67245
67246
67247
67248
67249
67250
67251
67252
67253
67254
67255
67256
67257
67258
67259
67260
67261
67262
67263
67264
67265
67266
67267
67268
67269
67270
67271
67272
67273
67274
67275
67276
67277
67278
67279
67280
67281
67282
67283
67284
67285
67286
67287
67288
67289
67290
67291
67292
67293
67294
67295
67296
67297
67298
67299
67300
67301
67302
67303
67304
67305
67306
67307
67308
67309
67310
67311
67312
67313
67314
67315
67316
67317
67318
67319
67320
67321
67322
67323
67324
67325
67326
67327
67328
67329
67330
67331
67332
67333
67334
67335
67336
67337
67338
67339
67340
67341
67342
67343
67344
67345
67346
67347
67348
67349
67350
67351
67352
67353
67354
67355
67356
67357
67358
67359
67360
67361
67362
67363
67364
67365
67366
67367
67368
67369
67370
67371
67372
67373
67374
67375
67376
67377
67378
67379
67380
67381
67382
67383
67384
67385
67386
67387
67388
67389
67390
67391
67392
67393
67394
67395
67396
67397
67398
67399
67400
67401
67402
67403
67404
67405
67406
67407
67408
67409
67410
67411
67412
67413
67414
67415
67416
67417
67418
67419
67420
67421
67422
67423
67424
67425
67426
67427
67428
67429
67430
67431
67432
67433
67434
67435
67436
67437
67438
67439
67440
67441
67442
67443
67444
67445
67446
67447
67448
67449
67450
67451
67452
67453
67454
67455
67456
67457
67458
67459
67460
67461
67462
67463
67464
67465
67466
67467
67468
67469
67470
67471
67472
67473
67474
67475
67476
67477
67478
67479
67480
67481
67482
67483
67484
67485
67486
67487
67488
67489
67490
67491
67492
67493
67494
67495
67496
67497
67498
67499
67500
67501
67502
67503
67504
67505
67506
67507
67508
67509
67510
67511
67512
67513
67514
67515
67516
67517
67518
67519
67520
67521
67522
67523
67524
67525
67526
67527
67528
67529
67530
67531
67532
67533
67534
67535
67536
67537
67538
67539
67540
67541
67542
67543
67544
67545
67546
67547
67548
67549
67550
67551
67552
67553
67554
67555
67556
67557
67558
67559
67560
67561
67562
67563
67564
67565
67566
67567
67568
67569
67570
67571
67572
67573
67574
67575
67576
67577
67578
67579
67580
67581
67582
67583
67584
67585
67586
67587
67588
67589
67590
67591
67592
67593
67594
67595
67596
67597
67598
67599
67600
67601
67602
67603
67604
67605
67606
67607
67608
67609
67610
67611
67612
67613
67614
67615
67616
67617
67618
67619
67620
67621
67622
67623
67624
67625
67626
67627
67628
67629
67630
67631
67632
67633
67634
67635
67636
67637
67638
67639
67640
67641
67642
67643
67644
67645
67646
67647
67648
67649
67650
67651
67652
67653
67654
67655
67656
67657
67658
67659
67660
67661
67662
67663
67664
67665
67666
67667
67668
67669
67670
67671
67672
67673
67674
67675
67676
67677
67678
67679
67680
67681
67682
67683
67684
67685
67686
67687
67688
67689
67690
67691
67692
67693
67694
67695
67696
67697
67698
67699
67700
67701
67702
67703
67704
67705
67706
67707
67708
67709
67710
67711
67712
67713
67714
67715
67716
67717
67718
67719
67720
67721
67722
67723
67724
67725
67726
67727
67728
67729
67730
67731
67732
67733
67734
67735
67736
67737
67738
67739
67740
67741
67742
67743
67744
67745
67746
67747
67748
67749
67750
67751
67752
67753
67754
67755
67756
67757
67758
67759
67760
67761
67762
67763
67764
67765
67766
67767
67768
67769
67770
67771
67772
67773
67774
67775
67776
67777
67778
67779
67780
67781
67782
67783
67784
67785
67786
67787
67788
67789
67790
67791
67792
67793
67794
67795
67796
67797
67798
67799
67800
67801
67802
67803
67804
67805
67806
67807
67808
67809
67810
67811
67812
67813
67814
67815
67816
67817
67818
67819
67820
67821
67822
67823
67824
67825
67826
67827
67828
67829
67830
67831
67832
67833
67834
67835
67836
67837
67838
67839
67840
67841
67842
67843
67844
67845
67846
67847
67848
67849
67850
67851
67852
67853
67854
67855
67856
67857
67858
67859
67860
67861
67862
67863
67864
67865
67866
67867
67868
67869
67870
67871
67872
67873
67874
67875
67876
67877
67878
67879
67880
67881
67882
67883
67884
67885
67886
67887
67888
67889
67890
67891
67892
67893
67894
67895
67896
67897
67898
67899
67900
67901
67902
67903
67904
67905
67906
67907
67908
67909
67910
67911
67912
67913
67914
67915
67916
67917
67918
67919
67920
67921
67922
67923
67924
67925
67926
67927
67928
67929
67930
67931
67932
67933
67934
67935
67936
67937
67938
67939
67940
67941
67942
67943
67944
67945
67946
67947
67948
67949
67950
67951
67952
67953
67954
67955
67956
67957
67958
67959
67960
67961
67962
67963
67964
67965
67966
67967
67968
67969
67970
67971
67972
67973
67974
67975
67976
67977
67978
67979
67980
67981
67982
67983
67984
67985
67986
67987
67988
67989
67990
67991
67992
67993
67994
67995
67996
67997
67998
67999
68000
68001
68002
68003
68004
68005
68006
68007
68008
68009
68010
68011
68012
68013
68014
68015
68016
68017
68018
68019
68020
68021
68022
68023
68024
68025
68026
68027
68028
68029
68030
68031
68032
68033
68034
68035
68036
68037
68038
68039
68040
68041
68042
68043
68044
68045
68046
68047
68048
68049
68050
68051
68052
68053
68054
68055
68056
68057
68058
68059
68060
68061
68062
68063
68064
68065
68066
68067
68068
68069
68070
68071
68072
68073
68074
68075
68076
68077
68078
68079
68080
68081
68082
68083
68084
68085
68086
68087
68088
68089
68090
68091
68092
68093
68094
68095
68096
68097
68098
68099
68100
68101
68102
68103
68104
68105
68106
68107
68108
68109
68110
68111
68112
68113
68114
68115
68116
68117
68118
68119
68120
68121
68122
68123
68124
68125
68126
68127
68128
68129
68130
68131
68132
68133
68134
68135
68136
68137
68138
68139
68140
68141
68142
68143
68144
68145
68146
68147
68148
68149
68150
68151
68152
68153
68154
68155
68156
68157
68158
68159
68160
68161
68162
68163
68164
68165
68166
68167
68168
68169
68170
68171
68172
68173
68174
68175
68176
68177
68178
68179
68180
68181
68182
68183
68184
68185
68186
68187
68188
68189
68190
68191
68192
68193
68194
68195
68196
68197
68198
68199
68200
68201
68202
68203
68204
68205
68206
68207
68208
68209
68210
68211
68212
68213
68214
68215
68216
68217
68218
68219
68220
68221
68222
68223
68224
68225
68226
68227
68228
68229
68230
68231
68232
68233
68234
68235
68236
68237
68238
68239
68240
68241
68242
68243
68244
68245
68246
68247
68248
68249
68250
68251
68252
68253
68254
68255
68256
68257
68258
68259
68260
68261
68262
68263
68264
68265
68266
68267
68268
68269
68270
68271
68272
68273
68274
68275
68276
68277
68278
68279
68280
68281
68282
68283
68284
68285
68286
68287
68288
68289
68290
68291
68292
68293
68294
68295
68296
68297
68298
68299
68300
68301
68302
68303
68304
68305
68306
68307
68308
68309
68310
68311
68312
68313
68314
68315
68316
68317
68318
68319
68320
68321
68322
68323
68324
68325
68326
68327
68328
68329
68330
68331
68332
68333
68334
68335
68336
68337
68338
68339
68340
68341
68342
68343
68344
68345
68346
68347
68348
68349
68350
68351
68352
68353
68354
68355
68356
68357
68358
68359
68360
68361
68362
68363
68364
68365
68366
68367
68368
68369
68370
68371
68372
68373
68374
68375
68376
68377
68378
68379
68380
68381
68382
68383
68384
68385
68386
68387
68388
68389
68390
68391
68392
68393
68394
68395
68396
68397
68398
68399
68400
68401
68402
68403
68404
68405
68406
68407
68408
68409
68410
68411
68412
68413
68414
68415
68416
68417
68418
68419
68420
68421
68422
68423
68424
68425
68426
68427
68428
68429
68430
68431
68432
68433
68434
68435
68436
68437
68438
68439
68440
68441
68442
68443
68444
68445
68446
68447
68448
68449
68450
68451
68452
68453
68454
68455
68456
68457
68458
68459
68460
68461
68462
68463
68464
68465
68466
68467
68468
68469
68470
68471
68472
68473
68474
68475
68476
68477
68478
68479
68480
68481
68482
68483
68484
68485
68486
68487
68488
68489
68490
68491
68492
68493
68494
68495
68496
68497
68498
68499
68500
68501
68502
68503
68504
68505
68506
68507
68508
68509
68510
68511
68512
68513
68514
68515
68516
68517
68518
68519
68520
68521
68522
68523
68524
68525
68526
68527
68528
68529
68530
68531
68532
68533
68534
68535
68536
68537
68538
68539
68540
68541
68542
68543
68544
68545
68546
68547
68548
68549
68550
68551
68552
68553
68554
68555
68556
68557
68558
68559
68560
68561
68562
68563
68564
68565
68566
68567
68568
68569
68570
68571
68572
68573
68574
68575
68576
68577
68578
68579
68580
68581
68582
68583
68584
68585
68586
68587
68588
68589
68590
68591
68592
68593
68594
68595
68596
68597
68598
68599
68600
68601
68602
68603
68604
68605
68606
68607
68608
68609
68610
68611
68612
68613
68614
68615
68616
68617
68618
68619
68620
68621
68622
68623
68624
68625
68626
68627
68628
68629
68630
68631
68632
68633
68634
68635
68636
68637
68638
68639
68640
68641
68642
68643
68644
68645
68646
68647
68648
68649
68650
68651
68652
68653
68654
68655
68656
68657
68658
68659
68660
68661
68662
68663
68664
68665
68666
68667
68668
68669
68670
68671
68672
68673
68674
68675
68676
68677
68678
68679
68680
68681
68682
68683
68684
68685
68686
68687
68688
68689
68690
68691
68692
68693
68694
68695
68696
68697
68698
68699
68700
68701
68702
68703
68704
68705
68706
68707
68708
68709
68710
68711
68712
68713
68714
68715
68716
68717
68718
68719
68720
68721
68722
68723
68724
68725
68726
68727
68728
68729
68730
68731
68732
68733
68734
68735
68736
68737
68738
68739
68740
68741
68742
68743
68744
68745
68746
68747
68748
68749
68750
68751
68752
68753
68754
68755
68756
68757
68758
68759
68760
68761
68762
68763
68764
68765
68766
68767
68768
68769
68770
68771
68772
68773
68774
68775
68776
68777
68778
68779
68780
68781
68782
68783
68784
68785
68786
68787
68788
68789
68790
68791
68792
68793
68794
68795
68796
68797
68798
68799
68800
68801
68802
68803
68804
68805
68806
68807
68808
68809
68810
68811
68812
68813
68814
68815
68816
68817
68818
68819
68820
68821
68822
68823
68824
68825
68826
68827
68828
68829
68830
68831
68832
68833
68834
68835
68836
68837
68838
68839
68840
68841
68842
68843
68844
68845
68846
68847
68848
68849
68850
68851
68852
68853
68854
68855
68856
68857
68858
68859
68860
68861
68862
68863
68864
68865
68866
68867
68868
68869
68870
68871
68872
68873
68874
68875
68876
68877
68878
68879
68880
68881
68882
68883
68884
68885
68886
68887
68888
68889
68890
68891
68892
68893
68894
68895
68896
68897
68898
68899
68900
68901
68902
68903
68904
68905
68906
68907
68908
68909
68910
68911
68912
68913
68914
68915
68916
68917
68918
68919
68920
68921
68922
68923
68924
68925
68926
68927
68928
68929
68930
68931
68932
68933
68934
68935
68936
68937
68938
68939
68940
68941
68942
68943
68944
68945
68946
68947
68948
68949
68950
68951
68952
68953
68954
68955
68956
68957
68958
68959
68960
68961
68962
68963
68964
68965
68966
68967
68968
68969
68970
68971
68972
68973
68974
68975
68976
68977
68978
68979
68980
68981
68982
68983
68984
68985
68986
68987
68988
68989
68990
68991
68992
68993
68994
68995
68996
68997
68998
68999
69000
69001
69002
69003
69004
69005
69006
69007
69008
69009
69010
69011
69012
69013
69014
69015
69016
69017
69018
69019
69020
69021
69022
69023
69024
69025
69026
69027
69028
69029
69030
69031
69032
69033
69034
69035
69036
69037
69038
69039
69040
69041
69042
69043
69044
69045
69046
69047
69048
69049
69050
69051
69052
69053
69054
69055
69056
69057
69058
69059
69060
69061
69062
69063
69064
69065
69066
69067
69068
69069
69070
69071
69072
69073
69074
69075
69076
69077
69078
69079
69080
69081
69082
69083
69084
69085
69086
69087
69088
69089
69090
69091
69092
69093
69094
69095
69096
69097
69098
69099
69100
69101
69102
69103
69104
69105
69106
69107
69108
69109
69110
69111
69112
69113
69114
69115
69116
69117
69118
69119
69120
69121
69122
69123
69124
69125
69126
69127
69128
69129
69130
69131
69132
69133
69134
69135
69136
69137
69138
69139
69140
69141
69142
69143
69144
69145
69146
69147
69148
69149
69150
69151
69152
69153
69154
69155
69156
69157
69158
69159
69160
69161
69162
69163
69164
69165
69166
69167
69168
69169
69170
69171
69172
69173
69174
69175
69176
69177
69178
69179
69180
69181
69182
69183
69184
69185
69186
69187
69188
69189
69190
69191
69192
69193
69194
69195
69196
69197
69198
69199
69200
69201
69202
69203
69204
69205
69206
69207
69208
69209
69210
69211
69212
69213
69214
69215
69216
69217
69218
69219
69220
69221
69222
69223
69224
69225
69226
69227
69228
69229
69230
69231
69232
69233
69234
69235
69236
69237
69238
69239
69240
69241
69242
69243
69244
69245
69246
69247
69248
69249
69250
69251
69252
69253
69254
69255
69256
69257
69258
69259
69260
69261
69262
69263
69264
69265
69266
69267
69268
69269
69270
69271
69272
69273
69274
69275
69276
69277
69278
69279
69280
69281
69282
69283
69284
69285
69286
69287
69288
69289
69290
69291
69292
69293
69294
69295
69296
69297
69298
69299
69300
69301
69302
69303
69304
69305
69306
69307
69308
69309
69310
69311
69312
69313
69314
69315
69316
69317
69318
69319
69320
69321
69322
69323
69324
69325
69326
69327
69328
69329
69330
69331
69332
69333
69334
69335
69336
69337
69338
69339
69340
69341
69342
69343
69344
69345
69346
69347
69348
69349
69350
69351
69352
69353
69354
69355
69356
69357
69358
69359
69360
69361
69362
69363
69364
69365
69366
69367
69368
69369
69370
69371
69372
69373
69374
69375
69376
69377
69378
69379
69380
69381
69382
69383
69384
69385
69386
69387
69388
69389
69390
69391
69392
69393
69394
69395
69396
69397
69398
69399
69400
69401
69402
69403
69404
69405
69406
69407
69408
69409
69410
69411
69412
69413
69414
69415
69416
69417
69418
69419
69420
69421
69422
69423
69424
69425
69426
69427
69428
69429
69430
69431
69432
69433
69434
69435
69436
69437
69438
69439
69440
69441
69442
69443
69444
69445
69446
69447
69448
69449
69450
69451
69452
69453
69454
69455
69456
69457
69458
69459
69460
69461
69462
69463
69464
69465
69466
69467
69468
69469
69470
69471
69472
69473
69474
69475
69476
69477
69478
69479
69480
69481
69482
69483
69484
69485
69486
69487
69488
69489
69490
69491
69492
69493
69494
69495
69496
69497
69498
69499
69500
69501
69502
69503
69504
69505
69506
69507
69508
69509
69510
69511
69512
69513
69514
69515
69516
69517
69518
69519
69520
69521
69522
69523
69524
69525
69526
69527
69528
69529
69530
69531
69532
69533
69534
69535
69536
69537
69538
69539
69540
69541
69542
69543
69544
69545
69546
69547
69548
69549
69550
69551
69552
69553
69554
69555
69556
69557
69558
69559
69560
69561
69562
69563
69564
69565
69566
69567
69568
69569
69570
69571
69572
69573
69574
69575
69576
69577
69578
69579
69580
69581
69582
69583
69584
69585
69586
69587
69588
69589
69590
69591
69592
69593
69594
69595
69596
69597
69598
69599
69600
69601
69602
69603
69604
69605
69606
69607
69608
69609
69610
69611
69612
69613
69614
69615
69616
69617
69618
69619
69620
69621
69622
69623
69624
69625
69626
69627
69628
69629
69630
69631
69632
69633
69634
69635
69636
69637
69638
69639
69640
69641
69642
69643
69644
69645
69646
69647
69648
69649
69650
69651
69652
69653
69654
69655
69656
69657
69658
69659
69660
69661
69662
69663
69664
69665
69666
69667
69668
69669
69670
69671
69672
69673
69674
69675
69676
69677
69678
69679
69680
69681
69682
69683
69684
69685
69686
69687
69688
69689
69690
69691
69692
69693
69694
69695
69696
69697
69698
69699
69700
69701
69702
69703
69704
69705
69706
69707
69708
69709
69710
69711
69712
69713
69714
69715
69716
69717
69718
69719
69720
69721
69722
69723
69724
69725
69726
69727
69728
69729
69730
69731
69732
69733
69734
69735
69736
69737
69738
69739
69740
69741
69742
69743
69744
69745
69746
69747
69748
69749
69750
69751
69752
69753
69754
69755
69756
69757
69758
69759
69760
69761
69762
69763
69764
69765
69766
69767
69768
69769
69770
69771
69772
69773
69774
69775
69776
69777
69778
69779
69780
69781
69782
69783
69784
69785
69786
69787
69788
69789
69790
69791
69792
69793
69794
69795
69796
69797
69798
69799
69800
69801
69802
69803
69804
69805
69806
69807
69808
69809
69810
69811
69812
69813
69814
69815
69816
69817
69818
69819
69820
69821
69822
69823
69824
69825
69826
69827
69828
69829
69830
69831
69832
69833
69834
69835
69836
69837
69838
69839
69840
69841
69842
69843
69844
69845
69846
69847
69848
69849
69850
69851
69852
69853
69854
69855
69856
69857
69858
69859
69860
69861
69862
69863
69864
69865
69866
69867
69868
69869
69870
69871
69872
69873
69874
69875
69876
69877
69878
69879
69880
69881
69882
69883
69884
69885
69886
69887
69888
69889
69890
69891
69892
69893
69894
69895
69896
69897
69898
69899
69900
69901
69902
69903
69904
69905
69906
69907
69908
69909
69910
69911
69912
69913
69914
69915
69916
69917
69918
69919
69920
69921
69922
69923
69924
69925
69926
69927
69928
69929
69930
69931
69932
69933
69934
69935
69936
69937
69938
69939
69940
69941
69942
69943
69944
69945
69946
69947
69948
69949
69950
69951
69952
69953
69954
69955
69956
69957
69958
69959
69960
69961
69962
69963
69964
69965
69966
69967
69968
69969
69970
69971
69972
69973
69974
69975
69976
69977
69978
69979
69980
69981
69982
69983
69984
69985
69986
69987
69988
69989
69990
69991
69992
69993
69994
69995
69996
69997
69998
69999
70000
70001
70002
70003
70004
70005
70006
70007
70008
70009
70010
70011
70012
70013
70014
70015
70016
70017
70018
70019
70020
70021
70022
70023
70024
70025
70026
70027
70028
70029
70030
70031
70032
70033
70034
70035
70036
70037
70038
70039
70040
70041
70042
70043
70044
70045
70046
70047
70048
70049
70050
70051
70052
70053
70054
70055
70056
70057
70058
70059
70060
70061
70062
70063
70064
70065
70066
70067
70068
70069
70070
70071
70072
70073
70074
70075
70076
70077
70078
70079
70080
70081
70082
70083
70084
70085
70086
70087
70088
70089
70090
70091
70092
70093
70094
70095
70096
70097
70098
70099
70100
70101
70102
70103
70104
70105
70106
70107
70108
70109
70110
70111
70112
70113
70114
70115
70116
70117
70118
70119
70120
70121
70122
70123
70124
70125
70126
70127
70128
70129
70130
70131
70132
70133
70134
70135
70136
70137
70138
70139
70140
70141
70142
70143
70144
70145
70146
70147
70148
70149
70150
70151
70152
70153
70154
70155
70156
70157
70158
70159
70160
70161
70162
70163
70164
70165
70166
70167
70168
70169
70170
70171
70172
70173
70174
70175
70176
70177
70178
70179
70180
70181
70182
70183
70184
70185
70186
70187
70188
70189
70190
70191
70192
70193
70194
70195
70196
70197
70198
70199
70200
70201
70202
70203
70204
70205
70206
70207
70208
70209
70210
70211
70212
70213
70214
70215
70216
70217
70218
70219
70220
70221
70222
70223
70224
70225
70226
70227
70228
70229
70230
70231
70232
70233
70234
70235
70236
70237
70238
70239
70240
70241
70242
70243
70244
70245
70246
70247
70248
70249
70250
70251
70252
70253
70254
70255
70256
70257
70258
70259
70260
70261
70262
70263
70264
70265
70266
70267
70268
70269
70270
70271
70272
70273
70274
70275
70276
70277
70278
70279
70280
70281
70282
70283
70284
70285
70286
70287
70288
70289
70290
70291
70292
70293
70294
70295
70296
70297
70298
70299
70300
70301
70302
70303
70304
70305
70306
70307
70308
70309
70310
70311
70312
70313
70314
70315
70316
70317
70318
70319
70320
70321
70322
70323
70324
70325
70326
70327
70328
70329
70330
70331
70332
70333
70334
70335
70336
70337
70338
70339
70340
70341
70342
70343
70344
70345
70346
70347
70348
70349
70350
70351
70352
70353
70354
70355
70356
70357
70358
70359
70360
70361
70362
70363
70364
70365
70366
70367
70368
70369
70370
70371
70372
70373
70374
70375
70376
70377
70378
70379
70380
70381
70382
70383
70384
70385
70386
70387
70388
70389
70390
70391
70392
70393
70394
70395
70396
70397
70398
70399
70400
70401
70402
70403
70404
70405
70406
70407
70408
70409
70410
70411
70412
70413
70414
70415
70416
70417
70418
70419
70420
70421
70422
70423
70424
70425
70426
70427
70428
70429
70430
70431
70432
70433
70434
70435
70436
70437
70438
70439
70440
70441
70442
70443
70444
70445
70446
70447
70448
70449
70450
70451
70452
70453
70454
70455
70456
70457
70458
70459
70460
70461
70462
70463
70464
70465
70466
70467
70468
70469
70470
70471
70472
70473
70474
70475
70476
70477
70478
70479
70480
70481
70482
70483
70484
70485
70486
70487
70488
70489
70490
70491
70492
70493
70494
70495
70496
70497
70498
70499
70500
70501
70502
70503
70504
70505
70506
70507
70508
70509
70510
70511
70512
70513
70514
70515
70516
70517
70518
70519
70520
70521
70522
70523
70524
70525
70526
70527
70528
70529
70530
70531
70532
70533
70534
70535
70536
70537
70538
70539
70540
70541
70542
70543
70544
70545
70546
70547
70548
70549
70550
70551
70552
70553
70554
70555
70556
70557
70558
70559
70560
70561
70562
70563
70564
70565
70566
70567
70568
70569
70570
70571
70572
70573
70574
70575
70576
70577
70578
70579
70580
70581
70582
70583
70584
70585
70586
70587
70588
70589
70590
70591
70592
70593
70594
70595
70596
70597
70598
70599
70600
70601
70602
70603
70604
70605
70606
70607
70608
70609
70610
70611
70612
70613
70614
70615
70616
70617
70618
70619
70620
70621
70622
70623
70624
70625
70626
70627
70628
70629
70630
70631
70632
70633
70634
70635
70636
70637
70638
70639
70640
70641
70642
70643
70644
70645
70646
70647
70648
70649
70650
70651
70652
70653
70654
70655
70656
70657
70658
70659
70660
70661
70662
70663
70664
70665
70666
70667
70668
70669
70670
70671
70672
70673
70674
70675
70676
70677
70678
70679
70680
70681
70682
70683
70684
70685
70686
70687
70688
70689
70690
70691
70692
70693
70694
70695
70696
70697
70698
70699
70700
70701
70702
70703
70704
70705
70706
70707
70708
70709
70710
70711
70712
70713
70714
70715
70716
70717
70718
70719
70720
70721
70722
70723
70724
70725
70726
70727
70728
70729
70730
70731
70732
70733
70734
70735
70736
70737
70738
70739
70740
70741
70742
70743
70744
70745
70746
70747
70748
70749
70750
70751
70752
70753
70754
70755
70756
70757
70758
70759
70760
70761
70762
70763
70764
70765
70766
70767
70768
70769
70770
70771
70772
70773
70774
70775
70776
70777
70778
70779
70780
70781
70782
70783
70784
70785
70786
70787
70788
70789
70790
70791
70792
70793
70794
70795
70796
70797
70798
70799
70800
70801
70802
70803
70804
70805
70806
70807
70808
70809
70810
70811
70812
70813
70814
70815
70816
70817
70818
70819
70820
70821
70822
70823
70824
70825
70826
70827
70828
70829
70830
70831
70832
70833
70834
70835
70836
70837
70838
70839
70840
70841
70842
70843
70844
70845
70846
70847
70848
70849
70850
70851
70852
70853
70854
70855
70856
70857
70858
70859
70860
70861
70862
70863
70864
70865
70866
70867
70868
70869
70870
70871
70872
70873
70874
70875
70876
70877
70878
70879
70880
70881
70882
70883
70884
70885
70886
70887
70888
70889
70890
70891
70892
70893
70894
70895
70896
70897
70898
70899
70900
70901
70902
70903
70904
70905
70906
70907
70908
70909
70910
70911
70912
70913
70914
70915
70916
70917
70918
70919
70920
70921
70922
70923
70924
70925
70926
70927
70928
70929
70930
70931
70932
70933
70934
70935
70936
70937
70938
70939
70940
70941
70942
70943
70944
70945
70946
70947
70948
70949
70950
70951
70952
70953
70954
70955
70956
70957
70958
70959
70960
70961
70962
70963
70964
70965
70966
70967
70968
70969
70970
70971
70972
70973
70974
70975
70976
70977
70978
70979
70980
70981
70982
70983
70984
70985
70986
70987
70988
70989
70990
70991
70992
70993
70994
70995
70996
70997
70998
70999
71000
71001
71002
71003
71004
71005
71006
71007
71008
71009
71010
71011
71012
71013
71014
71015
71016
71017
71018
71019
71020
71021
71022
71023
71024
71025
71026
71027
71028
71029
71030
71031
71032
71033
71034
71035
71036
71037
71038
71039
71040
71041
71042
71043
71044
71045
71046
71047
71048
71049
71050
71051
71052
71053
71054
71055
71056
71057
71058
71059
71060
71061
71062
71063
71064
71065
71066
71067
71068
71069
71070
71071
71072
71073
71074
71075
71076
71077
71078
71079
71080
71081
71082
71083
71084
71085
71086
71087
71088
71089
71090
71091
71092
71093
71094
71095
71096
71097
71098
71099
71100
71101
71102
71103
71104
71105
71106
71107
71108
71109
71110
71111
71112
71113
71114
71115
71116
71117
71118
71119
71120
71121
71122
71123
71124
71125
71126
71127
71128
71129
71130
71131
71132
71133
71134
71135
71136
71137
71138
71139
71140
71141
71142
71143
71144
71145
71146
71147
71148
71149
71150
71151
71152
71153
71154
71155
71156
71157
71158
71159
71160
71161
71162
71163
71164
71165
71166
71167
71168
71169
71170
71171
71172
71173
71174
71175
71176
71177
71178
71179
71180
71181
71182
71183
71184
71185
71186
71187
71188
71189
71190
71191
71192
71193
71194
71195
71196
71197
71198
71199
71200
71201
71202
71203
71204
71205
71206
71207
71208
71209
71210
71211
71212
71213
71214
71215
71216
71217
71218
71219
71220
71221
71222
71223
71224
71225
71226
71227
71228
71229
71230
71231
71232
71233
71234
71235
71236
71237
71238
71239
71240
71241
71242
71243
71244
71245
71246
71247
71248
71249
71250
71251
71252
71253
71254
71255
71256
71257
71258
71259
71260
71261
71262
71263
71264
71265
71266
71267
71268
71269
71270
71271
71272
71273
71274
71275
71276
71277
71278
71279
71280
71281
71282
71283
71284
71285
71286
71287
71288
71289
71290
71291
71292
71293
71294
71295
71296
71297
71298
71299
71300
71301
71302
71303
71304
71305
71306
71307
71308
71309
71310
71311
71312
71313
71314
71315
71316
71317
71318
71319
71320
71321
71322
71323
71324
71325
71326
71327
71328
71329
71330
71331
71332
71333
71334
71335
71336
71337
71338
71339
71340
71341
71342
71343
71344
71345
71346
71347
71348
71349
71350
71351
71352
71353
71354
71355
71356
71357
71358
71359
71360
71361
71362
71363
71364
71365
71366
71367
71368
71369
71370
71371
71372
71373
71374
71375
71376
71377
71378
71379
71380
71381
71382
71383
71384
71385
71386
71387
71388
71389
71390
71391
71392
71393
71394
71395
71396
71397
71398
71399
71400
71401
71402
71403
71404
71405
71406
71407
71408
71409
71410
71411
71412
71413
71414
71415
71416
71417
71418
71419
71420
71421
71422
71423
71424
71425
71426
71427
71428
71429
71430
71431
71432
71433
71434
71435
71436
71437
71438
71439
71440
71441
71442
71443
71444
71445
71446
71447
71448
71449
71450
71451
71452
71453
71454
71455
71456
71457
71458
71459
71460
71461
71462
71463
71464
71465
71466
71467
71468
71469
71470
71471
71472
71473
71474
71475
71476
71477
71478
71479
71480
71481
71482
71483
71484
71485
71486
71487
71488
71489
71490
71491
71492
71493
71494
71495
71496
71497
71498
71499
71500
71501
71502
71503
71504
71505
71506
71507
71508
71509
71510
71511
71512
71513
71514
71515
71516
71517
71518
71519
71520
71521
71522
71523
71524
71525
71526
71527
71528
71529
71530
71531
71532
71533
71534
71535
71536
71537
71538
71539
71540
71541
71542
71543
71544
71545
71546
71547
71548
71549
71550
71551
71552
71553
71554
71555
71556
71557
71558
71559
71560
71561
71562
71563
71564
71565
71566
71567
71568
71569
71570
71571
71572
71573
71574
71575
71576
71577
71578
71579
71580
71581
71582
71583
71584
71585
71586
71587
71588
71589
71590
71591
71592
71593
71594
71595
71596
71597
71598
71599
71600
71601
71602
71603
71604
71605
71606
71607
71608
71609
71610
71611
71612
71613
71614
71615
71616
71617
71618
71619
71620
71621
71622
71623
71624
71625
71626
71627
71628
71629
71630
71631
71632
71633
71634
71635
71636
71637
71638
71639
71640
71641
71642
71643
71644
71645
71646
71647
71648
71649
71650
71651
71652
71653
71654
71655
71656
71657
71658
71659
71660
71661
71662
71663
71664
71665
71666
71667
71668
71669
71670
71671
71672
71673
71674
71675
71676
71677
71678
71679
71680
71681
71682
71683
71684
71685
71686
71687
71688
71689
71690
71691
71692
71693
71694
71695
71696
71697
71698
71699
71700
71701
71702
71703
71704
71705
71706
71707
71708
71709
71710
71711
71712
71713
71714
71715
71716
71717
71718
71719
71720
71721
71722
71723
71724
71725
71726
71727
71728
71729
71730
71731
71732
71733
71734
71735
71736
71737
71738
71739
71740
71741
71742
71743
71744
71745
71746
71747
71748
71749
71750
71751
71752
71753
71754
71755
71756
71757
71758
71759
71760
71761
71762
71763
71764
71765
71766
71767
71768
71769
71770
71771
71772
71773
71774
71775
71776
71777
71778
71779
71780
71781
71782
71783
71784
71785
71786
71787
71788
71789
71790
71791
71792
71793
71794
71795
71796
71797
71798
71799
71800
71801
71802
71803
71804
71805
71806
71807
71808
71809
71810
71811
71812
71813
71814
71815
71816
71817
71818
71819
71820
71821
71822
71823
71824
71825
71826
71827
71828
71829
71830
71831
71832
71833
71834
71835
71836
71837
71838
71839
71840
71841
71842
71843
71844
71845
71846
71847
71848
71849
71850
71851
71852
71853
71854
71855
71856
71857
71858
71859
71860
71861
71862
71863
71864
71865
71866
71867
71868
71869
71870
71871
71872
71873
71874
71875
71876
71877
71878
71879
71880
71881
71882
71883
71884
71885
71886
71887
71888
71889
71890
71891
71892
71893
71894
71895
71896
71897
71898
71899
71900
71901
71902
71903
71904
71905
71906
71907
71908
71909
71910
71911
71912
71913
71914
71915
71916
71917
71918
71919
71920
71921
71922
71923
71924
71925
71926
71927
71928
71929
71930
71931
71932
71933
71934
71935
71936
71937
71938
71939
71940
71941
71942
71943
71944
71945
71946
71947
71948
71949
71950
71951
71952
71953
71954
71955
71956
71957
71958
71959
71960
71961
71962
71963
71964
71965
71966
71967
71968
71969
71970
71971
71972
71973
71974
71975
71976
71977
71978
71979
71980
71981
71982
71983
71984
71985
71986
71987
71988
71989
71990
71991
71992
71993
71994
71995
71996
71997
71998
71999
72000
72001
72002
72003
72004
72005
72006
72007
72008
72009
72010
72011
72012
72013
72014
72015
72016
72017
72018
72019
72020
72021
72022
72023
72024
72025
72026
72027
72028
72029
72030
72031
72032
72033
72034
72035
72036
72037
72038
72039
72040
72041
72042
72043
72044
72045
72046
72047
72048
72049
72050
72051
72052
72053
72054
72055
72056
72057
72058
72059
72060
72061
72062
72063
72064
72065
72066
72067
72068
72069
72070
72071
72072
72073
72074
72075
72076
72077
72078
72079
72080
72081
72082
72083
72084
72085
72086
72087
72088
72089
72090
72091
72092
72093
72094
72095
72096
72097
72098
72099
72100
72101
72102
72103
72104
72105
72106
72107
72108
72109
72110
72111
72112
72113
72114
72115
72116
72117
72118
72119
72120
72121
72122
72123
72124
72125
72126
72127
72128
72129
72130
72131
72132
72133
72134
72135
72136
72137
72138
72139
72140
72141
72142
72143
72144
72145
72146
72147
72148
72149
72150
72151
72152
72153
72154
72155
72156
72157
72158
72159
72160
72161
72162
72163
72164
72165
72166
72167
72168
72169
72170
72171
72172
72173
72174
72175
72176
72177
72178
72179
72180
72181
72182
72183
72184
72185
72186
72187
72188
72189
72190
72191
72192
72193
72194
72195
72196
72197
72198
72199
72200
72201
72202
72203
72204
72205
72206
72207
72208
72209
72210
72211
72212
72213
72214
72215
72216
72217
72218
72219
72220
72221
72222
72223
72224
72225
72226
72227
72228
72229
72230
72231
72232
72233
72234
72235
72236
72237
72238
72239
72240
72241
72242
72243
72244
72245
72246
72247
72248
72249
72250
72251
72252
72253
72254
72255
72256
72257
72258
72259
72260
72261
72262
72263
72264
72265
72266
72267
72268
72269
72270
72271
72272
72273
72274
72275
72276
72277
72278
72279
72280
72281
72282
72283
72284
72285
72286
72287
72288
72289
72290
72291
72292
72293
72294
72295
72296
72297
72298
72299
72300
72301
72302
72303
72304
72305
72306
72307
72308
72309
72310
72311
72312
72313
72314
72315
72316
72317
72318
72319
72320
72321
72322
72323
72324
72325
72326
72327
72328
72329
72330
72331
72332
72333
72334
72335
72336
72337
72338
72339
72340
72341
72342
72343
72344
72345
72346
72347
72348
72349
72350
72351
72352
72353
72354
72355
72356
72357
72358
72359
72360
72361
72362
72363
72364
72365
72366
72367
72368
72369
72370
72371
72372
72373
72374
72375
72376
72377
72378
72379
72380
72381
72382
72383
72384
72385
72386
72387
72388
72389
72390
72391
72392
72393
72394
72395
72396
72397
72398
72399
72400
72401
72402
72403
72404
72405
72406
72407
72408
72409
72410
72411
72412
72413
72414
72415
72416
72417
72418
72419
72420
72421
72422
72423
72424
72425
72426
72427
72428
72429
72430
72431
72432
72433
72434
72435
72436
72437
72438
72439
72440
72441
72442
72443
72444
72445
72446
72447
72448
72449
72450
72451
72452
72453
72454
72455
72456
72457
72458
72459
72460
72461
72462
72463
72464
72465
72466
72467
72468
72469
72470
72471
72472
72473
72474
72475
72476
72477
72478
72479
72480
72481
72482
72483
72484
72485
72486
72487
72488
72489
72490
72491
72492
72493
72494
72495
72496
72497
72498
72499
72500
72501
72502
72503
72504
72505
72506
72507
72508
72509
72510
72511
72512
72513
72514
72515
72516
72517
72518
72519
72520
72521
72522
72523
72524
72525
72526
72527
72528
72529
72530
72531
72532
72533
72534
72535
72536
72537
72538
72539
72540
72541
72542
72543
72544
72545
72546
72547
72548
72549
72550
72551
72552
72553
72554
72555
72556
72557
72558
72559
72560
72561
72562
72563
72564
72565
72566
72567
72568
72569
72570
72571
72572
72573
72574
72575
72576
72577
72578
72579
72580
72581
72582
72583
72584
72585
72586
72587
72588
72589
72590
72591
72592
72593
72594
72595
72596
72597
72598
72599
72600
72601
72602
72603
72604
72605
72606
72607
72608
72609
72610
72611
72612
72613
72614
72615
72616
72617
72618
72619
72620
72621
72622
72623
72624
72625
72626
72627
72628
72629
72630
72631
72632
72633
72634
72635
72636
72637
72638
72639
72640
72641
72642
72643
72644
72645
72646
72647
72648
72649
72650
72651
72652
72653
72654
72655
72656
72657
72658
72659
72660
72661
72662
72663
72664
72665
72666
72667
72668
72669
72670
72671
72672
72673
72674
72675
72676
72677
72678
72679
72680
72681
72682
72683
72684
72685
72686
72687
72688
72689
72690
72691
72692
72693
72694
72695
72696
72697
72698
72699
72700
72701
72702
72703
72704
72705
72706
72707
72708
72709
72710
72711
72712
72713
72714
72715
72716
72717
72718
72719
72720
72721
72722
72723
72724
72725
72726
72727
72728
72729
72730
72731
72732
72733
72734
72735
72736
72737
72738
72739
72740
72741
72742
72743
72744
72745
72746
72747
72748
72749
72750
72751
72752
72753
72754
72755
72756
72757
72758
72759
72760
72761
72762
72763
72764
72765
72766
72767
72768
72769
72770
72771
72772
72773
72774
72775
72776
72777
72778
72779
72780
72781
72782
72783
72784
72785
72786
72787
72788
72789
72790
72791
72792
72793
72794
72795
72796
72797
72798
72799
72800
72801
72802
72803
72804
72805
72806
72807
72808
72809
72810
72811
72812
72813
72814
72815
72816
72817
72818
72819
72820
72821
72822
72823
72824
72825
72826
72827
72828
72829
72830
72831
72832
72833
72834
72835
72836
72837
72838
72839
72840
72841
72842
72843
72844
72845
72846
72847
72848
72849
72850
72851
72852
72853
72854
72855
72856
72857
72858
72859
72860
72861
72862
72863
72864
72865
72866
72867
72868
72869
72870
72871
72872
72873
72874
72875
72876
72877
72878
72879
72880
72881
72882
72883
72884
72885
72886
72887
72888
72889
72890
72891
72892
72893
72894
72895
72896
72897
72898
72899
72900
72901
72902
72903
72904
72905
72906
72907
72908
72909
72910
72911
72912
72913
72914
72915
72916
72917
72918
72919
72920
72921
72922
72923
72924
72925
72926
72927
72928
72929
72930
72931
72932
72933
72934
72935
72936
72937
72938
72939
72940
72941
72942
72943
72944
72945
72946
72947
72948
72949
72950
72951
72952
72953
72954
72955
72956
72957
72958
72959
72960
72961
72962
72963
72964
72965
72966
72967
72968
72969
72970
72971
72972
72973
72974
72975
72976
72977
72978
72979
72980
72981
72982
72983
72984
72985
72986
72987
72988
72989
72990
72991
72992
72993
72994
72995
72996
72997
72998
72999
73000
73001
73002
73003
73004
73005
73006
73007
73008
73009
73010
73011
73012
73013
73014
73015
73016
73017
73018
73019
73020
73021
73022
73023
73024
73025
73026
73027
73028
73029
73030
73031
73032
73033
73034
73035
73036
73037
73038
73039
73040
73041
73042
73043
73044
73045
73046
73047
73048
73049
73050
73051
73052
73053
73054
73055
73056
73057
73058
73059
73060
73061
73062
73063
73064
73065
73066
73067
73068
73069
73070
73071
73072
73073
73074
73075
73076
73077
73078
73079
73080
73081
73082
73083
73084
73085
73086
73087
73088
73089
73090
73091
73092
73093
73094
73095
73096
73097
73098
73099
73100
73101
73102
73103
73104
73105
73106
73107
73108
73109
73110
73111
73112
73113
73114
73115
73116
73117
73118
73119
73120
73121
73122
73123
73124
73125
73126
73127
73128
73129
73130
73131
73132
73133
73134
73135
73136
73137
73138
73139
73140
73141
73142
73143
73144
73145
73146
73147
73148
73149
73150
73151
73152
73153
73154
73155
73156
73157
73158
73159
73160
73161
73162
73163
73164
73165
73166
73167
73168
73169
73170
73171
73172
73173
73174
73175
73176
73177
73178
73179
73180
73181
73182
73183
73184
73185
73186
73187
73188
73189
73190
73191
73192
73193
73194
73195
73196
73197
73198
73199
73200
73201
73202
73203
73204
73205
73206
73207
73208
73209
73210
73211
73212
73213
73214
73215
73216
73217
73218
73219
73220
73221
73222
73223
73224
73225
73226
73227
73228
73229
73230
73231
73232
73233
73234
73235
73236
73237
73238
73239
73240
73241
73242
73243
73244
73245
73246
73247
73248
73249
73250
73251
73252
73253
73254
73255
73256
73257
73258
73259
73260
73261
73262
73263
73264
73265
73266
73267
73268
73269
73270
73271
73272
73273
73274
73275
73276
73277
73278
73279
73280
73281
73282
73283
73284
73285
73286
73287
73288
73289
73290
73291
73292
73293
73294
73295
73296
73297
73298
73299
73300
73301
73302
73303
73304
73305
73306
73307
73308
73309
73310
73311
73312
73313
73314
73315
73316
73317
73318
73319
73320
73321
73322
73323
73324
73325
73326
73327
73328
73329
73330
73331
73332
73333
73334
73335
73336
73337
73338
73339
73340
73341
73342
73343
73344
73345
73346
73347
73348
73349
73350
73351
73352
73353
73354
73355
73356
73357
73358
73359
73360
73361
73362
73363
73364
73365
73366
73367
73368
73369
73370
73371
73372
73373
73374
73375
73376
73377
73378
73379
73380
73381
73382
73383
73384
73385
73386
73387
73388
73389
73390
73391
73392
73393
73394
73395
73396
73397
73398
73399
73400
73401
73402
73403
73404
73405
73406
73407
73408
73409
73410
73411
73412
73413
73414
73415
73416
73417
73418
73419
73420
73421
73422
73423
73424
73425
73426
73427
73428
73429
73430
73431
73432
73433
73434
73435
73436
73437
73438
73439
73440
73441
73442
73443
73444
73445
73446
73447
73448
73449
73450
73451
73452
73453
73454
73455
73456
73457
73458
73459
73460
73461
73462
73463
73464
73465
73466
73467
73468
73469
73470
73471
73472
73473
73474
73475
73476
73477
73478
73479
73480
73481
73482
73483
73484
73485
73486
73487
73488
73489
73490
73491
73492
73493
73494
73495
73496
73497
73498
73499
73500
73501
73502
73503
73504
73505
73506
73507
73508
73509
73510
73511
73512
73513
73514
73515
73516
73517
73518
73519
73520
73521
73522
73523
73524
73525
73526
73527
73528
73529
73530
73531
73532
73533
73534
73535
73536
73537
73538
73539
73540
73541
73542
73543
73544
73545
73546
73547
73548
73549
73550
73551
73552
73553
73554
73555
73556
73557
73558
73559
73560
73561
73562
73563
73564
73565
73566
73567
73568
73569
73570
73571
73572
73573
73574
73575
73576
73577
73578
73579
73580
73581
73582
73583
73584
73585
73586
73587
73588
73589
73590
73591
73592
73593
73594
73595
73596
73597
73598
73599
73600
73601
73602
73603
73604
73605
73606
73607
73608
73609
73610
73611
73612
73613
73614
73615
73616
73617
73618
73619
73620
73621
73622
73623
73624
73625
73626
73627
73628
73629
73630
73631
73632
73633
73634
73635
73636
73637
73638
73639
73640
73641
73642
73643
73644
73645
73646
73647
73648
73649
73650
73651
73652
73653
73654
73655
73656
73657
73658
73659
73660
73661
73662
73663
73664
73665
73666
73667
73668
73669
73670
73671
73672
73673
73674
73675
73676
73677
73678
73679
73680
73681
73682
73683
73684
73685
73686
73687
73688
73689
73690
73691
73692
73693
73694
73695
73696
73697
73698
73699
73700
73701
73702
73703
73704
73705
73706
73707
73708
73709
73710
73711
73712
73713
73714
73715
73716
73717
73718
73719
73720
73721
73722
73723
73724
73725
73726
73727
73728
73729
73730
73731
73732
73733
73734
73735
73736
73737
73738
73739
73740
73741
73742
73743
73744
73745
73746
73747
73748
73749
73750
73751
73752
73753
73754
73755
73756
73757
73758
73759
73760
73761
73762
73763
73764
73765
73766
73767
73768
73769
73770
73771
73772
73773
73774
73775
73776
73777
73778
73779
73780
73781
73782
73783
73784
73785
73786
73787
73788
73789
73790
73791
73792
73793
73794
73795
73796
73797
73798
73799
73800
73801
73802
73803
73804
73805
73806
73807
73808
73809
73810
73811
73812
73813
73814
73815
73816
73817
73818
73819
73820
73821
73822
73823
73824
73825
73826
73827
73828
73829
73830
73831
73832
73833
73834
73835
73836
73837
73838
73839
73840
73841
73842
73843
73844
73845
73846
73847
73848
73849
73850
73851
73852
73853
73854
73855
73856
73857
73858
73859
73860
73861
73862
73863
73864
73865
73866
73867
73868
73869
73870
73871
73872
73873
73874
73875
73876
73877
73878
73879
73880
73881
73882
73883
73884
73885
73886
73887
73888
73889
73890
73891
73892
73893
73894
73895
73896
73897
73898
73899
73900
73901
73902
73903
73904
73905
73906
73907
73908
73909
73910
73911
73912
73913
73914
73915
73916
73917
73918
73919
73920
73921
73922
73923
73924
73925
73926
73927
73928
73929
73930
73931
73932
73933
73934
73935
73936
73937
73938
73939
73940
73941
73942
73943
73944
73945
73946
73947
73948
73949
73950
73951
73952
73953
73954
73955
73956
73957
73958
73959
73960
73961
73962
73963
73964
73965
73966
73967
73968
73969
73970
73971
73972
73973
73974
73975
73976
73977
73978
73979
73980
73981
73982
73983
73984
73985
73986
73987
73988
73989
73990
73991
73992
73993
73994
73995
73996
73997
73998
73999
74000
74001
74002
74003
74004
74005
74006
74007
74008
74009
74010
74011
74012
74013
74014
74015
74016
74017
74018
74019
74020
74021
74022
74023
74024
74025
74026
74027
74028
74029
74030
74031
74032
74033
74034
74035
74036
74037
74038
74039
74040
74041
74042
74043
74044
74045
74046
74047
74048
74049
74050
74051
74052
74053
74054
74055
74056
74057
74058
74059
74060
74061
74062
74063
74064
74065
74066
74067
74068
74069
74070
74071
74072
74073
74074
74075
74076
74077
74078
74079
74080
74081
74082
74083
74084
74085
74086
74087
74088
74089
74090
74091
74092
74093
74094
74095
74096
74097
74098
74099
74100
74101
74102
74103
74104
74105
74106
74107
74108
74109
74110
74111
74112
74113
74114
74115
74116
74117
74118
74119
74120
74121
74122
74123
74124
74125
74126
74127
74128
74129
74130
74131
74132
74133
74134
74135
74136
74137
74138
74139
74140
74141
74142
74143
74144
74145
74146
74147
74148
74149
74150
74151
74152
74153
74154
74155
74156
74157
74158
74159
74160
74161
74162
74163
74164
74165
74166
74167
74168
74169
74170
74171
74172
74173
74174
74175
74176
74177
74178
74179
74180
74181
74182
74183
74184
74185
74186
74187
74188
74189
74190
74191
74192
74193
74194
74195
74196
74197
74198
74199
74200
74201
74202
74203
74204
74205
74206
74207
74208
74209
74210
74211
74212
74213
74214
74215
74216
74217
74218
74219
74220
74221
74222
74223
74224
74225
74226
74227
74228
74229
74230
74231
74232
74233
74234
74235
74236
74237
74238
74239
74240
74241
74242
74243
74244
74245
74246
74247
74248
74249
74250
74251
74252
74253
74254
74255
74256
74257
74258
74259
74260
74261
74262
74263
74264
74265
74266
74267
74268
74269
74270
74271
74272
74273
74274
74275
74276
74277
74278
74279
74280
74281
74282
74283
74284
74285
74286
74287
74288
74289
74290
74291
74292
74293
74294
74295
74296
74297
74298
74299
74300
74301
74302
74303
74304
74305
74306
74307
74308
74309
74310
74311
74312
74313
74314
74315
74316
74317
74318
74319
74320
74321
74322
74323
74324
74325
74326
74327
74328
74329
74330
74331
74332
74333
74334
74335
74336
74337
74338
74339
74340
74341
74342
74343
74344
74345
74346
74347
74348
74349
74350
74351
74352
74353
74354
74355
74356
74357
74358
74359
74360
74361
74362
74363
74364
74365
74366
74367
74368
74369
74370
74371
74372
74373
74374
74375
74376
74377
74378
74379
74380
74381
74382
74383
74384
74385
74386
74387
74388
74389
74390
74391
74392
74393
74394
74395
74396
74397
74398
74399
74400
74401
74402
74403
74404
74405
74406
74407
74408
74409
74410
74411
74412
74413
74414
74415
74416
74417
74418
74419
74420
74421
74422
74423
74424
74425
74426
74427
74428
74429
74430
74431
74432
74433
74434
74435
74436
74437
74438
74439
74440
74441
74442
74443
74444
74445
74446
74447
74448
74449
74450
74451
74452
74453
74454
74455
74456
74457
74458
74459
74460
74461
74462
74463
74464
74465
74466
74467
74468
74469
74470
74471
74472
74473
74474
74475
74476
74477
74478
74479
74480
74481
74482
74483
74484
74485
74486
74487
74488
74489
74490
74491
74492
74493
74494
74495
74496
74497
74498
74499
74500
74501
74502
74503
74504
74505
74506
74507
74508
74509
74510
74511
74512
74513
74514
74515
74516
74517
74518
74519
74520
74521
74522
74523
74524
74525
74526
74527
74528
74529
74530
74531
74532
74533
74534
74535
74536
74537
74538
74539
74540
74541
74542
74543
74544
74545
74546
74547
74548
74549
74550
74551
74552
74553
74554
74555
74556
74557
74558
74559
74560
74561
74562
74563
74564
74565
74566
74567
74568
74569
74570
74571
74572
74573
74574
74575
74576
74577
74578
74579
74580
74581
74582
74583
74584
74585
74586
74587
74588
74589
74590
74591
74592
74593
74594
74595
74596
74597
74598
74599
74600
74601
74602
74603
74604
74605
74606
74607
74608
74609
74610
74611
74612
74613
74614
74615
74616
74617
74618
74619
74620
74621
74622
74623
74624
74625
74626
74627
74628
74629
74630
74631
74632
74633
74634
74635
74636
74637
74638
74639
74640
74641
74642
74643
74644
74645
74646
74647
74648
74649
74650
74651
74652
74653
74654
74655
74656
74657
74658
74659
74660
74661
74662
74663
74664
74665
74666
74667
74668
74669
74670
74671
74672
74673
74674
74675
74676
74677
74678
74679
74680
74681
74682
74683
74684
74685
74686
74687
74688
74689
74690
74691
74692
74693
74694
74695
74696
74697
74698
74699
74700
74701
74702
74703
74704
74705
74706
74707
74708
74709
74710
74711
74712
74713
74714
74715
74716
74717
74718
74719
74720
74721
74722
74723
74724
74725
74726
74727
74728
74729
74730
74731
74732
74733
74734
74735
74736
74737
74738
74739
74740
74741
74742
74743
74744
74745
74746
74747
74748
74749
74750
74751
74752
74753
74754
74755
74756
74757
74758
74759
74760
74761
74762
74763
74764
74765
74766
74767
74768
74769
74770
74771
74772
74773
74774
74775
74776
74777
74778
74779
74780
74781
74782
74783
74784
74785
74786
74787
74788
74789
74790
74791
74792
74793
74794
74795
74796
74797
74798
74799
74800
74801
74802
74803
74804
74805
74806
74807
74808
74809
74810
74811
74812
74813
74814
74815
74816
74817
74818
74819
74820
74821
74822
74823
74824
74825
74826
74827
74828
74829
74830
74831
74832
74833
74834
74835
74836
74837
74838
74839
74840
74841
74842
74843
74844
74845
74846
74847
74848
74849
74850
74851
74852
74853
74854
74855
74856
74857
74858
74859
74860
74861
74862
74863
74864
74865
74866
74867
74868
74869
74870
74871
74872
74873
74874
74875
74876
74877
74878
74879
74880
74881
74882
74883
74884
74885
74886
74887
74888
74889
74890
74891
74892
74893
74894
74895
74896
74897
74898
74899
74900
74901
74902
74903
74904
74905
74906
74907
74908
74909
74910
74911
74912
74913
74914
74915
74916
74917
74918
74919
74920
74921
74922
74923
74924
74925
74926
74927
74928
74929
74930
74931
74932
74933
74934
74935
74936
74937
74938
74939
74940
74941
74942
74943
74944
74945
74946
74947
74948
74949
74950
74951
74952
74953
74954
74955
74956
74957
74958
74959
74960
74961
74962
74963
74964
74965
74966
74967
74968
74969
74970
74971
74972
74973
74974
74975
74976
74977
74978
74979
74980
74981
74982
74983
74984
74985
74986
74987
74988
74989
74990
74991
74992
74993
74994
74995
74996
74997
74998
74999
75000
75001
75002
75003
75004
75005
75006
75007
75008
75009
75010
75011
75012
75013
75014
75015
75016
75017
75018
75019
75020
75021
75022
75023
75024
75025
75026
75027
75028
75029
75030
75031
75032
75033
75034
75035
75036
75037
75038
75039
75040
75041
75042
75043
75044
75045
75046
75047
75048
75049
75050
75051
75052
75053
75054
75055
75056
75057
75058
75059
75060
75061
75062
75063
75064
75065
75066
75067
75068
75069
75070
75071
75072
75073
75074
75075
75076
75077
75078
75079
75080
75081
75082
75083
75084
75085
75086
75087
75088
75089
75090
75091
75092
75093
75094
75095
75096
75097
75098
75099
75100
75101
75102
75103
75104
75105
75106
75107
75108
75109
75110
75111
75112
75113
75114
75115
75116
75117
75118
75119
75120
75121
75122
75123
75124
75125
75126
75127
75128
75129
75130
75131
75132
75133
75134
75135
75136
75137
75138
75139
75140
75141
75142
75143
75144
75145
75146
75147
75148
75149
75150
75151
75152
75153
75154
75155
75156
75157
75158
75159
75160
75161
75162
75163
75164
75165
75166
75167
75168
75169
75170
75171
75172
75173
75174
75175
75176
75177
75178
75179
75180
75181
75182
75183
75184
75185
75186
75187
75188
75189
75190
75191
75192
75193
75194
75195
75196
75197
75198
75199
75200
75201
75202
75203
75204
75205
75206
75207
75208
75209
75210
75211
75212
75213
75214
75215
75216
75217
75218
75219
75220
75221
75222
75223
75224
75225
75226
75227
75228
75229
75230
75231
75232
75233
75234
75235
75236
75237
75238
75239
75240
75241
75242
75243
75244
75245
75246
75247
75248
75249
75250
75251
75252
75253
75254
75255
75256
75257
75258
75259
75260
75261
75262
75263
75264
75265
75266
75267
75268
75269
75270
75271
75272
75273
75274
75275
75276
75277
75278
75279
75280
75281
75282
75283
75284
75285
75286
75287
75288
75289
75290
75291
75292
75293
75294
75295
75296
75297
75298
75299
75300
75301
75302
75303
75304
75305
75306
75307
75308
75309
75310
75311
75312
75313
75314
75315
75316
75317
75318
75319
75320
75321
75322
75323
75324
75325
75326
75327
75328
75329
75330
75331
75332
75333
75334
75335
75336
75337
75338
75339
75340
75341
75342
75343
75344
75345
75346
75347
75348
75349
75350
75351
75352
75353
75354
75355
75356
75357
75358
75359
75360
75361
75362
75363
75364
75365
75366
75367
75368
75369
75370
75371
75372
75373
75374
75375
75376
75377
75378
75379
75380
75381
75382
75383
75384
75385
75386
75387
75388
75389
75390
75391
75392
75393
75394
75395
75396
75397
75398
75399
75400
75401
75402
75403
75404
75405
75406
75407
75408
75409
75410
75411
75412
75413
75414
75415
75416
75417
75418
75419
75420
75421
75422
75423
75424
75425
75426
75427
75428
75429
75430
75431
75432
75433
75434
75435
75436
75437
75438
75439
75440
75441
75442
75443
75444
75445
75446
75447
75448
75449
75450
75451
75452
75453
75454
75455
75456
75457
75458
75459
75460
75461
75462
75463
75464
75465
75466
75467
75468
75469
75470
75471
75472
75473
75474
75475
75476
75477
75478
75479
75480
75481
75482
75483
75484
75485
75486
75487
75488
75489
75490
75491
75492
75493
75494
75495
75496
75497
75498
75499
75500
75501
75502
75503
75504
75505
75506
75507
75508
75509
75510
75511
75512
75513
75514
75515
75516
75517
75518
75519
75520
75521
75522
75523
75524
75525
75526
75527
75528
75529
75530
75531
75532
75533
75534
75535
75536
75537
75538
75539
75540
75541
75542
75543
75544
75545
75546
75547
75548
75549
75550
75551
75552
75553
75554
75555
75556
75557
75558
75559
75560
75561
75562
75563
75564
75565
75566
75567
75568
75569
75570
75571
75572
75573
75574
75575
75576
75577
75578
75579
75580
75581
75582
75583
75584
75585
75586
75587
75588
75589
75590
75591
75592
75593
75594
75595
75596
75597
75598
75599
75600
75601
75602
75603
75604
75605
75606
75607
75608
75609
75610
75611
75612
75613
75614
75615
75616
75617
75618
75619
75620
75621
75622
75623
75624
75625
75626
75627
75628
75629
75630
75631
75632
75633
75634
75635
75636
75637
75638
75639
75640
75641
75642
75643
75644
75645
75646
75647
75648
75649
75650
75651
75652
75653
75654
75655
75656
75657
75658
75659
75660
75661
75662
75663
75664
75665
75666
75667
75668
75669
75670
75671
75672
75673
75674
75675
75676
75677
75678
75679
75680
75681
75682
75683
75684
75685
75686
75687
75688
75689
75690
75691
75692
75693
75694
75695
75696
75697
75698
75699
75700
75701
75702
75703
75704
75705
75706
75707
75708
75709
75710
75711
75712
75713
75714
75715
75716
75717
75718
75719
75720
75721
75722
75723
75724
75725
75726
75727
75728
75729
75730
75731
75732
75733
75734
75735
75736
75737
75738
75739
75740
75741
75742
75743
75744
75745
75746
75747
75748
75749
75750
75751
75752
75753
75754
75755
75756
75757
75758
75759
75760
75761
75762
75763
75764
75765
75766
75767
75768
75769
75770
75771
75772
75773
75774
75775
75776
75777
75778
75779
75780
75781
75782
75783
75784
75785
75786
75787
75788
75789
75790
75791
75792
75793
75794
75795
75796
75797
75798
75799
75800
75801
75802
75803
75804
75805
75806
75807
75808
75809
75810
75811
75812
75813
75814
75815
75816
75817
75818
75819
75820
75821
75822
75823
75824
75825
75826
75827
75828
75829
75830
75831
75832
75833
75834
75835
75836
75837
75838
75839
75840
75841
75842
75843
75844
75845
75846
75847
75848
75849
75850
75851
75852
75853
75854
75855
75856
75857
75858
75859
75860
75861
75862
75863
75864
75865
75866
75867
75868
75869
75870
75871
75872
75873
75874
75875
75876
75877
75878
75879
75880
75881
75882
75883
75884
75885
75886
75887
75888
75889
75890
75891
75892
75893
75894
75895
75896
75897
75898
75899
75900
75901
75902
75903
75904
75905
75906
75907
75908
75909
75910
75911
75912
75913
75914
75915
75916
75917
75918
75919
75920
75921
75922
75923
75924
75925
75926
75927
75928
75929
75930
75931
75932
75933
75934
75935
75936
75937
75938
75939
75940
75941
75942
75943
75944
75945
75946
75947
75948
75949
75950
75951
75952
75953
75954
75955
75956
75957
75958
75959
75960
75961
75962
75963
75964
75965
75966
75967
75968
75969
75970
75971
75972
75973
75974
75975
75976
75977
75978
75979
75980
75981
75982
75983
75984
75985
75986
75987
75988
75989
75990
75991
75992
75993
75994
75995
75996
75997
75998
75999
76000
76001
76002
76003
76004
76005
76006
76007
76008
76009
76010
76011
76012
76013
76014
76015
76016
76017
76018
76019
76020
76021
76022
76023
76024
76025
76026
76027
76028
76029
76030
76031
76032
76033
76034
76035
76036
76037
76038
76039
76040
76041
76042
76043
76044
76045
76046
76047
76048
76049
76050
76051
76052
76053
76054
76055
76056
76057
76058
76059
76060
76061
76062
76063
76064
76065
76066
76067
76068
76069
76070
76071
76072
76073
76074
76075
76076
76077
76078
76079
76080
76081
76082
76083
76084
76085
76086
76087
76088
76089
76090
76091
76092
76093
76094
76095
76096
76097
76098
76099
76100
76101
76102
76103
76104
76105
76106
76107
76108
76109
76110
76111
76112
76113
76114
76115
76116
76117
76118
76119
76120
76121
76122
76123
76124
76125
76126
76127
76128
76129
76130
76131
76132
76133
76134
76135
76136
76137
76138
76139
76140
76141
76142
76143
76144
76145
76146
76147
76148
76149
76150
76151
76152
76153
76154
76155
76156
76157
76158
76159
76160
76161
76162
76163
76164
76165
76166
76167
76168
76169
76170
76171
76172
76173
76174
76175
76176
76177
76178
76179
76180
76181
76182
76183
76184
76185
76186
76187
76188
76189
76190
76191
76192
76193
76194
76195
76196
76197
76198
76199
76200
76201
76202
76203
76204
76205
76206
76207
76208
76209
76210
76211
76212
76213
76214
76215
76216
76217
76218
76219
76220
76221
76222
76223
76224
76225
76226
76227
76228
76229
76230
76231
76232
76233
76234
76235
76236
76237
76238
76239
76240
76241
76242
76243
76244
76245
76246
76247
76248
76249
76250
76251
76252
76253
76254
76255
76256
76257
76258
76259
76260
76261
76262
76263
76264
76265
76266
76267
76268
76269
76270
76271
76272
76273
76274
76275
76276
76277
76278
76279
76280
76281
76282
76283
76284
76285
76286
76287
76288
76289
76290
76291
76292
76293
76294
76295
76296
76297
76298
76299
76300
76301
76302
76303
76304
76305
76306
76307
76308
76309
76310
76311
76312
76313
76314
76315
76316
76317
76318
76319
76320
76321
76322
76323
76324
76325
76326
76327
76328
76329
76330
76331
76332
76333
76334
76335
76336
76337
76338
76339
76340
76341
76342
76343
76344
76345
76346
76347
76348
76349
76350
76351
76352
76353
76354
76355
76356
76357
76358
76359
76360
76361
76362
76363
76364
76365
76366
76367
76368
76369
76370
76371
76372
76373
76374
76375
76376
76377
76378
76379
76380
76381
76382
76383
76384
76385
76386
76387
76388
76389
76390
76391
76392
76393
76394
76395
76396
76397
76398
76399
76400
76401
76402
76403
76404
76405
76406
76407
76408
76409
76410
76411
76412
76413
76414
76415
76416
76417
76418
76419
76420
76421
76422
76423
76424
76425
76426
76427
76428
76429
76430
76431
76432
76433
76434
76435
76436
76437
76438
76439
76440
76441
76442
76443
76444
76445
76446
76447
76448
76449
76450
76451
76452
76453
76454
76455
76456
76457
76458
76459
76460
76461
76462
76463
76464
76465
76466
76467
76468
76469
76470
76471
76472
76473
76474
76475
76476
76477
76478
76479
76480
76481
76482
76483
76484
76485
76486
76487
76488
76489
76490
76491
76492
76493
76494
76495
76496
76497
76498
76499
76500
76501
76502
76503
76504
76505
76506
76507
76508
76509
76510
76511
76512
76513
76514
76515
76516
76517
76518
76519
76520
76521
76522
76523
76524
76525
76526
76527
76528
76529
76530
76531
76532
76533
76534
76535
76536
76537
76538
76539
76540
76541
76542
76543
76544
76545
76546
76547
76548
76549
76550
76551
76552
76553
76554
76555
76556
76557
76558
76559
76560
76561
76562
76563
76564
76565
76566
76567
76568
76569
76570
76571
76572
76573
76574
76575
76576
76577
76578
76579
76580
76581
76582
76583
76584
76585
76586
76587
76588
76589
76590
76591
76592
76593
76594
76595
76596
76597
76598
76599
76600
76601
76602
76603
76604
76605
76606
76607
76608
76609
76610
76611
76612
76613
76614
76615
76616
76617
76618
76619
76620
76621
76622
76623
76624
76625
76626
76627
76628
76629
76630
76631
76632
76633
76634
76635
76636
76637
76638
76639
76640
76641
76642
76643
76644
76645
76646
76647
76648
76649
76650
76651
76652
76653
76654
76655
76656
76657
76658
76659
76660
76661
76662
76663
76664
76665
76666
76667
76668
76669
76670
76671
76672
76673
76674
76675
76676
76677
76678
76679
76680
76681
76682
76683
76684
76685
76686
76687
76688
76689
76690
76691
76692
76693
76694
76695
76696
76697
76698
76699
76700
76701
76702
76703
76704
76705
76706
76707
76708
76709
76710
76711
76712
76713
76714
76715
76716
76717
76718
76719
76720
76721
76722
76723
76724
76725
76726
76727
76728
76729
76730
76731
76732
76733
76734
76735
76736
76737
76738
76739
76740
76741
76742
76743
76744
76745
76746
76747
76748
76749
76750
76751
76752
76753
76754
76755
76756
76757
76758
76759
76760
76761
76762
76763
76764
76765
76766
76767
76768
76769
76770
76771
76772
76773
76774
76775
76776
76777
76778
76779
76780
76781
76782
76783
76784
76785
76786
76787
76788
76789
76790
76791
76792
76793
76794
76795
76796
76797
76798
76799
76800
76801
76802
76803
76804
76805
76806
76807
76808
76809
76810
76811
76812
76813
76814
76815
76816
76817
76818
76819
76820
76821
76822
76823
76824
76825
76826
76827
76828
76829
76830
76831
76832
76833
76834
76835
76836
76837
76838
76839
76840
76841
76842
76843
76844
76845
76846
76847
76848
76849
76850
76851
76852
76853
76854
76855
76856
76857
76858
76859
76860
76861
76862
76863
76864
76865
76866
76867
76868
76869
76870
76871
76872
76873
76874
76875
76876
76877
76878
76879
76880
76881
76882
76883
76884
76885
76886
76887
76888
76889
76890
76891
76892
76893
76894
76895
76896
76897
76898
76899
76900
76901
76902
76903
76904
76905
76906
76907
76908
76909
76910
76911
76912
76913
76914
76915
76916
76917
76918
76919
76920
76921
76922
76923
76924
76925
76926
76927
76928
76929
76930
76931
76932
76933
76934
76935
76936
76937
76938
76939
76940
76941
76942
76943
76944
76945
76946
76947
76948
76949
76950
76951
76952
76953
76954
76955
76956
76957
76958
76959
76960
76961
76962
76963
76964
76965
76966
76967
76968
76969
76970
76971
76972
76973
76974
76975
76976
76977
76978
76979
76980
76981
76982
76983
76984
76985
76986
76987
76988
76989
76990
76991
76992
76993
76994
76995
76996
76997
76998
76999
77000
77001
77002
77003
77004
77005
77006
77007
77008
77009
77010
77011
77012
77013
77014
77015
77016
77017
77018
77019
77020
77021
77022
77023
77024
77025
77026
77027
77028
77029
77030
77031
77032
77033
77034
77035
77036
77037
77038
77039
77040
77041
77042
77043
77044
77045
77046
77047
77048
77049
77050
77051
77052
77053
77054
77055
77056
77057
77058
77059
77060
77061
77062
77063
77064
77065
77066
77067
77068
77069
77070
77071
77072
77073
77074
77075
77076
77077
77078
77079
77080
77081
77082
77083
77084
77085
77086
77087
77088
77089
77090
77091
77092
77093
77094
77095
77096
77097
77098
77099
77100
77101
77102
77103
77104
77105
77106
77107
77108
77109
77110
77111
77112
77113
77114
77115
77116
77117
77118
77119
77120
77121
77122
77123
77124
77125
77126
77127
77128
77129
77130
77131
77132
77133
77134
77135
77136
77137
77138
77139
77140
77141
77142
77143
77144
77145
77146
77147
77148
77149
77150
77151
77152
77153
77154
77155
77156
77157
77158
77159
77160
77161
77162
77163
77164
77165
77166
77167
77168
77169
77170
77171
77172
77173
77174
77175
77176
77177
77178
77179
77180
77181
77182
77183
77184
77185
77186
77187
77188
77189
77190
77191
77192
77193
77194
77195
77196
77197
77198
77199
77200
77201
77202
77203
77204
77205
77206
77207
77208
77209
77210
77211
77212
77213
77214
77215
77216
77217
77218
77219
77220
77221
77222
77223
77224
77225
77226
77227
77228
77229
77230
77231
77232
77233
77234
77235
77236
77237
77238
77239
77240
77241
77242
77243
77244
77245
77246
77247
77248
77249
77250
77251
77252
77253
77254
77255
77256
77257
77258
77259
77260
77261
77262
77263
77264
77265
77266
77267
77268
77269
77270
77271
77272
77273
77274
77275
77276
77277
77278
77279
77280
77281
77282
77283
77284
77285
77286
77287
77288
77289
77290
77291
77292
77293
77294
77295
77296
77297
77298
77299
77300
77301
77302
77303
77304
77305
77306
77307
77308
77309
77310
77311
77312
77313
77314
77315
77316
77317
77318
77319
77320
77321
77322
77323
77324
77325
77326
77327
77328
77329
77330
77331
77332
77333
77334
77335
77336
77337
77338
77339
77340
77341
77342
77343
77344
77345
77346
77347
77348
77349
77350
77351
77352
77353
77354
77355
77356
77357
77358
77359
77360
77361
77362
77363
77364
77365
77366
77367
77368
77369
77370
77371
77372
77373
77374
77375
77376
77377
77378
77379
77380
77381
77382
77383
77384
77385
77386
77387
77388
77389
77390
77391
77392
77393
77394
77395
77396
77397
77398
77399
77400
77401
77402
77403
77404
77405
77406
77407
77408
77409
77410
77411
77412
77413
77414
77415
77416
77417
77418
77419
77420
77421
77422
77423
77424
77425
77426
77427
77428
77429
77430
77431
77432
77433
77434
77435
77436
77437
77438
77439
77440
77441
77442
77443
77444
77445
77446
77447
77448
77449
77450
77451
77452
77453
77454
77455
77456
77457
77458
77459
77460
77461
77462
77463
77464
77465
77466
77467
77468
77469
77470
77471
77472
77473
77474
77475
77476
77477
77478
77479
77480
77481
77482
77483
77484
77485
77486
77487
77488
77489
77490
77491
77492
77493
77494
77495
77496
77497
77498
77499
77500
77501
77502
77503
77504
77505
77506
77507
77508
77509
77510
77511
77512
77513
77514
77515
77516
77517
77518
77519
77520
77521
77522
77523
77524
77525
77526
77527
77528
77529
77530
77531
77532
77533
77534
77535
77536
77537
77538
77539
77540
77541
77542
77543
77544
77545
77546
77547
77548
77549
77550
77551
77552
77553
77554
77555
77556
77557
77558
77559
77560
77561
77562
77563
77564
77565
77566
77567
77568
77569
77570
77571
77572
77573
77574
77575
77576
77577
77578
77579
77580
77581
77582
77583
77584
77585
77586
77587
77588
77589
77590
77591
77592
77593
77594
77595
77596
77597
77598
77599
77600
77601
77602
77603
77604
77605
77606
77607
77608
77609
77610
77611
77612
77613
77614
77615
77616
77617
77618
77619
77620
77621
77622
77623
77624
77625
77626
77627
77628
77629
77630
77631
77632
77633
77634
77635
77636
77637
77638
77639
77640
77641
77642
77643
77644
77645
77646
77647
77648
77649
77650
77651
77652
77653
77654
77655
77656
77657
77658
77659
77660
77661
77662
77663
77664
77665
77666
77667
77668
77669
77670
77671
77672
77673
77674
77675
77676
77677
77678
77679
77680
77681
77682
77683
77684
77685
77686
77687
77688
77689
77690
77691
77692
77693
77694
77695
77696
77697
77698
77699
77700
77701
77702
77703
77704
77705
77706
77707
77708
77709
77710
77711
77712
77713
77714
77715
77716
77717
77718
77719
77720
77721
77722
77723
77724
77725
77726
77727
77728
77729
77730
77731
77732
77733
77734
77735
77736
77737
77738
77739
77740
77741
77742
77743
77744
77745
77746
77747
77748
77749
77750
77751
77752
77753
77754
77755
77756
77757
77758
77759
77760
77761
77762
77763
77764
77765
77766
77767
77768
77769
77770
77771
77772
77773
77774
77775
77776
77777
77778
77779
77780
77781
77782
77783
77784
77785
77786
77787
77788
77789
77790
77791
77792
77793
77794
77795
77796
77797
77798
77799
77800
77801
77802
77803
77804
77805
77806
77807
77808
77809
77810
77811
77812
77813
77814
77815
77816
77817
77818
77819
77820
77821
77822
77823
77824
77825
77826
77827
77828
77829
77830
77831
77832
77833
77834
77835
77836
77837
77838
77839
77840
77841
77842
77843
77844
77845
77846
77847
77848
77849
77850
77851
77852
77853
77854
77855
77856
77857
77858
77859
77860
77861
77862
77863
77864
77865
77866
77867
77868
77869
77870
77871
77872
77873
77874
77875
77876
77877
77878
77879
77880
77881
77882
77883
77884
77885
77886
77887
77888
77889
77890
77891
77892
77893
77894
77895
77896
77897
77898
77899
77900
77901
77902
77903
77904
77905
77906
77907
77908
77909
77910
77911
77912
77913
77914
77915
77916
77917
77918
77919
77920
77921
77922
77923
77924
77925
77926
77927
77928
77929
77930
77931
77932
77933
77934
77935
77936
77937
77938
77939
77940
77941
77942
77943
77944
77945
77946
77947
77948
77949
77950
77951
77952
77953
77954
77955
77956
77957
77958
77959
77960
77961
77962
77963
77964
77965
77966
77967
77968
77969
77970
77971
77972
77973
77974
77975
77976
77977
77978
77979
77980
77981
77982
77983
77984
77985
77986
77987
77988
77989
77990
77991
77992
77993
77994
77995
77996
77997
77998
77999
78000
78001
78002
78003
78004
78005
78006
78007
78008
78009
78010
78011
78012
78013
78014
78015
78016
78017
78018
78019
78020
78021
78022
78023
78024
78025
78026
78027
78028
78029
78030
78031
78032
78033
78034
78035
78036
78037
78038
78039
78040
78041
78042
78043
78044
78045
78046
78047
78048
78049
78050
78051
78052
78053
78054
78055
78056
78057
78058
78059
78060
78061
78062
78063
78064
78065
78066
78067
78068
78069
78070
78071
78072
78073
78074
78075
78076
78077
78078
78079
78080
78081
78082
78083
78084
78085
78086
78087
78088
78089
78090
78091
78092
78093
78094
78095
78096
78097
78098
78099
78100
78101
78102
78103
78104
78105
78106
78107
78108
78109
78110
78111
78112
78113
78114
78115
78116
78117
78118
78119
78120
78121
78122
78123
78124
78125
78126
78127
78128
78129
78130
78131
78132
78133
78134
78135
78136
78137
78138
78139
78140
78141
78142
78143
78144
78145
78146
78147
78148
78149
78150
78151
78152
78153
78154
78155
78156
78157
78158
78159
78160
78161
78162
78163
78164
78165
78166
78167
78168
78169
78170
78171
78172
78173
78174
78175
78176
78177
78178
78179
78180
78181
78182
78183
78184
78185
78186
78187
78188
78189
78190
78191
78192
78193
78194
78195
78196
78197
78198
78199
78200
78201
78202
78203
78204
78205
78206
78207
78208
78209
78210
78211
78212
78213
78214
78215
78216
78217
78218
78219
78220
78221
78222
78223
78224
78225
78226
78227
78228
78229
78230
78231
78232
78233
78234
78235
78236
78237
78238
78239
78240
78241
78242
78243
78244
78245
78246
78247
78248
78249
78250
78251
78252
78253
78254
78255
78256
78257
78258
78259
78260
78261
78262
78263
78264
78265
78266
78267
78268
78269
78270
78271
78272
78273
78274
78275
78276
78277
78278
78279
78280
78281
78282
78283
78284
78285
78286
78287
78288
78289
78290
78291
78292
78293
78294
78295
78296
78297
78298
78299
78300
78301
78302
78303
78304
78305
78306
78307
78308
78309
78310
78311
78312
78313
78314
78315
78316
78317
78318
78319
78320
78321
78322
78323
78324
78325
78326
78327
78328
78329
78330
78331
78332
78333
78334
78335
78336
78337
78338
78339
78340
78341
78342
78343
78344
78345
78346
78347
78348
78349
78350
78351
78352
78353
78354
78355
78356
78357
78358
78359
78360
78361
78362
78363
78364
78365
78366
78367
78368
78369
78370
78371
78372
78373
78374
78375
78376
78377
78378
78379
78380
78381
78382
78383
78384
78385
78386
78387
78388
78389
78390
78391
78392
78393
78394
78395
78396
78397
78398
78399
78400
78401
78402
78403
78404
78405
78406
78407
78408
78409
78410
78411
78412
78413
78414
78415
78416
78417
78418
78419
78420
78421
78422
78423
78424
78425
78426
78427
78428
78429
78430
78431
78432
78433
78434
78435
78436
78437
78438
78439
78440
78441
78442
78443
78444
78445
78446
78447
78448
78449
78450
78451
78452
78453
78454
78455
78456
78457
78458
78459
78460
78461
78462
78463
78464
78465
78466
78467
78468
78469
78470
78471
78472
78473
78474
78475
78476
78477
78478
78479
78480
78481
78482
78483
78484
78485
78486
78487
78488
78489
78490
78491
78492
78493
78494
78495
78496
78497
78498
78499
78500
78501
78502
78503
78504
78505
78506
78507
78508
78509
78510
78511
78512
78513
78514
78515
78516
78517
78518
78519
78520
78521
78522
78523
78524
78525
78526
78527
78528
78529
78530
78531
78532
78533
78534
78535
78536
78537
78538
78539
78540
78541
78542
78543
78544
78545
78546
78547
78548
78549
78550
78551
78552
78553
78554
78555
78556
78557
78558
78559
78560
78561
78562
78563
78564
78565
78566
78567
78568
78569
78570
78571
78572
78573
78574
78575
78576
78577
78578
78579
78580
78581
78582
78583
78584
78585
78586
78587
78588
78589
78590
78591
78592
78593
78594
78595
78596
78597
78598
78599
78600
78601
78602
78603
78604
78605
78606
78607
78608
78609
78610
78611
78612
78613
78614
78615
78616
78617
78618
78619
78620
78621
78622
78623
78624
78625
78626
78627
78628
78629
78630
78631
78632
78633
78634
78635
78636
78637
78638
78639
78640
78641
78642
78643
78644
78645
78646
78647
78648
78649
78650
78651
78652
78653
78654
78655
78656
78657
78658
78659
78660
78661
78662
78663
78664
78665
78666
78667
78668
78669
78670
78671
78672
78673
78674
78675
78676
78677
78678
78679
78680
78681
78682
78683
78684
78685
78686
78687
78688
78689
78690
78691
78692
78693
78694
78695
78696
78697
78698
78699
78700
78701
78702
78703
78704
78705
78706
78707
78708
78709
78710
78711
78712
78713
78714
78715
78716
78717
78718
78719
78720
78721
78722
78723
78724
78725
78726
78727
78728
78729
78730
78731
78732
78733
78734
78735
78736
78737
78738
78739
78740
78741
78742
78743
78744
78745
78746
78747
78748
78749
78750
78751
78752
78753
78754
78755
78756
78757
78758
78759
78760
78761
78762
78763
78764
78765
78766
78767
78768
78769
78770
78771
78772
78773
78774
78775
78776
78777
78778
78779
78780
78781
78782
78783
78784
78785
78786
78787
78788
78789
78790
78791
78792
78793
78794
78795
78796
78797
78798
78799
78800
78801
78802
78803
78804
78805
78806
78807
78808
78809
78810
78811
78812
78813
78814
78815
78816
78817
78818
78819
78820
78821
78822
78823
78824
78825
78826
78827
78828
78829
78830
78831
78832
78833
78834
78835
78836
78837
78838
78839
78840
78841
78842
78843
78844
78845
78846
78847
78848
78849
78850
78851
78852
78853
78854
78855
78856
78857
78858
78859
78860
78861
78862
78863
78864
78865
78866
78867
78868
78869
78870
78871
78872
78873
78874
78875
78876
78877
78878
78879
78880
78881
78882
78883
78884
78885
78886
78887
78888
78889
78890
78891
78892
78893
78894
78895
78896
78897
78898
78899
78900
78901
78902
78903
78904
78905
78906
78907
78908
78909
78910
78911
78912
78913
78914
78915
78916
78917
78918
78919
78920
78921
78922
78923
78924
78925
78926
78927
78928
78929
78930
78931
78932
78933
78934
78935
78936
78937
78938
78939
78940
78941
78942
78943
78944
78945
78946
78947
78948
78949
78950
78951
78952
78953
78954
78955
78956
78957
78958
78959
78960
78961
78962
78963
78964
78965
78966
78967
78968
78969
78970
78971
78972
78973
78974
78975
78976
78977
78978
78979
78980
78981
78982
78983
78984
78985
78986
78987
78988
78989
78990
78991
78992
78993
78994
78995
78996
78997
78998
78999
79000
79001
79002
79003
79004
79005
79006
79007
79008
79009
79010
79011
79012
79013
79014
79015
79016
79017
79018
79019
79020
79021
79022
79023
79024
79025
79026
79027
79028
79029
79030
79031
79032
79033
79034
79035
79036
79037
79038
79039
79040
79041
79042
79043
79044
79045
79046
79047
79048
79049
79050
79051
79052
79053
79054
79055
79056
79057
79058
79059
79060
79061
79062
79063
79064
79065
79066
79067
79068
79069
79070
79071
79072
79073
79074
79075
79076
79077
79078
79079
79080
79081
79082
79083
79084
79085
79086
79087
79088
79089
79090
79091
79092
79093
79094
79095
79096
79097
79098
79099
79100
79101
79102
79103
79104
79105
79106
79107
79108
79109
79110
79111
79112
79113
79114
79115
79116
79117
79118
79119
79120
79121
79122
79123
79124
79125
79126
79127
79128
79129
79130
79131
79132
79133
79134
79135
79136
79137
79138
79139
79140
79141
79142
79143
79144
79145
79146
79147
79148
79149
79150
79151
79152
79153
79154
79155
79156
79157
79158
79159
79160
79161
79162
79163
79164
79165
79166
79167
79168
79169
79170
79171
79172
79173
79174
79175
79176
79177
79178
79179
79180
79181
79182
79183
79184
79185
79186
79187
79188
79189
79190
79191
79192
79193
79194
79195
79196
79197
79198
79199
79200
79201
79202
79203
79204
79205
79206
79207
79208
79209
79210
79211
79212
79213
79214
79215
79216
79217
79218
79219
79220
79221
79222
79223
79224
79225
79226
79227
79228
79229
79230
79231
79232
79233
79234
79235
79236
79237
79238
79239
79240
79241
79242
79243
79244
79245
79246
79247
79248
79249
79250
79251
79252
79253
79254
79255
79256
79257
79258
79259
79260
79261
79262
79263
79264
79265
79266
79267
79268
79269
79270
79271
79272
79273
79274
79275
79276
79277
79278
79279
79280
79281
79282
79283
79284
79285
79286
79287
79288
79289
79290
79291
79292
79293
79294
79295
79296
79297
79298
79299
79300
79301
79302
79303
79304
79305
79306
79307
79308
79309
79310
79311
79312
79313
79314
79315
79316
79317
79318
79319
79320
79321
79322
79323
79324
79325
79326
79327
79328
79329
79330
79331
79332
79333
79334
79335
79336
79337
79338
79339
79340
79341
79342
79343
79344
79345
79346
79347
79348
79349
79350
79351
79352
79353
79354
79355
79356
79357
79358
79359
79360
79361
79362
79363
79364
79365
79366
79367
79368
79369
79370
79371
79372
79373
79374
79375
79376
79377
79378
79379
79380
79381
79382
79383
79384
79385
79386
79387
79388
79389
79390
79391
79392
79393
79394
79395
79396
79397
79398
79399
79400
79401
79402
79403
79404
79405
79406
79407
79408
79409
79410
79411
79412
79413
79414
79415
79416
79417
79418
79419
79420
79421
79422
79423
79424
79425
79426
79427
79428
79429
79430
79431
79432
79433
79434
79435
79436
79437
79438
79439
79440
79441
79442
79443
79444
79445
79446
79447
79448
79449
79450
79451
79452
79453
79454
79455
79456
79457
79458
79459
79460
79461
79462
79463
79464
79465
79466
79467
79468
79469
79470
79471
79472
79473
79474
79475
79476
79477
79478
79479
79480
79481
79482
79483
79484
79485
79486
79487
79488
79489
79490
79491
79492
79493
79494
79495
79496
79497
79498
79499
79500
79501
79502
79503
79504
79505
79506
79507
79508
79509
79510
79511
79512
79513
79514
79515
79516
79517
79518
79519
79520
79521
79522
79523
79524
79525
79526
79527
79528
79529
79530
79531
79532
79533
79534
79535
79536
79537
79538
79539
79540
79541
79542
79543
79544
79545
79546
79547
79548
79549
79550
79551
79552
79553
79554
79555
79556
79557
79558
79559
79560
79561
79562
79563
79564
79565
79566
79567
79568
79569
79570
79571
79572
79573
79574
79575
79576
79577
79578
79579
79580
79581
79582
79583
79584
79585
79586
79587
79588
79589
79590
79591
79592
79593
79594
79595
79596
79597
79598
79599
79600
79601
79602
79603
79604
79605
79606
79607
79608
79609
79610
79611
79612
79613
79614
79615
79616
79617
79618
79619
79620
79621
79622
79623
79624
79625
79626
79627
79628
79629
79630
79631
79632
79633
79634
79635
79636
79637
79638
79639
79640
79641
79642
79643
79644
79645
79646
79647
79648
79649
79650
79651
79652
79653
79654
79655
79656
79657
79658
79659
79660
79661
79662
79663
79664
79665
79666
79667
79668
79669
79670
79671
79672
79673
79674
79675
79676
79677
79678
79679
79680
79681
79682
79683
79684
79685
79686
79687
79688
79689
79690
79691
79692
79693
79694
79695
79696
79697
79698
79699
79700
79701
79702
79703
79704
79705
79706
79707
79708
79709
79710
79711
79712
79713
79714
79715
79716
79717
79718
79719
79720
79721
79722
79723
79724
79725
79726
79727
79728
79729
79730
79731
79732
79733
79734
79735
79736
79737
79738
79739
79740
79741
79742
79743
79744
79745
79746
79747
79748
79749
79750
79751
79752
79753
79754
79755
79756
79757
79758
79759
79760
79761
79762
79763
79764
79765
79766
79767
79768
79769
79770
79771
79772
79773
79774
79775
79776
79777
79778
79779
79780
79781
79782
79783
79784
79785
79786
79787
79788
79789
79790
79791
79792
79793
79794
79795
79796
79797
79798
79799
79800
79801
79802
79803
79804
79805
79806
79807
79808
79809
79810
79811
79812
79813
79814
79815
79816
79817
79818
79819
79820
79821
79822
79823
79824
79825
79826
79827
79828
79829
79830
79831
79832
79833
79834
79835
79836
79837
79838
79839
79840
79841
79842
79843
79844
79845
79846
79847
79848
79849
79850
79851
79852
79853
79854
79855
79856
79857
79858
79859
79860
79861
79862
79863
79864
79865
79866
79867
79868
79869
79870
79871
79872
79873
79874
79875
79876
79877
79878
79879
79880
79881
79882
79883
79884
79885
79886
79887
79888
79889
79890
79891
79892
79893
79894
79895
79896
79897
79898
79899
79900
79901
79902
79903
79904
79905
79906
79907
79908
79909
79910
79911
79912
79913
79914
79915
79916
79917
79918
79919
79920
79921
79922
79923
79924
79925
79926
79927
79928
79929
79930
79931
79932
79933
79934
79935
79936
79937
79938
79939
79940
79941
79942
79943
79944
79945
79946
79947
79948
79949
79950
79951
79952
79953
79954
79955
79956
79957
79958
79959
79960
79961
79962
79963
79964
79965
79966
79967
79968
79969
79970
79971
79972
79973
79974
79975
79976
79977
79978
79979
79980
79981
79982
79983
79984
79985
79986
79987
79988
79989
79990
79991
79992
79993
79994
79995
79996
79997
79998
79999
80000
80001
80002
80003
80004
80005
80006
80007
80008
80009
80010
80011
80012
80013
80014
80015
80016
80017
80018
80019
80020
80021
80022
80023
80024
80025
80026
80027
80028
80029
80030
80031
80032
80033
80034
80035
80036
80037
80038
80039
80040
80041
80042
80043
80044
80045
80046
80047
80048
80049
80050
80051
80052
80053
80054
80055
80056
80057
80058
80059
80060
80061
80062
80063
80064
80065
80066
80067
80068
80069
80070
80071
80072
80073
80074
80075
80076
80077
80078
80079
80080
80081
80082
80083
80084
80085
80086
80087
80088
80089
80090
80091
80092
80093
80094
80095
80096
80097
80098
80099
80100
80101
80102
80103
80104
80105
80106
80107
80108
80109
80110
80111
80112
80113
80114
80115
80116
80117
80118
80119
80120
80121
80122
80123
80124
80125
80126
80127
80128
80129
80130
80131
80132
80133
80134
80135
80136
80137
80138
80139
80140
80141
80142
80143
80144
80145
80146
80147
80148
80149
80150
80151
80152
80153
80154
80155
80156
80157
80158
80159
80160
80161
80162
80163
80164
80165
80166
80167
80168
80169
80170
80171
80172
80173
80174
80175
80176
80177
80178
80179
80180
80181
80182
80183
80184
80185
80186
80187
80188
80189
80190
80191
80192
80193
80194
80195
80196
80197
80198
80199
80200
80201
80202
80203
80204
80205
80206
80207
80208
80209
80210
80211
80212
80213
80214
80215
80216
80217
80218
80219
80220
80221
80222
80223
80224
80225
80226
80227
80228
80229
80230
80231
80232
80233
80234
80235
80236
80237
80238
80239
80240
80241
80242
80243
80244
80245
80246
80247
80248
80249
80250
80251
80252
80253
80254
80255
80256
80257
80258
80259
80260
80261
80262
80263
80264
80265
80266
80267
80268
80269
80270
80271
80272
80273
80274
80275
80276
80277
80278
80279
80280
80281
80282
80283
80284
80285
80286
80287
80288
80289
80290
80291
80292
80293
80294
80295
80296
80297
80298
80299
80300
80301
80302
80303
80304
80305
80306
80307
80308
80309
80310
80311
80312
80313
80314
80315
80316
80317
80318
80319
80320
80321
80322
80323
80324
80325
80326
80327
80328
80329
80330
80331
80332
80333
80334
80335
80336
80337
80338
80339
80340
80341
80342
80343
80344
80345
80346
80347
80348
80349
80350
80351
80352
80353
80354
80355
80356
80357
80358
80359
80360
80361
80362
80363
80364
80365
80366
80367
80368
80369
80370
80371
80372
80373
80374
80375
80376
80377
80378
80379
80380
80381
80382
80383
80384
80385
80386
80387
80388
80389
80390
80391
80392
80393
80394
80395
80396
80397
80398
80399
80400
80401
80402
80403
80404
80405
80406
80407
80408
80409
80410
80411
80412
80413
80414
80415
80416
80417
80418
80419
80420
80421
80422
80423
80424
80425
80426
80427
80428
80429
80430
80431
80432
80433
80434
80435
80436
80437
80438
80439
80440
80441
80442
80443
80444
80445
80446
80447
80448
80449
80450
80451
80452
80453
80454
80455
80456
80457
80458
80459
80460
80461
80462
80463
80464
80465
80466
80467
80468
80469
80470
80471
80472
80473
80474
80475
80476
80477
80478
80479
80480
80481
80482
80483
80484
80485
80486
80487
80488
80489
80490
80491
80492
80493
80494
80495
80496
80497
80498
80499
80500
80501
80502
80503
80504
80505
80506
80507
80508
80509
80510
80511
80512
80513
80514
80515
80516
80517
80518
80519
80520
80521
80522
80523
80524
80525
80526
80527
80528
80529
80530
80531
80532
80533
80534
80535
80536
80537
80538
80539
80540
80541
80542
80543
80544
80545
80546
80547
80548
80549
80550
80551
80552
80553
80554
80555
80556
80557
80558
80559
80560
80561
80562
80563
80564
80565
80566
80567
80568
80569
80570
80571
80572
80573
80574
80575
80576
80577
80578
80579
80580
80581
80582
80583
80584
80585
80586
80587
80588
80589
80590
80591
80592
80593
80594
80595
80596
80597
80598
80599
80600
80601
80602
80603
80604
80605
80606
80607
80608
80609
80610
80611
80612
80613
80614
80615
80616
80617
80618
80619
80620
80621
80622
80623
80624
80625
80626
80627
80628
80629
80630
80631
80632
80633
80634
80635
80636
80637
80638
80639
80640
80641
80642
80643
80644
80645
80646
80647
80648
80649
80650
80651
80652
80653
80654
80655
80656
80657
80658
80659
80660
80661
80662
80663
80664
80665
80666
80667
80668
80669
80670
80671
80672
80673
80674
80675
80676
80677
80678
80679
80680
80681
80682
80683
80684
80685
80686
80687
80688
80689
80690
80691
80692
80693
80694
80695
80696
80697
80698
80699
80700
80701
80702
80703
80704
80705
80706
80707
80708
80709
80710
80711
80712
80713
80714
80715
80716
80717
80718
80719
80720
80721
80722
80723
80724
80725
80726
80727
80728
80729
80730
80731
80732
80733
80734
80735
80736
80737
80738
80739
80740
80741
80742
80743
80744
80745
80746
80747
80748
80749
80750
80751
80752
80753
80754
80755
80756
80757
80758
80759
80760
80761
80762
80763
80764
80765
80766
80767
80768
80769
80770
80771
80772
80773
80774
80775
80776
80777
80778
80779
80780
80781
80782
80783
80784
80785
80786
80787
80788
80789
80790
80791
80792
80793
80794
80795
80796
80797
80798
80799
80800
80801
80802
80803
80804
80805
80806
80807
80808
80809
80810
80811
80812
80813
80814
80815
80816
80817
80818
80819
80820
80821
80822
80823
80824
80825
80826
80827
80828
80829
80830
80831
80832
80833
80834
80835
80836
80837
80838
80839
80840
80841
80842
80843
80844
80845
80846
80847
80848
80849
80850
80851
80852
80853
80854
80855
80856
80857
80858
80859
80860
80861
80862
80863
80864
80865
80866
80867
80868
80869
80870
80871
80872
80873
80874
80875
80876
80877
80878
80879
80880
80881
80882
80883
80884
80885
80886
80887
80888
80889
80890
80891
80892
80893
80894
80895
80896
80897
80898
80899
80900
80901
80902
80903
80904
80905
80906
80907
80908
80909
80910
80911
80912
80913
80914
80915
80916
80917
80918
80919
80920
80921
80922
80923
80924
80925
80926
80927
80928
80929
80930
80931
80932
80933
80934
80935
80936
80937
80938
80939
80940
80941
80942
80943
80944
80945
80946
80947
80948
80949
80950
80951
80952
80953
80954
80955
80956
80957
80958
80959
80960
80961
80962
80963
80964
80965
80966
80967
80968
80969
80970
80971
80972
80973
80974
80975
80976
80977
80978
80979
80980
80981
80982
80983
80984
80985
80986
80987
80988
80989
80990
80991
80992
80993
80994
80995
80996
80997
80998
80999
81000
81001
81002
81003
81004
81005
81006
81007
81008
81009
81010
81011
81012
81013
81014
81015
81016
81017
81018
81019
81020
81021
81022
81023
81024
81025
81026
81027
81028
81029
81030
81031
81032
81033
81034
81035
81036
81037
81038
81039
81040
81041
81042
81043
81044
81045
81046
81047
81048
81049
81050
81051
81052
81053
81054
81055
81056
81057
81058
81059
81060
81061
81062
81063
81064
81065
81066
81067
81068
81069
81070
81071
81072
81073
81074
81075
81076
81077
81078
81079
81080
81081
81082
81083
81084
81085
81086
81087
81088
81089
81090
81091
81092
81093
81094
81095
81096
81097
81098
81099
81100
81101
81102
81103
81104
81105
81106
81107
81108
81109
81110
81111
81112
81113
81114
81115
81116
81117
81118
81119
81120
81121
81122
81123
81124
81125
81126
81127
81128
81129
81130
81131
81132
81133
81134
81135
81136
81137
81138
81139
81140
81141
81142
81143
81144
81145
81146
81147
81148
81149
81150
81151
81152
81153
81154
81155
81156
81157
81158
81159
81160
81161
81162
81163
81164
81165
81166
81167
81168
81169
81170
81171
81172
81173
81174
81175
81176
81177
81178
81179
81180
81181
81182
81183
81184
81185
81186
81187
81188
81189
81190
81191
81192
81193
81194
81195
81196
81197
81198
81199
81200
81201
81202
81203
81204
81205
81206
81207
81208
81209
81210
81211
81212
81213
81214
81215
81216
81217
81218
81219
81220
81221
81222
81223
81224
81225
81226
81227
81228
81229
81230
81231
81232
81233
81234
81235
81236
81237
81238
81239
81240
81241
81242
81243
81244
81245
81246
81247
81248
81249
81250
81251
81252
81253
81254
81255
81256
81257
81258
81259
81260
81261
81262
81263
81264
81265
81266
81267
81268
81269
81270
81271
81272
81273
81274
81275
81276
81277
81278
81279
81280
81281
81282
81283
81284
81285
81286
81287
81288
81289
81290
81291
81292
81293
81294
81295
81296
81297
81298
81299
81300
81301
81302
81303
81304
81305
81306
81307
81308
81309
81310
81311
81312
81313
81314
81315
81316
81317
81318
81319
81320
81321
81322
81323
81324
81325
81326
81327
81328
81329
81330
81331
81332
81333
81334
81335
81336
81337
81338
81339
81340
81341
81342
81343
81344
81345
81346
81347
81348
81349
81350
81351
81352
81353
81354
81355
81356
81357
81358
81359
81360
81361
81362
81363
81364
81365
81366
81367
81368
81369
81370
81371
81372
81373
81374
81375
81376
81377
81378
81379
81380
81381
81382
81383
81384
81385
81386
81387
81388
81389
81390
81391
81392
81393
81394
81395
81396
81397
81398
81399
81400
81401
81402
81403
81404
81405
81406
81407
81408
81409
81410
81411
81412
81413
81414
81415
81416
81417
81418
81419
81420
81421
81422
81423
81424
81425
81426
81427
81428
81429
81430
81431
81432
81433
81434
81435
81436
81437
81438
81439
81440
81441
81442
81443
81444
81445
81446
81447
81448
81449
81450
81451
81452
81453
81454
81455
81456
81457
81458
81459
81460
81461
81462
81463
81464
81465
81466
81467
81468
81469
81470
81471
81472
81473
81474
81475
81476
81477
81478
81479
81480
81481
81482
81483
81484
81485
81486
81487
81488
81489
81490
81491
81492
81493
81494
81495
81496
81497
81498
81499
81500
81501
81502
81503
81504
81505
81506
81507
81508
81509
81510
81511
81512
81513
81514
81515
81516
81517
81518
81519
81520
81521
81522
81523
81524
81525
81526
81527
81528
81529
81530
81531
81532
81533
81534
81535
81536
81537
81538
81539
81540
81541
81542
81543
81544
81545
81546
81547
81548
81549
81550
81551
81552
81553
81554
81555
81556
81557
81558
81559
81560
81561
81562
81563
81564
81565
81566
81567
81568
81569
81570
81571
81572
81573
81574
81575
81576
81577
81578
81579
81580
81581
81582
81583
81584
81585
81586
81587
81588
81589
81590
81591
81592
81593
81594
81595
81596
81597
81598
81599
81600
81601
81602
81603
81604
81605
81606
81607
81608
81609
81610
81611
81612
81613
81614
81615
81616
81617
81618
81619
81620
81621
81622
81623
81624
81625
81626
81627
81628
81629
81630
81631
81632
81633
81634
81635
81636
81637
81638
81639
81640
81641
81642
81643
81644
81645
81646
81647
81648
81649
81650
81651
81652
81653
81654
81655
81656
81657
81658
81659
81660
81661
81662
81663
81664
81665
81666
81667
81668
81669
81670
81671
81672
81673
81674
81675
81676
81677
81678
81679
81680
81681
81682
81683
81684
81685
81686
81687
81688
81689
81690
81691
81692
81693
81694
81695
81696
81697
81698
81699
81700
81701
81702
81703
81704
81705
81706
81707
81708
81709
81710
81711
81712
81713
81714
81715
81716
81717
81718
81719
81720
81721
81722
81723
81724
81725
81726
81727
81728
81729
81730
81731
81732
81733
81734
81735
81736
81737
81738
81739
81740
81741
81742
81743
81744
81745
81746
81747
81748
81749
81750
81751
81752
81753
81754
81755
81756
81757
81758
81759
81760
81761
81762
81763
81764
81765
81766
81767
81768
81769
81770
81771
81772
81773
81774
81775
81776
81777
81778
81779
81780
81781
81782
81783
81784
81785
81786
81787
81788
81789
81790
81791
81792
81793
81794
81795
81796
81797
81798
81799
81800
81801
81802
81803
81804
81805
81806
81807
81808
81809
81810
81811
81812
81813
81814
81815
81816
81817
81818
81819
81820
81821
81822
81823
81824
81825
81826
81827
81828
81829
81830
81831
81832
81833
81834
81835
81836
81837
81838
81839
81840
81841
81842
81843
81844
81845
81846
81847
81848
81849
81850
81851
81852
81853
81854
81855
81856
81857
81858
81859
81860
81861
81862
81863
81864
81865
81866
81867
81868
81869
81870
81871
81872
81873
81874
81875
81876
81877
81878
81879
81880
81881
81882
81883
81884
81885
81886
81887
81888
81889
81890
81891
81892
81893
81894
81895
81896
81897
81898
81899
81900
81901
81902
81903
81904
81905
81906
81907
81908
81909
81910
81911
81912
81913
81914
81915
81916
81917
81918
81919
81920
81921
81922
81923
81924
81925
81926
81927
81928
81929
81930
81931
81932
81933
81934
81935
81936
81937
81938
81939
81940
81941
81942
81943
81944
81945
81946
81947
81948
81949
81950
81951
81952
81953
81954
81955
81956
81957
81958
81959
81960
81961
81962
81963
81964
81965
81966
81967
81968
81969
81970
81971
81972
81973
81974
81975
81976
81977
81978
81979
81980
81981
81982
81983
81984
81985
81986
81987
81988
81989
81990
81991
81992
81993
81994
81995
81996
81997
81998
81999
82000
82001
82002
82003
82004
82005
82006
82007
82008
82009
82010
82011
82012
82013
82014
82015
82016
82017
82018
82019
82020
82021
82022
82023
82024
82025
82026
82027
82028
82029
82030
82031
82032
82033
82034
82035
82036
82037
82038
82039
82040
82041
82042
82043
82044
82045
82046
82047
82048
82049
82050
82051
82052
82053
82054
82055
82056
82057
82058
82059
82060
82061
82062
82063
82064
82065
82066
82067
82068
82069
82070
82071
82072
82073
82074
82075
82076
82077
82078
82079
82080
82081
82082
82083
82084
82085
82086
82087
82088
82089
82090
82091
82092
82093
82094
82095
82096
82097
82098
82099
82100
82101
82102
82103
82104
82105
82106
82107
82108
82109
82110
82111
82112
82113
82114
82115
82116
82117
82118
82119
82120
82121
82122
82123
82124
82125
82126
82127
82128
82129
82130
82131
82132
82133
82134
82135
82136
82137
82138
82139
82140
82141
82142
82143
82144
82145
82146
82147
82148
82149
82150
82151
82152
82153
82154
82155
82156
82157
82158
82159
82160
82161
82162
82163
82164
82165
82166
82167
82168
82169
82170
82171
82172
82173
82174
82175
82176
82177
82178
82179
82180
82181
82182
82183
82184
82185
82186
82187
82188
82189
82190
82191
82192
82193
82194
82195
82196
82197
82198
82199
82200
82201
82202
82203
82204
82205
82206
82207
82208
82209
82210
82211
82212
82213
82214
82215
82216
82217
82218
82219
82220
82221
82222
82223
82224
82225
82226
82227
82228
82229
82230
82231
82232
82233
82234
82235
82236
82237
82238
82239
82240
82241
82242
82243
82244
82245
82246
82247
82248
82249
82250
82251
82252
82253
82254
82255
82256
82257
82258
82259
82260
82261
82262
82263
82264
82265
82266
82267
82268
82269
82270
82271
82272
82273
82274
82275
82276
82277
82278
82279
82280
82281
82282
82283
82284
82285
82286
82287
82288
82289
82290
82291
82292
82293
82294
82295
82296
82297
82298
82299
82300
82301
82302
82303
82304
82305
82306
82307
82308
82309
82310
82311
82312
82313
82314
82315
82316
82317
82318
82319
82320
82321
82322
82323
82324
82325
82326
82327
82328
82329
82330
82331
82332
82333
82334
82335
82336
82337
82338
82339
82340
82341
82342
82343
82344
82345
82346
82347
82348
82349
82350
82351
82352
82353
82354
82355
82356
82357
82358
82359
82360
82361
82362
82363
82364
82365
82366
82367
82368
82369
82370
82371
82372
82373
82374
82375
82376
82377
82378
82379
82380
82381
82382
82383
82384
82385
82386
82387
82388
82389
82390
82391
82392
82393
82394
82395
82396
82397
82398
82399
82400
82401
82402
82403
82404
82405
82406
82407
82408
82409
82410
82411
82412
82413
82414
82415
82416
82417
82418
82419
82420
82421
82422
82423
82424
82425
82426
82427
82428
82429
82430
82431
82432
82433
82434
82435
82436
82437
82438
82439
82440
82441
82442
82443
82444
82445
82446
82447
82448
82449
82450
82451
82452
82453
82454
82455
82456
82457
82458
82459
82460
82461
82462
82463
82464
82465
82466
82467
82468
82469
82470
82471
82472
82473
82474
82475
82476
82477
82478
82479
82480
82481
82482
82483
82484
82485
82486
82487
82488
82489
82490
82491
82492
82493
82494
82495
82496
82497
82498
82499
82500
82501
82502
82503
82504
82505
82506
82507
82508
82509
82510
82511
82512
82513
82514
82515
82516
82517
82518
82519
82520
82521
82522
82523
82524
82525
82526
82527
82528
82529
82530
82531
82532
82533
82534
82535
82536
82537
82538
82539
82540
82541
82542
82543
82544
82545
82546
82547
82548
82549
82550
82551
82552
82553
82554
82555
82556
82557
82558
82559
82560
82561
82562
82563
82564
82565
82566
82567
82568
82569
82570
82571
82572
82573
82574
82575
82576
82577
82578
82579
82580
82581
82582
82583
82584
82585
82586
82587
82588
82589
82590
82591
82592
82593
82594
82595
82596
82597
82598
82599
82600
82601
82602
82603
82604
82605
82606
82607
82608
82609
82610
82611
82612
82613
82614
82615
82616
82617
82618
82619
82620
82621
82622
82623
82624
82625
82626
82627
82628
82629
82630
82631
82632
82633
82634
82635
82636
82637
82638
82639
82640
82641
82642
82643
82644
82645
82646
82647
82648
82649
82650
82651
82652
82653
82654
82655
82656
82657
82658
82659
82660
82661
82662
82663
82664
82665
82666
82667
82668
82669
82670
82671
82672
82673
82674
82675
82676
82677
82678
82679
82680
82681
82682
82683
82684
82685
82686
82687
82688
82689
82690
82691
82692
82693
82694
82695
82696
82697
82698
82699
82700
82701
82702
82703
82704
82705
82706
82707
82708
82709
82710
82711
82712
82713
82714
82715
82716
82717
82718
82719
82720
82721
82722
82723
82724
82725
82726
82727
82728
82729
82730
82731
82732
82733
82734
82735
82736
82737
82738
82739
82740
82741
82742
82743
82744
82745
82746
82747
82748
82749
82750
82751
82752
82753
82754
82755
82756
82757
82758
82759
82760
82761
82762
82763
82764
82765
82766
82767
82768
82769
82770
82771
82772
82773
82774
82775
82776
82777
82778
82779
82780
82781
82782
82783
82784
82785
82786
82787
82788
82789
82790
82791
82792
82793
82794
82795
82796
82797
82798
82799
82800
82801
82802
82803
82804
82805
82806
82807
82808
82809
82810
82811
82812
82813
82814
82815
82816
82817
82818
82819
82820
82821
82822
82823
82824
82825
82826
82827
82828
82829
82830
82831
82832
82833
82834
82835
82836
82837
82838
82839
82840
82841
82842
82843
82844
82845
82846
82847
82848
82849
82850
82851
82852
82853
82854
82855
82856
82857
82858
82859
82860
82861
82862
82863
82864
82865
82866
82867
82868
82869
82870
82871
82872
82873
82874
82875
82876
82877
82878
82879
82880
82881
82882
82883
82884
82885
82886
82887
82888
82889
82890
82891
82892
82893
82894
82895
82896
82897
82898
82899
82900
82901
82902
82903
82904
82905
82906
82907
82908
82909
82910
82911
82912
82913
82914
82915
82916
82917
82918
82919
82920
82921
82922
82923
82924
82925
82926
82927
82928
82929
82930
82931
82932
82933
82934
82935
82936
82937
82938
82939
82940
82941
82942
82943
82944
82945
82946
82947
82948
82949
82950
82951
82952
82953
82954
82955
82956
82957
82958
82959
82960
82961
82962
82963
82964
82965
82966
82967
82968
82969
82970
82971
82972
82973
82974
82975
82976
82977
82978
82979
82980
82981
82982
82983
82984
82985
82986
82987
82988
82989
82990
82991
82992
82993
82994
82995
82996
82997
82998
82999
83000
83001
83002
83003
83004
83005
83006
83007
83008
83009
83010
83011
83012
83013
83014
83015
83016
83017
83018
83019
83020
83021
83022
83023
83024
83025
83026
83027
83028
83029
83030
83031
83032
83033
83034
83035
83036
83037
83038
83039
83040
83041
83042
83043
83044
83045
83046
83047
83048
83049
83050
83051
83052
83053
83054
83055
83056
83057
83058
83059
83060
83061
83062
83063
83064
83065
83066
83067
83068
83069
83070
83071
83072
83073
83074
83075
83076
83077
83078
83079
83080
83081
83082
83083
83084
83085
83086
83087
83088
83089
83090
83091
83092
83093
83094
83095
83096
83097
83098
83099
83100
83101
83102
83103
83104
83105
83106
83107
83108
83109
83110
83111
83112
83113
83114
83115
83116
83117
83118
83119
83120
83121
83122
83123
83124
83125
83126
83127
83128
83129
83130
83131
83132
83133
83134
83135
83136
83137
83138
83139
83140
83141
83142
83143
83144
83145
83146
83147
83148
83149
83150
83151
83152
83153
83154
83155
83156
83157
83158
83159
83160
83161
83162
83163
83164
83165
83166
83167
83168
83169
83170
83171
83172
83173
83174
83175
83176
83177
83178
83179
83180
83181
83182
83183
83184
83185
83186
83187
83188
83189
83190
83191
83192
83193
83194
83195
83196
83197
83198
83199
83200
83201
83202
83203
83204
83205
83206
83207
83208
83209
83210
83211
83212
83213
83214
83215
83216
83217
83218
83219
83220
83221
83222
83223
83224
83225
83226
83227
83228
83229
83230
83231
83232
83233
83234
83235
83236
83237
83238
83239
83240
83241
83242
83243
83244
83245
83246
83247
83248
83249
83250
83251
83252
83253
83254
83255
83256
83257
83258
83259
83260
83261
83262
83263
83264
83265
83266
83267
83268
83269
83270
83271
83272
83273
83274
83275
83276
83277
83278
83279
83280
83281
83282
83283
83284
83285
83286
83287
83288
83289
83290
83291
83292
83293
83294
83295
83296
83297
83298
83299
83300
83301
83302
83303
83304
83305
83306
83307
83308
83309
83310
83311
83312
83313
83314
83315
83316
83317
83318
83319
83320
83321
83322
83323
83324
83325
83326
83327
83328
83329
83330
83331
83332
83333
83334
83335
83336
83337
83338
83339
83340
83341
83342
83343
83344
83345
83346
83347
83348
83349
83350
83351
83352
83353
83354
83355
83356
83357
83358
83359
83360
83361
83362
83363
83364
83365
83366
83367
83368
83369
83370
83371
83372
83373
83374
83375
83376
83377
83378
83379
83380
83381
83382
83383
83384
83385
83386
83387
83388
83389
83390
83391
83392
83393
83394
83395
83396
83397
83398
83399
83400
83401
83402
83403
83404
83405
83406
83407
83408
83409
83410
83411
83412
83413
83414
83415
83416
83417
83418
83419
83420
83421
83422
83423
83424
83425
83426
83427
83428
83429
83430
83431
83432
83433
83434
83435
83436
83437
83438
83439
83440
83441
83442
83443
83444
83445
83446
83447
83448
83449
83450
83451
83452
83453
83454
83455
83456
83457
83458
83459
83460
83461
83462
83463
83464
83465
83466
83467
83468
83469
83470
83471
83472
83473
83474
83475
83476
83477
83478
83479
83480
83481
83482
83483
83484
83485
83486
83487
83488
83489
83490
83491
83492
83493
83494
83495
83496
83497
83498
83499
83500
83501
83502
83503
83504
83505
83506
83507
83508
83509
83510
83511
83512
83513
83514
83515
83516
83517
83518
83519
83520
83521
83522
83523
83524
83525
83526
83527
83528
83529
83530
83531
83532
83533
83534
83535
83536
83537
83538
83539
83540
83541
83542
83543
83544
83545
83546
83547
83548
83549
83550
83551
83552
83553
83554
83555
83556
83557
83558
83559
83560
83561
83562
83563
83564
83565
83566
83567
83568
83569
83570
83571
83572
83573
83574
83575
83576
83577
83578
83579
83580
83581
83582
83583
83584
83585
83586
83587
83588
83589
83590
83591
83592
83593
83594
83595
83596
83597
83598
83599
83600
83601
83602
83603
83604
83605
83606
83607
83608
83609
83610
83611
83612
83613
83614
83615
83616
83617
83618
83619
83620
83621
83622
83623
83624
83625
83626
83627
83628
83629
83630
83631
83632
83633
83634
83635
83636
83637
83638
83639
83640
83641
83642
83643
83644
83645
83646
83647
83648
83649
83650
83651
83652
83653
83654
83655
83656
83657
83658
83659
83660
83661
83662
83663
83664
83665
83666
83667
83668
83669
83670
83671
83672
83673
83674
83675
83676
83677
83678
83679
83680
83681
83682
83683
83684
83685
83686
83687
83688
83689
83690
83691
83692
83693
83694
83695
83696
83697
83698
83699
83700
83701
83702
83703
83704
83705
83706
83707
83708
83709
83710
83711
83712
83713
83714
83715
83716
83717
83718
83719
83720
83721
83722
83723
83724
83725
83726
83727
83728
83729
83730
83731
83732
83733
83734
83735
83736
83737
83738
83739
83740
83741
83742
83743
83744
83745
83746
83747
83748
83749
83750
83751
83752
83753
83754
83755
83756
83757
83758
83759
83760
83761
83762
83763
83764
83765
83766
83767
83768
83769
83770
83771
83772
83773
83774
83775
83776
83777
83778
83779
83780
83781
83782
83783
83784
83785
83786
83787
83788
83789
83790
83791
83792
83793
83794
83795
83796
83797

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!-- saved from url=(0060)http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html -->
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>C++ Standard Library Defect Report List</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
</style>
</head>
<body>
<table>
<tbody><tr>
  <td align="left">Doc. no.</td>
  <td align="left">D3182=10-0172</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2010-11-29</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</tbody></table>
<h1>C++ Standard Library Defect Report List (Revision D73)</h1>
<p>Revised 2010-11-29 at 10:11:56 UTC</p>

  <p>Reference ISO/IEC IS 14882:2003(E)</p>
  <p>Also see:</p>
    <ul>
      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
    </ul>
  <p>This document contains only library issues which have been closed
  by the Library Working Group (LWG) after being found to be defects
  in the standard.  That is, issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>,
  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the
  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects.  See the
  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information.  The
  introductory material in that document also applies to this
  document.</p>

<h2>Revision History</h2>
<ul>
<li>D73: Batavia meeting preview<ul>
<li><b>Summary:</b><ul>
<li>80 open issues, down by 126.</li>
<li>1459 closed issues, up by 145.</li>
<li>1539 issues total, up by 19.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 11 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1521">1521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1523">1523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2008">2008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2012">2012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2013">2013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2014">2014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2015">2015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2016">2016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2017">2017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2018">2018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2019">2019</a>.</li>
<li>Added the following 5 Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2001">2001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2003">2003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2005">2005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2010">2010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2011">2011</a>.</li>
<li>Added the following Resolved issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2002">2002</a>.</li>
<li>Added the following Review issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2009">2009</a>.</li>
<li>Added the following Tentatively NAD issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2006">2006</a>.</li>
<li>Added the following 3 Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2000">2000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2004">2004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2007">2007</a>.</li>
<li>Added the following WP issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1522">1522</a>.</li>
<li>Changed the following 3 issues from New to Deferred: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1214">1214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1330">1330</a>.</li>
<li>Changed the following issue from Open to Deferred: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1450">1450</a>.</li>
<li>Changed the following 14 issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1350">1350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1351">1351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1352">1352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1375">1375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1411">1411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1443">1443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1451">1451</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1454">1454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1458">1458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1463">1463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1470">1470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1475">1475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1476">1476</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1477">1477</a>.</li>
<li>Changed the following issue from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1331">1331</a>.</li>
<li>Changed the following 8 issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1359">1359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1361">1361</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1373">1373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1376">1376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1398">1398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1446">1446</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1473">1473</a>.</li>
<li>Changed the following 2 issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1200">1200</a>.</li>
<li>Changed the following issue from WP to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>.</li>
<li>Changed the following 11 issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1395">1395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1442">1442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1471">1471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1472">1472</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1489">1489</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1495">1495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1496">1496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1509">1509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1510">1510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1511">1511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1512">1512</a>.</li>
<li>Changed the following issue from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1281">1281</a>.</li>
<li>Changed the following issue from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1289">1289</a>.</li>
<li>Changed the following 6 issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1406">1406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1422">1422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1484">1484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1488">1488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1493">1493</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1499">1499</a>.</li>
<li>Changed the following 2 issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1188">1188</a>.</li>
<li>Changed the following 2 issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1252">1252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1297">1297</a>.</li>
<li>Changed the following 3 issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1279">1279</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1318">1318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1332">1332</a>.</li>
<li>Changed the following 6 issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1385">1385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1401">1401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1408">1408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1418">1418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1420">1420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1438">1438</a>.</li>
<li>Changed the following 42 issues from NAD Editorial to Resolved: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1260">1260</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1283">1283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1293">1293</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1307">1307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1321">1321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1394">1394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1405">1405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1407">1407</a>.</li>
<li>Changed the following 5 issues from New to Resolved: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1290">1290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1322">1322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1324">1324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1326">1326</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1328">1328</a>.</li>
<li>Changed the following 46 issues from Open to Resolved: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1268">1268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1327">1327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1344">1344</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1346">1346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1347">1347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1355">1355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1356">1356</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1357">1357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1365">1365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1366">1366</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1377">1377</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1378">1378</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1379">1379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1380">1380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1382">1382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1383">1383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1389">1389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1390">1390</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1391">1391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1392">1392</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1393">1393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1397">1397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1409">1409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1410">1410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1412">1412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1445">1445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1447">1447</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1453">1453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1455">1455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1462">1462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1464">1464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1465">1465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1466">1466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1467">1467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1468">1468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1469">1469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1481">1481</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1482">1482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1490">1490</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1491">1491</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1492">1492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1498">1498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1501">1501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1508">1508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1513">1513</a>.</li>
<li>Changed the following issue from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1480">1480</a>.</li>
<li>Changed the following 2 issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1371">1371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1413">1413</a>.</li>
<li>Changed the following issue from New to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1320">1320</a>.</li>
<li>Changed the following 3 issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1215">1215</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1253">1253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1310">1310</a>.</li>
<li>Changed the following issue from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1497">1497</a>.</li>
<li>Changed the following 24 issues from NAD Editorial to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1360">1360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1363">1363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1367">1367</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1372">1372</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1381">1381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1384">1384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1386">1386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1387">1387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1388">1388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1399">1399</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1400">1400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1402">1402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1403">1403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1416">1416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1417">1417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1423">1423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1424">1424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1425">1425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1426">1426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1427">1427</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1429">1429</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1430">1430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1431">1431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1441">1441</a>.</li>
<li>Changed the following issue from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1294">1294</a>.</li>
<li>Changed the following 10 issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1354">1354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1362">1362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1368">1368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1370">1370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1428">1428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1435">1435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1436">1436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1437">1437</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1439">1439</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1440">1440</a>.</li>
<li>Changed the following 2 issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.</li>
<li>Changed the following 33 issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1198">1198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1207">1207</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1292">1292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1295">1295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1316">1316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1319">1319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1323">1323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1325">1325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1333">1333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1334">1334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1335">1335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1337">1337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1338">1338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1339">1339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1340">1340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1404">1404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1414">1414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1432">1432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1449">1449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1516">1516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1517">1517</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1518">1518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1519">1519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1520">1520</a>.</li>
</ul></li>
</ul>
</li>
<li>R72: 
2010-10-18 pre-Batavia mailing.
<ul>
<li><b>Summary:</b><ul>
<li>206 open issues, up by 141.</li>
<li>1314 closed issues, up by 36.</li>
<li>1520 issues total, up by 177.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1433">1433</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1444">1444</a>.</li>
<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1360">1360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1363">1363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1367">1367</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1372">1372</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1381">1381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1384">1384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1386">1386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1387">1387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1388">1388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1394">1394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1399">1399</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1400">1400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1402">1402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1403">1403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1405">1405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1407">1407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1415">1415</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1416">1416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1417">1417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1419">1419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1423">1423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1424">1424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1425">1425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1426">1426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1427">1427</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1429">1429</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1430">1430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1431">1431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1434">1434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1441">1441</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1483">1483</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1500">1500</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1506">1506</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1344">1344</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1345">1345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1346">1346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1347">1347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1348">1348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1349">1349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1350">1350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1351">1351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1352">1352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1353">1353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1354">1354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1355">1355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1356">1356</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1357">1357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1358">1358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1359">1359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1361">1361</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1362">1362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1364">1364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1365">1365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1366">1366</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1368">1368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1369">1369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1370">1370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1371">1371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1373">1373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1374">1374</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1375">1375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1376">1376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1377">1377</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1378">1378</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1379">1379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1380">1380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1382">1382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1383">1383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1385">1385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1389">1389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1390">1390</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1391">1391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1392">1392</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1393">1393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1395">1395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1396">1396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1397">1397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1398">1398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1401">1401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1406">1406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1408">1408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1409">1409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1410">1410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1411">1411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1412">1412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1413">1413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1418">1418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1420">1420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1421">1421</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1422">1422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1428">1428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1435">1435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1436">1436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1437">1437</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1438">1438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1439">1439</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1440">1440</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1442">1442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1443">1443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1445">1445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1446">1446</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1447">1447</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1448">1448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1450">1450</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1451">1451</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1452">1452</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1453">1453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1454">1454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1455">1455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1456">1456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1457">1457</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1458">1458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1459">1459</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1460">1460</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1461">1461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1462">1462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1463">1463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1464">1464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1465">1465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1466">1466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1467">1467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1468">1468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1469">1469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1470">1470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1471">1471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1472">1472</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1473">1473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1474">1474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1475">1475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1476">1476</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1477">1477</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1478">1478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1479">1479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1480">1480</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1481">1481</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1482">1482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1484">1484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1485">1485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1486">1486</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1487">1487</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1488">1488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1489">1489</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1490">1490</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1491">1491</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1492">1492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1493">1493</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1494">1494</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1495">1495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1496">1496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1497">1497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1498">1498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1499">1499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1501">1501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1502">1502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1503">1503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1504">1504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1505">1505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1507">1507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1508">1508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1509">1509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1510">1510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1511">1511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1512">1512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1513">1513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1514">1514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1515">1515</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1404">1404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1414">1414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1432">1432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1449">1449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1516">1516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1517">1517</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1518">1518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1519">1519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1520">1520</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1260">1260</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1292">1292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1295">1295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1316">1316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1319">1319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1323">1323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1325">1325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1333">1333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1334">1334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1335">1335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1337">1337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1338">1338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1339">1339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1340">1340</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>.</li>
</ul></li>
</ul>
</li>
<li>R71: 
2010-08-25 post-Rapperswil mailing.
<ul>
<li><b>Summary:</b><ul>
<li>65 open issues, up by 2.</li>
<li>1278 closed issues, up by 7.</li>
<li>1343 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1335">1335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2008">2008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1337">1337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1338">1338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1339">1339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1340">1340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2009">2009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2010">2010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2011">2011</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1119">1119</a>.</li>
<li>Changed the following issues from Open to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1076">1076</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1169">1169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1175">1175</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1200">1200</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1188">1188</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1198">1198</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1207">1207</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1278">1278</a>.</li>
</ul></li>
</ul>
</li>
<li>R70: 
2010-03-26 post-Pittsburgh mailing.
<ul>
<li><b>Summary:</b><ul>
<li>63 open issues, down by 203.</li>
<li>1271 closed issues, up by 219.</li>
<li>1334 issues total, up by 16.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1321">1321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1329">1329</a>.</li>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1319">1319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1320">1320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1322">1322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1323">1323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1324">1324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1325">1325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1326">1326</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1328">1328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1330">1330</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1331">1331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1332">1332</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1333">1333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1334">1334</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1327">1327</a>.</li>
<li>Changed the following issues from Tentatively Dup to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1302">1302</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1308">1308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1313">1313</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1314">1314</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1228">1228</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1259">1259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1263">1263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1265">1265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1296">1296</a>.</li>
<li>Changed the following issues from Tentatively NAD Concepts to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1186">1186</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1185">1185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1210">1210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1212">1212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1225">1225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1244">1244</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1266">1266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1269">1269</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1272">1272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1275">1275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1291">1291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1305">1305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1307">1307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1311">1311</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#446">446</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1211">1211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#485">485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1135">1135</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1233">1233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1239">1239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1283">1283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1301">1301</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1226">1226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1273">1273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1274">1274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1293">1293</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1300">1300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1304">1304</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1315">1315</a>.</li>
<li>Changed the following issues from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1154">1154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1317">1317</a>.</li>
<li>Changed the following issues from Ready to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1052">1052</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1201">1201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1238">1238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1282">1282</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1268">1268</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1278">1278</a>.</li>
<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1281">1281</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>.</li>
<li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1159">1159</a>.</li>
<li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#427">427</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#896">896</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1079">1079</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#296">296</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1157">1157</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1216">1216</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1227">1227</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1237">1237</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1089">1089</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1208">1208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1220">1220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1231">1231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1241">1241</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1247">1247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1257">1257</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1261">1261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1262">1262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1264">1264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1267">1267</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1270">1270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1271">1271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1276">1276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1277">1277</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1280">1280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1284">1284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1285">1285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1286">1286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1287">1287</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1298">1298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1299">1299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1303">1303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1306">1306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1312">1312</a>.</li>
</ul></li>
</ul>
</li>
<li>R69: 
2010-02-12 pre-Pittsburgh mailing.
<ul>
<li><b>Summary:</b><ul>
<li>266 open issues, up by 61.</li>
<li>1052 closed issues, down by 3.</li>
<li>1318 issues total, up by 58.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1266">1266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1268">1268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1269">1269</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1272">1272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1275">1275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1278">1278</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1279">1279</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1281">1281</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1289">1289</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1290">1290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1291">1291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1292">1292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1294">1294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1295">1295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1297">1297</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1302">1302</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1305">1305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1307">1307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1308">1308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1310">1310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1311">1311</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1313">1313</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1314">1314</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1316">1316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1317">1317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1318">1318</a>.</li>
<li>Added the following Tentatively NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1263">1263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1265">1265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1296">1296</a>.</li>
<li>Added the following Tentatively NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1283">1283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1301">1301</a>.</li>
<li>Added the following Tentatively NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1282">1282</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1261">1261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1262">1262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1264">1264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1267">1267</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1270">1270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1271">1271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1273">1273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1274">1274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1276">1276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1277">1277</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1280">1280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1284">1284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1285">1285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1286">1286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1287">1287</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1293">1293</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1298">1298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1299">1299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1300">1300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1303">1303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1304">1304</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1306">1306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1312">1312</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1315">1315</a>.</li>
<li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#101">101</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1207">1207</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1079">1079</a>.</li>
<li>Changed the following issues from New to Tentatively Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1259">1259</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1106">1106</a>.</li>
<li>Changed the following issues from Ready to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>.</li>
<li>Changed the following issues from NAD to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>.</li>
<li>Changed the following issues from NAD Editorial to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1257">1257</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1089">1089</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1110">1110</a>.</li>
<li>Changed the following issues from Ready to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1247">1247</a>.</li>
<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>.</li>
</ul></li>
</ul>
</li>
<li>R68: 
2009-11-06 post-Santa Cruz mailing.
<ul>
<li><b>Summary:</b><ul>
<li>205 open issues, down by 77.</li>
<li>1055 closed issues, up by 120.</li>
<li>1260 issues total, up by 43.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a>.</li>
<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1236">1236</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1243">1243</a>.</li>
<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1232">1232</a>.</li>
<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1235">1235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1242">1242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1225">1225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1244">1244</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1252">1252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1253">1253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1257">1257</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1259">1259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1260">1260</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1228">1228</a>.</li>
<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1227">1227</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1237">1237</a>.</li>
<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1247">1247</a>.</li>
<li>Added the following Tentatively NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1233">1233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1239">1239</a>.</li>
<li>Added the following Tentatively NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1238">1238</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1220">1220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1226">1226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1231">1231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1241">1241</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>.</li>
<li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
<li>Changed the following issues from NAD Concepts to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>.</li>
<li>Changed the following issues from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1053">1053</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1211">1211</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>.</li>
<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>.</li>
<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1216">1216</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#296">296</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#485">485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1098">1098</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1157">1157</a>.</li>
<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1130">1130</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1186">1186</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1115">1115</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1201">1201</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1112">1112</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1208">1208</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
</ul></li>
</ul>
</li>
<li>R67: 
2009-09-25 pre-Santa Cruz mailing.
<ul>
<li><b>Summary:</b><ul>
<li>282 open issues, up by 32.</li>
<li>935 closed issues, down by 1.</li>
<li>1217 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1188">1188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1198">1198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1200">1200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1201">1201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1207">1207</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1208">1208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1210">1210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1211">1211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1212">1212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1214">1214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1215">1215</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1216">1216</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#296">296</a>.</li>
<li>Changed the following issues from WP to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1052">1052</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>.</li>
</ul></li>
</ul>
</li>
<li>R66: 
2009-07-31 post-Frankfurt mailing.
<ul>
<li><b>Summary:</b><ul>
<li>250 open issues, down by 128.</li>
<li>936 closed issues, up by 171.</li>
<li>1186 issues total, up by 43.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1164">1164</a>.</li>
<li>Added the following NAD Concepts issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1149">1149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1167">1167</a>.</li>
<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1168">1168</a>.</li>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1154">1154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1159">1159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1169">1169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1175">1175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1185">1185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1186">1186</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1157">1157</a>.</li>
<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#290">290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382">382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#394">394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#398">398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#417">417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#421">421</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#459">459</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#492">492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>.</li>
<li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>.</li>
<li>Changed the following issues from New to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
<li>Changed the following issues from Open to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>.</li>
<li>Changed the following issues from Review to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from Tentatively NAD to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>.</li>
<li>Changed the following issues from Tentatively NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
<li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#423">423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
<li>Changed the following issues from CD1 to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li>
<li>Changed the following issues from NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>.</li>
<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1093">1093</a>.</li>
<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>.</li>
<li>Changed the following issues from Tentatively NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>.</li>
<li>Changed the following issues from Tentatively NAD to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>.</li>
<li>Changed the following issues from Tentatively Ready to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>.</li>
<li>Changed the following issues from NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>.</li>
<li>Changed the following issues from Tentatively NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>.</li>
<li>Changed the following issues from Tentatively Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>.</li>
</ul></li>
</ul>
</li>
<li>R65: 
2009-06-19 pre-Frankfurt mailing.
<ul>
<li><b>Summary:</b><ul>
<li>378 open issues, up by 32.</li>
<li>765 closed issues, up by 0.</li>
<li>1143 issues total, up by 32.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1110">1110</a>.</li>
<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>.</li>
<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>.</li>
<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#884">884</a>.</li>
<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.</li>
<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>.</li>
</ul></li>
</ul>
</li>
<li>R64: 
2009-05-01 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>346 open issues, up by 19.</li>
<li>765 closed issues, up by 0.</li>
<li>1111 issues total, up by 19.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
<li>Changed the following issues from DR to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li>
<li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
</ul></li>
</ul>
</li>
<li>R63: 
2009-03-20 post-Summit mailing.
<ul>
<li><b>Summary:</b><ul>
<li>327 open issues, up by 96.</li>
<li>765 closed issues, up by 14.</li>
<li>1092 issues total, up by 110.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li>
<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1089">1089</a>.</li>
<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
<li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
<li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>.</li>
<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
</ul></li>
</ul>
</li>
<li>R62: 
2009-02-06 pre-Summit mailing.
<ul>
<li><b>Summary:</b><ul>
<li>231 open issues, up by 44.</li>
<li>751 closed issues, up by 0.</li>
<li>982 issues total, up by 44.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>.</li>
</ul></li>
</ul>
</li>
<li>R61: 
2008-12-05 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>187 open issues, up by 20.</li>
<li>751 closed issues, up by 0.</li>
<li>938 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>.</li>
</ul></li>
</ul>
</li>
<li>R60: 
2008-10-03 post-San Francisco mailing.
<ul>
<li><b>Summary:</b><ul>
<li>167 open issues, down by 25.</li>
<li>751 closed issues, up by 65.</li>
<li>918 issues total, up by 40.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#896">896</a>.</li>
<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
<li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li>
<li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li>
<li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#167">167</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#291">291</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#300">300</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#305">305</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#370">370</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#420">420</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
<li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#62">62</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.</li>
</ul></li>
</ul>
</li>
<li>R59: 
2008-08-22 pre-San Francisco mailing.
<ul>
<li><b>Summary:</b><ul>
<li>192 open issues, up by 9.</li>
<li>686 closed issues, up by 0.</li>
<li>878 issues total, up by 9.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
</ul></li>
</ul>
</li>
<li>R58: 
2008-07-28 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>183 open issues, up by 12.</li>
<li>686 closed issues, down by 4.</li>
<li>869 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>.</li>
<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>.</li>
</ul></li>
</ul>
</li>
<li>R57: 
2008-06-27 post-Sophia Antipolis mailing.
<ul>
<li><b>Summary:</b><ul>
<li>171 open issues, down by 20.</li>
<li>690 closed issues, up by 43.</li>
<li>861 issues total, up by 23.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#861">861</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>.</li>
<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>.</li>
<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
</ul></li>
</ul>
</li>
<li>R56: 
2008-05-16 pre-Sophia Antipolis mailing.
<ul>
<li><b>Summary:</b><ul>
<li>191 open issues, up by 24.</li>
<li>647 closed issues, up by 1.</li>
<li>838 issues total, up by 25.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li>
</ul></li>
</ul>
</li>
<li>R55: 
2008-03-14 post-Bellevue mailing.
<ul>
<li><b>Summary:</b><ul>
<li>167 open issues, down by 39.</li>
<li>646 closed issues, up by 65.</li>
<li>813 issues total, up by 26.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
<li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li>
<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a>.</li>
<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
</ul></li>
</ul>
</li>
<li>R54: 
2008-02-01 pre-Bellevue mailing.
<ul>
<li><b>Summary:</b><ul>
<li>206 open issues, up by 23.</li>
<li>581 closed issues, up by 0.</li>
<li>787 issues total, up by 23.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li>
<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#353">353</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#697">697</a>.</li>
<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
</ul></li>
</ul>
</li>
<li>R53: 
2007-12-09 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>183 open issues, up by 11.</li>
<li>581 closed issues, down by 1.</li>
<li>764 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>.</li>
<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
</ul></li>
</ul>
</li>
<li>R52: 
2007-10-19 post-Kona mailing.
<ul>
<li><b>Summary:</b><ul>
<li>172 open issues, up by 4.</li>
<li>582 closed issues, up by 27.</li>
<li>754 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
<li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>.</li>
<li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
<li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
</ul></li>
</ul>
</li>
<li>R51: 
2007-09-09 pre-Kona mailing.
<ul>
<li><b>Summary:</b><ul>
<li>168 open issues, up by 15.</li>
<li>555 closed issues, up by 0.</li>
<li>723 issues total, up by 15.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>.</li>
</ul></li>
</ul>
</li>
<li>R50: 
2007-08-05 post-Toronto mailing.
<ul>
<li><b>Summary:</b><ul>
<li>153 open issues, down by 5.</li>
<li>555 closed issues, up by 17.</li>
<li>708 issues total, up by 12.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>.</li>
<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li>
<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#525">525</a>.</li>
<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li>
<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li>
<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
<li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
</ul></li>
</ul>
</li>
<li>R49: 
2007-06-23 pre-Toronto mailing.
<ul>
<li><b>Summary:</b><ul>
<li>158 open issues, up by 13.</li>
<li>538 closed issues, up by 7.</li>
<li>696 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>.</li>
<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li>
<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li>
<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li>
</ul></li>
</ul>
</li>
<li>R48: 
2007-05-06 post-Oxford mailing.
<ul>
<li><b>Summary:</b><ul>
<li>145 open issues, down by 33.</li>
<li>531 closed issues, up by 53.</li>
<li>676 issues total, up by 20.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#676">676</a>.</li>
<li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
<li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li>
<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>.</li>
<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>.</li>
<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li>
<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>R47: 
2007-03-09 pre-Oxford mailing.
<ul>
<li><b>Summary:</b><ul>
<li>178 open issues, up by 37.</li>
<li>478 closed issues, up by 0.</li>
<li>656 issues total, up by 37.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>.</li>
<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li>
</ul></li>
</ul>
</li>
<li>R46: 
2007-01-12 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>141 open issues, up by 11.</li>
<li>478 closed issues, down by 1.</li>
<li>619 issues total, up by 10.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
</ul></li>
</ul>
</li>
<li>R45: 
2006-11-03 post-Portland mailing.
<ul>
<li><b>Summary:</b><ul>
<li>130 open issues, up by 0.</li>
<li>479 closed issues, up by 17.</li>
<li>609 issues total, up by 17.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a> to Open.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
</ul></li>
</ul>
</li>
<li>R44: 
2006-09-08 pre-Portland mailing.
<ul>
<li><b>Summary:</b><ul>
<li>130 open issues, up by 6.</li>
<li>462 closed issues, down by 1.</li>
<li>592 issues total, up by 5.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
</ul></li>
</ul>
</li>
<li>R43: 
2006-06-23 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>124 open issues, up by 14.</li>
<li>463 closed issues, down by 1.</li>
<li>587 issues total, up by 13.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>.</li>
<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
</ul></li>
</ul>
</li>
<li>R42: 
2006-04-21 post-Berlin mailing.
<ul>
<li><b>Summary:</b><ul>
<li>110 open issues, down by 16.</li>
<li>464 closed issues, up by 24.</li>
<li>574 issues total, up by 8.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
</ul></li>
</ul>
</li>
<li>R41: 
2006-02-24 pre-Berlin mailing.
<ul>
<li><b>Summary:</b><ul>
<li>126 open issues, up by 31.</li>
<li>440 closed issues, up by 0.</li>
<li>566 issues total, up by 31.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a> ,<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a> from Ready to Open.</li>
<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>.</li>
</ul></li>
</ul>
</li>
<li>R40: 
2005-12-16 mid-term mailing.
<ul>
<li><b>Summary:</b><ul>
<li>95 open issues.</li>
<li>440 closed issues.</li>
<li>535 issues total.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
</ul></li>
</ul>
</li>
<li>R39: 
2005-10-14 post-Mont Tremblant mailing.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
</li>
<li>R38: 
2005-07-03 pre-Mont Tremblant mailing.
Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>
</li>
<li>R37: 
2005-06 mid-term mailing.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>.
</li>
<li>R36: 
2005-04 post-Lillehammer mailing. All issues in "ready" status except
for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
previously in "DR" status were moved to "WP".
</li>
<li>R35: 
2005-03 pre-Lillehammer mailing.
</li>
<li>R34: 
2005-01 mid-term mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
</li>
<li>R33: 
2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
</li>
<li>R32: 
2004-09 pre-Redmond mailing: reflects new proposed resolutions and
new issues received after the 2004-07 mailing.  Added
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
</li>
<li>R31: 
2004-07 mid-term mailing: reflects new proposed resolutions and
new issues received after the post-Sydney mailing.  Added
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
</li>
<li>R30: 
Post-Sydney mailing: reflects decisions made at the Sydney meeting.
Voted all "Ready" issues from R29 into the working paper.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
</li>
<li>R29: 
Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
</li>
<li>R28: 
Post-Kona mailing: reflects decisions made at the Kona meeting.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
</li>
<li>R27: 
Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>.
</li>
<li>R26: 
Post-Oxford mailing: reflects decisions made at the Oxford meeting.
All issues in Ready status were voted into DR status.  All issues in
DR status were voted into WP status.
</li>
<li>R25: 
Pre-Oxford mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
</li>
<li>R24: 
Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
meeting.  All Ready issues from R23 with the exception of <iref ref="253">, which has been given a new proposed resolution, were
moved to DR status.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<iref ref="389">.  (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
at the meeting.)  Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <iref ref="226">, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <iref ref="229"> have been moved to Ready status, and the only remaining
concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
</iref></iref></iref></iref></li>
<li>R23: 
Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382">382</a>.
Moved issues in the TC to TC status.
</li>
<li>R22: 
Post-Cura�ao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<iref ref="366">.
</iref></li>
<li>R21: 
Pre-Cura�ao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<iref ref="361">.
</iref></li>
<li>R20: 
Post-Redmond mailing; reflects actions taken in Redmond.  Added
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
not discussed at the meeting.  

All Ready issues were moved to DR status, with the exception of issues
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.

Noteworthy issues discussed at Redmond include 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
</li>
<li>R19: 
Pre-Redmond mailing.  Added new issues 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
</li>
<li>R18: 
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.

Changed status of issues
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
to DR.

Changed status of issues
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
to Ready.

Closed issues 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
as NAD.

</li>
<li>R17: 
Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <iref ref="91">, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
</iref></li>
<li>R16:  
post-Toronto mailing; reflects actions taken in Toronto. Added new
issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>.  Changed status of issues
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR".  Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>. Reopened
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
the bug in enough places.
</li>
<li>R15: 
pre-Toronto mailing. Added issues
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
changes so that we pass Weblint tests.
</li>
<li>R14: 
post-Tokyo II mailing; reflects committee actions taken in
Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
</li>
<li>R13: 
pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
</li>
<li>R12: 
pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
</li>
<li>R11: 
post-Kona mailing: Updated to reflect LWG and full committee actions
in Kona (99-0048/N1224). Note changed resolution of issues
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
"closed" documents.  Changed the proposed resolution of issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
</li>
<li>R10: 
pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
</li>
<li>R9: 
pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
"closed" documents. (99-0030/N1206, 25 Aug 99)
</li>
<li>R8: 
post-Dublin mailing. Updated to reflect LWG and full committee actions
in Dublin. (99-0016/N1193, 21 Apr 99)
</li>
<li>R7: 
pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
</li>
<li>R6: 
pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
</li>
<li>R5: 
update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
for making list public. (30 Dec 98)
</li>
<li>R4: 
post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
issues corrected. (22 Oct 98)
</li>
<li>R3: 
post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
added, many issues updated to reflect LWG consensus (12 Oct 98)
</li>
<li>R2: 
pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
</li>
<li>R1: 
Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
</li>
</ul>

<h2>Defect Reports</h2>
<hr>
<h3><a name="1"></a>1. C library linkage editing oversight</h3>
<p><b>Section:</b> 17.6.2.3 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The change specified in the proposed resolution below did not make
it into the Standard. This change was accepted in principle at the
London meeting, and the exact wording below was accepted at the
Morristown meeting.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 17.6.2.3 [using.linkage] paragraph 2
from:</p>

<blockquote>
  <p>It is unspecified whether a name from the Standard C library
  declared with external linkage has either extern "C" or
  extern "C++" linkage.</p>
</blockquote>

<p>to:</p>

<blockquote>
  <p>Whether a name from the Standard C library declared with external
  linkage has extern "C" or extern "C++" linkage
  is implementation defined. It is recommended that an implementation
  use extern "C++" linkage for this purpose.</p>
</blockquote>





<hr>
<h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3>
<p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1997-12-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>We appear not to have covered all the possibilities of
 exit processing with respect to
atexit registration. <br>
<br>
Example 1: (C and C++)</p>

<pre>    #include &lt;stdlib.h&gt;
    void f1() { }
    void f2() { atexit(f1); }
    
    int main()
    {
        atexit(f2); // the only use of f2
        return 0; // for C compatibility
    }</pre>

<p>At program exit, f2 gets called due to its registration in
main. Running f2 causes f1 to be newly registered during the exit
processing. Is this a valid program? If so, what are its
semantics?</p>

<p>
Interestingly, neither the C standard, nor the C++ draft standard nor
the forthcoming C9X Committee Draft says directly whether you can
register a function with atexit during exit processing.</p>

<p>
All 3 standards say that functions are run in reverse order of their
registration. Since f1 is registered last, it ought to be run first,
but by the time it is registered, it is too late to be first.</p>

<p>If the program is valid, the standards are self-contradictory about
its semantics.</p>

<p>Example 2: (C++ only)</p>

<pre>    
    void F() { static T t; } // type T has a destructor

    int main()
    {
        atexit(F); // the only use of F
    }
</pre>

<p>Function F registered with atexit has a local static variable t,
and F is called for the first time during exit processing. A local
static object is initialized the first time control flow passes
through its definition, and all static objects are destroyed during
exit processing. Is the code valid? If so, what are its semantics?</p>

<p>
Section 18.3 "Start and termination" says that if a function
F is registered with atexit before a static object t is initialized, F
will not be called until after t's destructor completes.</p>

<p>
In example 2, function F is registered with atexit before its local
static object O could possibly be initialized. On that basis, it must
not be called by exit processing until after O's destructor
completes. But the destructor cannot be run until after F is called,
since otherwise the object could not be constructed in the first
place.</p>

<p>If the program is valid, the standard is self-contradictory about
its semantics.</p>

<p>I plan to submit Example 1 as a public comment on the C9X CD, with
a recommendation that the results be undefined. (Alternative: make it
unspecified. I don't think it is worthwhile to specify the case where
f1 itself registers additional functions, each of which registers
still more functions.)</p>

<p>I think we should resolve the situation in the whatever way the C
committee decides. </p>

<p>For Example 2, I recommend we declare the results undefined.</p>

<p><i>[See reflector message lib-6500 for further discussion.]</i></p>




<p><b>Proposed resolution:</b></p>
<p>Change section 18.3/8 from:</p>
<blockquote><p>
  First, objects with static storage duration are destroyed and
  functions registered by calling atexit are called. Objects with
  static storage duration are destroyed in the reverse order of the
  completion of their constructor.  (Automatic objects are not
  destroyed as a result of calling exit().) Functions registered with
  atexit are called in the reverse order of their registration.  A
  function registered with atexit before an object obj1 of static
  storage duration is initialized will not be called until obj1's
  destruction has completed. A function registered with atexit after
  an object obj2 of static storage duration is initialized will be
  called before obj2's destruction starts.
</p></blockquote>
<p>to:</p>
<blockquote><p>
  First, objects with static storage duration are destroyed and
  functions registered by calling atexit are called. Non-local objects
  with static storage duration are destroyed in the reverse order of
  the completion of their constructor. (Automatic objects are not
  destroyed as a result of calling exit().) Functions registered with
  atexit are called in the reverse order of their registration, except
  that a function is called after any previously registered functions
  that had already been called at the time it was registered. A
  function registered with atexit before a non-local object obj1 of
  static storage duration is initialized will not be called until
  obj1's destruction has completed. A function registered with atexit
  after a non-local object obj2 of static storage duration is
  initialized will be called before obj2's destruction starts. A local
  static object obj3 is destroyed at the same time it would be if a
  function calling the obj3 destructor were registered with atexit at
  the completion of the obj3 constructor.
</p></blockquote>


<p><b>Rationale:</b></p>
<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
supporting to the proposed resolution.</p>





<hr>
<h3><a name="5"></a>5. String::compare specification questionable</h3>
<p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Jack Reeves <b>Opened:</b> 1997-12-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p>
<p><b>Discussion:</b></p>
<p>At the very end of the basic_string class definition is the signature: int
compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
following text this is defined as: returns
basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>

<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
= Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
throws length_error if n == npos, it appears the compare() signature above should always
throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
null terminated character array. </p>

<p>This appears to be a typo since the obvious intent is to allow either the call above or
something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>

<p>This would imply that what was really intended was two signatures int compare(size_type
pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>


<p><b>Proposed resolution:</b></p>
<p>Replace the compare signature in 21.4 [basic.string]
(at the very end of the basic_string synopsis) which reads:</p>

<blockquote>
  <p><tt>int compare(size_type pos1, size_type n1,<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
  size_type n2 = npos) const;</tt></p>
</blockquote>

<p>with:</p>

<blockquote>
  <p><tt>int compare(size_type pos1, size_type n1,<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
  int compare(size_type pos1, size_type n1,<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
  size_type n2) const;</tt></p>
</blockquote>

<p>Replace the portion of 21.4.6.8 [string::swap]
paragraphs 5 and 6 which read:</p>

<blockquote>
  <p><tt>int compare(size_type pos, size_type n1,<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
  = npos) const;<br>
  </tt>Returns:<tt><br>
  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
</blockquote>

<p>with:</p>

<blockquote>
  <p><tt>int compare(size_type pos, size_type n1,<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
  </tt>Returns:<tt><br>
  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
  <br>
  int compare(size_type pos, size_type n1,<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
  size_type n2) const;<br>
  </tt>Returns:<tt><br>
  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
</blockquote>

<p>Editors please note that in addition to splitting the signature, the third argument
becomes const, matching the existing synopsis.</p>


<p><b>Rationale:</b></p>
<p>While the LWG dislikes adding signatures, this is a clear defect in
the Standard which must be fixed.&nbsp; The same problem was also
identified in issues 7 (item 5) and 87.</p>





<hr>
<h3><a name="7"></a>7. String clause minor problems</h3>
<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>(1) In 21.4.6.4 [string::insert], the description of template
&lt;class InputIterator&gt; insert(iterator, InputIterator,
InputIterator) makes no sense. It refers to a member function that
doesn't exist. It also talks about the return value of a void
function. </p>

<p>(2) Several versions of basic_string::replace don't appear in the
class synopsis. </p>

<p>(3) basic_string::push_back appears in the synopsis, but is never
described elsewhere.  In the synopsis its argument is const charT,
which doesn't makes much sense; it should probably be charT, or
possible const charT&amp;. </p>

<p>(4) basic_string::pop_back is missing. </p>

<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
= npos) make no sense. First, it's const charT* in the synopsis and
charT* in the description. Second, given what it says in RETURNS,
leaving out the final argument will always result in an exception
getting thrown. This is paragraphs 5 and 6 of 
21.4.6.8 [string::swap]</p>

<p>(6) In table 37, in section 21.2.1 [char.traits.require],
there's a note for X::move(s, p, n). It says "Copies correctly
even where p is in [s, s+n)". This is correct as far as it goes,
but it doesn't go far enough; it should also guarantee that the copy
is correct even where s in in [p, p+n). These are two orthogonal
guarantees, and neither one follows from the other. Both guarantees
are necessary if X::move is supposed to have the same sort of
semantics as memmove (which was clearly the intent), and both
guarantees are necessary if X::move is actually supposed to be
useful. </p>


<p><b>Proposed resolution:</b></p>
<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
<br>
&nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
<br>
ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
<br>
ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
[lib.basic.string]) from:</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
<br>
to<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
<br>
Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
<br>
&nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
&nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
<br>
ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
<br>
ITEM 5: Duplicate; see issue 5 (and 87).<br>
<br>
ITEM 6: In table 37, Replace:<br>
<br>
&nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
<br>
with:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
s+n) overlap."</p>





<hr>
<h3><a name="8"></a>8. Locale::global lacks guarantee</h3>
<p><b>Section:</b> 22.3.1.5 [locale.statics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It appears there's an important guarantee missing from clause
22. We're told that invoking locale::global(L) sets the C locale if L
has a name. However, we're not told whether or not invoking
setlocale(s) sets the global C++ locale. </p>

<p>The intent, I think, is that it should not, but I can't find any
such words anywhere. </p>


<p><b>Proposed resolution:</b></p>
<p>Add a sentence at the end of 22.3.1.5 [locale.statics],
paragraph 2:&nbsp; </p>

<blockquote>
  <p>No library function other than <tt>locale::global()</tt> shall affect 
  the value returned by <tt>locale()</tt>. </p>

</blockquote>





<hr>
<h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3>
<p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-01-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
section 3.7.3.1 of CD2 seems to allow for the possibility that all
calls to operator new(0) yield the same pointer, an implementation
technique specifically prohibited by ARM 5.3.3.Was this prohibition
really lifted? Does the FDIS agree with CD2 in the regard? [Issues
list maintainer's note: the IS is the same.]</p>


<p><b>Proposed resolution:</b></p>
<p>Change the last paragraph of 3.7.3 from:</p>
<blockquote>
  <p>Any allocation and/or deallocation functions defined in a C++ program shall
  conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>Any allocation and/or deallocation functions defined in a C++ program,
  including the default versions in the library, shall conform to the semantics
  specified in 3.7.3.1 and 3.7.3.2.</p>
</blockquote>
<p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
<blockquote>
  <p>If the size of the space requested is zero, the value returned shall not be
  a null pointer value (4.10).</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>Even if the size of the space requested is zero, the request can fail. If
  the request succeeds, the value returned shall be a non-null pointer value
  (4.10) p0 different from any previously returned value p1, unless that value
  p1 was since passed to an operator delete.</p>
</blockquote>
<p>5.3.4/7 currently reads:</p>
<blockquote>
  <p>When the value of the expression in a direct-new-declarator is zero, the
  allocation function is called to allocate an array with no elements. The
  pointer returned by the new-expression is non-null. [Note: If the library
  allocation function is called, the pointer returned is distinct from the
  pointer to any other object.]</p>
</blockquote>
<p>Retain the first sentence, and delete the remainder.</p>
<p>18.5.1 currently has no text. Add the following:</p>
<blockquote>
  <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
  library versions of operator new and operator delete.</p>
</blockquote>
<p>To 18.5.1.3, add the following text:</p>
<blockquote>
  <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
  operator new and operator delete.</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
supporting to the proposed resolution.</p>





<hr>
<h3><a name="11"></a>11. Bitset minor problems</h3>
<p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
not documented in 23.3.5.2. </p>

<p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>

<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
go in the Effects clause.</p>


<p><b>Proposed resolution:</b></p>
<p>ITEMS 1 AND 2:<br>
<br>
In the bitset synopsis (20.5 [template.bitset]), 
replace the member function <br>
<br>
<tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
</tt><br>
with the two member functions<br>
<br>
<tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
&nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
</tt><br>
Add the following text at the end of 20.5.2 [bitset.members], 
immediately after paragraph 45:</p>

<blockquote>
  <p><tt>bool operator[](size_t pos) const;</tt><br>
  Requires: pos is valid<br>
  Throws: nothing<br>
  Returns: <tt>test(pos)</tt><br>
  <br>
  <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
  Requires: pos is valid<br>
  Throws: nothing<br>
  Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
  == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
  val);</tt></p>
</blockquote>


<p><b>Rationale:</b></p>
<p>The LWG believes Item 3 is not a defect. "Formatted
input" implies the desired semantics. See 27.7.1.2 [istream.formatted].
</p>





<hr>
<h3><a name="13"></a>13. Eos refuses to die</h3>
<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> William M. Miller <b>Opened:</b> 1998-03-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 27.6.1.2.3, there is a reference to "eos", which is
the only one in the whole draft (at least using Acrobat search), so
it's undefined. </p>


<p><b>Proposed resolution:</b></p>
<p>In 27.7.1.2.3 [istream::extractors], replace "eos" with
"charT()"</p>





<hr>
<h3><a name="14"></a>14. Locale::combine should be const</h3>
<p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>locale::combine is the only member function of locale (other than constructors and
destructor) that is not const. There is no reason for it not to be const, and good reasons
why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
paragraph 6: "An instance of a locale is immutable." </p>

<p>History: this member function originally was a constructor. it happened that the
interface it specified had no corresponding language syntax, so it was changed to a member
function. As constructors are never const, there was no "const" in the interface
which was transformed into member "combine". It should have been added at that
time, but the omission was not noticed. </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.3.1 [locale] and also in 22.3.1.3 [locale.members], add 
"const" to the declaration of member combine: </p>
<blockquote>
  <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
</blockquote>





<hr>
<h3><a name="15"></a>15. Locale::name requirement inconsistent</h3>
<p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>locale::name() is described as returning a string that can be passed to a locale
constructor, but there is no matching constructor. </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.3.1.3 [locale.members], paragraph 5, replace
"<tt>locale(name())</tt>" with
"<tt>locale(name().c_str())</tt>".
</p>





<hr>
<h3><a name="16"></a>16. Bad ctype_byname&lt;char&gt; decl</h3>
<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
edited in properly. Instead, the member do_widen appears four times, with wrong argument
lists. </p>


<p><b>Proposed resolution:</b></p>
<p>The correct declarations for the overloaded members
<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied 
from 22.4.1.3 [facet.ctype.special].</p>





<hr>
<h3><a name="17"></a>17. Bad bool parsing</h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>This section describes the process of parsing a text boolean value from the input
stream. It does not say it recognizes either of the sequences "true" or
"false" and returns the corresponding bool value; instead, it says it recognizes
only one of those sequences, and chooses which according to the received value of a
reference argument intended for returning the result, and reports an error if the other
sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
flag wrongly; it doesn't define the value "loc"; and finally, it computes
wrongly whether to use numeric or "alpha" parsing.<br>
<br>
I believe the correct algorithm is "as if": </p>

<pre>  // in, err, val, and str are arguments.
  err = 0;
  const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
  const string_type t = np.truename(), f = np.falsename();
  bool tm = true, fm = true;
  size_t pos = 0;
  while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
    if (in == end) { err = str.eofbit; }
    bool matched = false;
    if (tm &amp;&amp; pos &lt; t.size()) {
      if (!err &amp;&amp; t[pos] == *in) matched = true;
      else tm = false;
    }
    if (fm &amp;&amp; pos &lt; f.size()) {
      if (!err &amp;&amp; f[pos] == *in) matched = true;
      else fm = false;
    }
    if (matched) { ++in; ++pos; }
    if (pos &gt; t.size()) tm = false;
    if (pos &gt; f.size()) fm = false;
  }
  if (tm == fm || pos == 0) { err |= str.failbit; }
  else                      { val = tm; }
  return in;</pre>

<p>Notice this works reasonably when the candidate strings are both empty, or equal, or
when one is a substring of the other. The proposed text below captures the logic of the
code above.</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
change "&amp;&amp;" to "&amp;".</p>

<p>Then, replace paragraphs 15 and 16 as follows:</p>

<blockquote>

  <p>Otherwise target sequences are determined "as if" by
  calling the members <tt>falsename()</tt> and
  <tt>truename()</tt> of the facet obtained by
  <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.  
  Successive characters in the range <tt>[in,end)</tt> (see
  [lib.sequence.reqmts]) are obtained and matched against
  corresponding positions in the target sequences only as necessary to
  identify a unique match. The input iterator <tt>in</tt> is
  compared to <tt>end</tt> only when necessary to obtain a
  character. If and only if a target sequence is uniquely matched,
  <tt>val</tt> is set to the corresponding value.</p>

</blockquote>

<blockquote>
  <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
  successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
  <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
  <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
  <tt>(str.failbit|str.eofbit)</tt>if
  the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
  <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
  <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
  <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
  <tt>true</tt>:"1"
  and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
  and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
  <tt>err==str.failbit</tt>. --end example]</p>
</blockquote>





<hr>
<h3><a name="18"></a>18. Get(...bool&amp;) omitted</h3>
<p><b>Section:</b> 22.4.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
that parses bool values was omitted from the list of definitions of non-virtual
members, though it is listed in the class definition and the corresponding
virtual is listed everywhere appropriate. </p>


<p><b>Proposed resolution:</b></p>
<p>Add at the beginning of 22.4.2.1.1 [facet.num.get.members]
another get member for bool&amp;, copied from the entry in 
22.4.2.1 [locale.num.get].</p>





<hr>
<h3><a name="19"></a>19. "Noconv" definition too vague</h3>
<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p>
<p><b>Discussion:</b></p>
<p>
In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
specified to return noconv if "no conversion is
needed". This definition is too vague, and does not say
normatively what is done with the buffers.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the entry for noconv in the table under paragraph 4 in section 
22.4.1.4.2 [locale.codecvt.virtuals] to read:
</p>
<blockquote>
  <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
  and input sequence is identical to converted sequence.</p>
</blockquote>
<p>Change the Note in paragraph 2 to normative text as follows:</p>
<blockquote>
  <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
  same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
  <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
  unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
</blockquote>





<hr>
<h3><a name="20"></a>20. Thousands_sep returns wrong type</h3>
<p><b>Section:</b> 22.4.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
that it returns a value of type char_type. Here it is erroneously
described as returning a "string_type". </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change 
"string_type" to "char_type". </p>





<hr>
<h3><a name="21"></a>21. Codecvt_byname&lt;&gt; instantiations</h3>
<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the second table in the section, captioned "Required
instantiations", the instantiations for codecvt_byname&lt;&gt;
have been omitted. These are necessary to allow users to construct a
locale by name from facets. </p>


<p><b>Proposed resolution:</b></p>
<p>Add in 22.3.1.1.1 [locale.category] to the table captioned
"Required instantiations", in the category "ctype"
the lines </p>

<blockquote>
  <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
</blockquote>





<hr>
<h3><a name="22"></a>22. Member open vs. flags</h3>
<p><b>Section:</b> 27.9.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
responds to or changes flags in the error status for the stream. A strict reading
indicates that it ignores the bits and does not change them, which confuses users who do
not expect eofbit and failbit to remain set after a successful open. There are three
reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
and eofbit on call to open(). </p>


<p><b>Proposed resolution:</b></p>
<p>In 27.9.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.9.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote:
</p>

<blockquote>
  <p>A successful open does not change the error state.</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>This may seem surprising to some users, but it's just an instance
of a general rule: error flags are never cleared by the
implementation. The only way error flags are are ever cleared is if
the user explicitly clears them by hand.</p>

<p>The LWG believed that preserving this general rule was
important enough so that an exception shouldn't be made just for this
one case.  The resolution of this issue clarifies what the LWG
believes to have been the original intent.</p>






<hr>
<h3><a name="23"></a>23. Num_get overflow result</h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The current description of numeric input does not account for the
possibility of overflow. This is an implicit result of changing the
description to rely on the definition of scanf() (which fails to
report overflow), and conflicts with the documented behavior of
traditional and current implementations. </p>

<p>Users expect, when reading a character sequence that results in a
value unrepresentable in the specified type, to have an error
reported. The standard as written does not permit this. </p>

<p><b>Further comments from Dietmar:</b></p>

<p>
I don't feel comfortable with the proposed resolution to issue 23: It
kind of simplifies the issue to much. Here is what is going on:
</p>

<p>
Currently, the behavior of numeric overflow is rather counter intuitive
and hard to trace, so I will describe it briefly:
</p>

<ul>
  <li>
    According to 22.4.2.1.2 [facet.num.get.virtuals]
    paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
    return an input error; otherwise a value is converted to the rules
    of <tt>scanf</tt>.
  </li>
  <li> 
    <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>. 
  </li>
  <li>
    <tt>fscanf()</tt> returns an input failure if during conversion no
    character matching the conversion specification could be extracted
    before reaching EOF. This is the only reason for <tt>fscanf()</tt>
    to fail due to an input error and clearly does not apply to the case
    of overflow.
  </li>
  <li>
    Thus, the conversion is performed according to the rules of
    <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
    <tt>strtol()</tt>, etc. are to be used for the conversion.
  </li>
  <li>
    The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
    many matching characters as there are and on overflow continue to
    consume matching characters but also return a value identical to
    the maximum (or minimum for signed types if there was a leading minus)
    value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
  </li>
  <li>
    Thus, according to the current wording in the standard, overflows
    can be detected! All what is to be done is to check <tt>errno</tt>
    after reading an element and, of course, clearing <tt>errno</tt>
    before trying a conversion. With the current wording, it can be
    detected whether the overflow was due to a positive or negative
    number for signed types.
  </li>
</ul>

<p><b>Further discussion from Redmond:</b></p>

<p>The basic problem is that we've defined our behavior,
including our error-reporting behavior, in terms of C90.  However,
C90's method of reporting overflow in scanf is not technically an
"input error".  The <tt>strto_*</tt> functions are more precise.</p>

<p>There was general consensus that <tt>failbit</tt> should be set
upon overflow.  We considered three options based on this:</p>
<ol>
<li>Set failbit upon conversion error (including overflow), and 
    don't store any value.</li>
<li>Set failbit upon conversion error, and also set <tt>errno</tt> to 
    indicated the precise nature of the error.</li>
<li>Set failbit upon conversion error.  If the error was due to
    overflow, store +-numeric_limits&lt;T&gt;::max() as an
    overflow indication.</li>
</ol>

<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>


<p>Discussed at Lillehammer.  General outline of what we want the
  solution to look like: we want to say that overflow is an error, and
  provide a way to distinguish overflow from other kinds of errors.
  Choose candidate field the same way scanf does, but don't describe
  the rest of the process in terms of format.  If a finite input field
  is too large (positive or negative) to be represented as a finite
  value, then set failbit and assign the nearest representable value.
  Bill will provide wording.</p>

<p>
Discussed at Toronto:
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
is in alignment with the direction we wanted to go with in Lillehammer.  Bill
to work on.
</p>



<p><b>Proposed resolution:</b></p>

<p>
Change 22.4.2.1.2 [facet.num.get.virtuals], end of p3:
</p>

<blockquote>
<p>
<b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
<ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
converted to a numeric value by the rules of one of the functions declared
in the header <tt>&lt;cstdlib&gt;</tt>:</ins>
</p>
<ul>
<li>
<del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
converted (according to the rules of <tt>scanf</tt>) to a value of the
type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
stored in <i>err</i>.</del>
<ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
</li>
<li>
<del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
<tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
assigned to <i>err</i>.</del>
<ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
</li>
<li>
<ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
</li>
</ul>
<p>
<ins>The numeric value to be stored can be one of:</ins>
</p>
<ul>
<li><ins>zero, if the conversion function fails to convert the entire field.
<tt>ios_base::failbit</tt> is assigned to err.</ins></li>
<li><ins>the most positive representable value, if the field represents a value
too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
to <i>err</i>.</ins></li>
<li><ins>the most negative representable value (zero for unsigned integer), if
the field represents a value too large negative to be represented in <i>val</i>.
<tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
<li><ins>the converted value, otherwise.</ins></li>
</ul>

<p><ins>
The resultant numeric value is stored in <i>val</i>.
</ins></p>
</blockquote>

<p>
Change 22.4.2.1.2 [facet.num.get.virtuals], p6-p7:
</p>

<blockquote>
<pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base&amp; <i>str</i>, 
                 ios_base::iostate&amp; <i>err</i>, bool&amp; <i>val</i>) const;
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> If
<tt>(<i>str</i>.flags()&amp;ios_base::boolalpha)==0</tt> then input
proceeds as it would for a <tt>long</tt> except that if a value is being
stored into <i>val</i>, the value is determined according to the
following: If the value to be stored is 0 then <tt>false</tt> is stored.
If the value is 1 then <tt>true</tt> is stored. Otherwise
<del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
</p>
<p>
-7- Otherwise target sequences are determined "as if" by calling the
members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
obtained by <tt>use_facet&lt;numpunct&lt;charT&gt;
&gt;(<i>str</i>.getloc())</tt>. Successive characters in the range
<tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
against corresponding positions in the target sequences only as
necessary to identify a unique match. The input iterator <i>in</i> is
compared to <i>end</i> only when necessary to obtain a character. If <del>and
only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
is assigned to <i>err</i>.</ins>
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="24"></a>24. "do_convert" doesn't exist</h3>
<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p>
<p><b>Discussion:</b></p>
<p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
symbol "do_convert" which is not defined in the
standard. This is a leftover from an edit, and should be "do_in
and do_out". </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.1.4 [locale.codecvt], paragraph 3, change
"do_convert" to "do_in or do_out". Also, in 22.4.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
or do_out". </p>





<hr>
<h3><a name="25"></a>25. String operator&lt;&lt; uses width() value wrong</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p>
<p><b>Discussion:</b></p>
<p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
the smaller of os.width() and str.size(), to pad "as described in stage 3"
elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>


<p><b>Proposed resolution:</b></p>
<p>Change 21.4.8.9 [string.io]  paragraph 4 from:<br>
<br>
&nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
..."<br>
<br>
to: <br>
<br>
&nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
..."</p>





<hr>
<h3><a name="26"></a>26. Bad sentry example</h3>
<p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In paragraph 6, the code in the example: </p>

<pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
  basic_istream&lt;charT,traits&gt;::sentry(
           basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
      ...
      int_type c;
      typedef ctype&lt;charT&gt; ctype_type;
      const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
      while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
        if (ctype.is(ctype.space,c)==0) {
          is.rdbuf()-&gt;sputbackc (c);
          break;
        }
      }
      ...
   }</pre>

<p>fails to demonstrate correct use of the facilities described. In
particular, it fails to use traits operators, and specifies incorrect
semantics. (E.g. it specifies skipping over the first character in the
sequence without examining it.) </p>


<p><b>Proposed resolution:</b></p>
<p>Remove the example above from 27.7.1.1.3 [istream::sentry]
paragraph 6.</p>


<p><b>Rationale:</b></p>
<p>The originally proposed replacement code for the example was not
correct. The LWG tried in Kona and again in Tokyo to correct it
without success. In Tokyo, an implementor reported that actual working
code ran over one page in length and was quite complicated. The LWG
decided that it would be counter-productive to include such a lengthy
example, which might well still contain errors.</p>





<hr>
<h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3>
<p><b>Section:</b> 21.4.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The string::erase(iterator first, iterator last) is specified to return an element one
place beyond the next element after the last one erased. E.g. for the string
"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
while 'd' has not been erased. </p>


<p><b>Proposed resolution:</b></p>
<p>In 21.4.6.5 [string::erase], paragraph 10, change: </p>

<blockquote>
  <p>Returns: an iterator which points to the element immediately following _last_ prior to
  the element being erased. </p>
</blockquote>

<p>to read </p>

<blockquote>
  <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
  other elements being erased. </p>
</blockquote>





<hr>
<h3><a name="28"></a>28. Ctype&lt;char&gt;is ambiguous</h3>
<p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p>
<p><b>Discussion:</b></p>
<p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
something very different from what was intended. Paragraph 4 says </p>

<blockquote>
  <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
  table()[(unsigned char)*p]. </p>
</blockquote>

<p>This is intended to copy the value indexed from table()[] into the place identified in
vec[]. </p>


<p><b>Proposed resolution:</b></p>
<p>Change 22.4.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>

<blockquote>
  <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
  the value table()[(unsigned char)*p]. </p>
</blockquote>





<hr>
<h3><a name="29"></a>29. Ios_base::init doesn't exist</h3>
<p><b>Section:</b> 27.4.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Sections 27.4.1 [narrow.stream.objects] and 27.4.2 [wide.stream.objects] mention
a function ios_base::init, which is not defined. Probably they mean
basic_ios&lt;&gt;::init, defined in 27.5.4.1 [basic.ios.cons],
paragraph 3. </p>


<p><b>Proposed resolution:</b></p>
<p>[R12: modified to include paragraph 5.]</p>

<p>In 27.4.1 [narrow.stream.objects] paragraph 2 and 5, change </p>

<blockquote>
  <p>ios_base::init </p>
</blockquote>

<p>to </p>

<blockquote>
  <p>basic_ios&lt;char&gt;::init </p>
</blockquote>

<p>Also, make a similar change in 27.4.2 [wide.stream.objects] except it
should read </p>

<blockquote>
  <p>basic_ios&lt;wchar_t&gt;::init </p>
</blockquote>





<hr>
<h3><a name="30"></a>30. Wrong header for LC_*</h3>
<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.3.1.1.1 [locale.category], paragraph 2, change
"&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>





<hr>
<h3><a name="31"></a>31. Immutable locale values</h3>
<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p>
<p><b>Discussion:</b></p>
<p>Paragraph 6, says "An instance of <tt>locale</tt> is
<i>immutable</i>; once a facet reference is obtained from it,
...". This has caused some confusion, because locale variables
are manifestly assignable. </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.3.1 [locale] replace paragraph 6</p>

<blockquote>
  <p>An instance of <tt>locale</tt> is immutable; once a facet
  reference is obtained from it, that reference remains usable as long
  as the locale value itself exists.</p>
</blockquote>

<p>with</p>

<blockquote>
  <p>Once a facet reference is obtained from a locale object by
  calling use_facet&lt;&gt;, that reference remains usable, and the
  results from member functions of it may be cached and re-used, as
  long as some locale object refers to that facet.</p>
</blockquote>





<hr>
<h3><a name="32"></a>32. Pbackfail description inconsistent</h3>
<p><b>Section:</b> 27.6.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of the required state before calling virtual member
basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
Specifically, the latter says it calls pbackfail if: </p>

<p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>

<p>where pbackfail claims to require: </p>

<p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>

<p>It appears that the pbackfail description is wrong. </p>


<p><b>Proposed resolution:</b></p>
<p>In 27.6.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>

<blockquote>
  <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
</blockquote>

<p>to </p>

<blockquote>
  <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
  </p>
</blockquote>


<p><b>Rationale:</b></p>
<p>Note deliberate reordering of arguments for clarity in addition to the correction of
the argument value.</p>





<hr>
<h3><a name="33"></a>33. Codecvt&lt;&gt; mentions from_type</h3>
<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p>
<p><b>Discussion:</b></p>
<p>In the table defining the results from do_out and do_in, the specification for the
result <i>error</i> says </p>

<blockquote>
  <p>encountered a from_type character it could not convert </p>
</blockquote>

<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
an internT for do_out. </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
in the table for the case of _error_ with </p>

<blockquote>
  <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
</blockquote>





<hr>
<h3><a name="34"></a>34. True/falsename() not in ctype&lt;&gt;</h3>
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
22.2.2.1.2, addressed in (4). </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
clause for member put(...., bool), replace the initialization of the
string_type value s as follows: </p>

<blockquote>
  <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
string_type s = val ? np.truename() : np.falsename(); </pre>
</blockquote>





<hr>
<h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3>
<p><b>Section:</b> 27.5 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostreams.base">issues</a> in [iostreams.base].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 27.5.5.1 [fmtflags.manip], we have a definition for a manipulator
named "unitbuf". Unlike other manipulators, it's not listed
in synopsis. Similarly for "nounitbuf". </p>


<p><b>Proposed resolution:</b></p>
<p>Add to the synopsis for &lt;ios&gt; in 27.5 [iostreams.base], after
the entry for "nouppercase", the prototypes: </p>

<blockquote>
  <pre>ios_base&amp; unitbuf(ios_base&amp; str);
ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
</blockquote>





<hr>
<h3><a name="36"></a>36. Iword &amp; pword storage lifetime omitted</h3>
<p><b>Section:</b> 27.5.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
specified badly, so that an implementation which only keeps the last value stored appears
to conform. In particular, it says: </p>

<p>The reference returned may become invalid after another call to the object's iword
member with a different index ... </p>

<p>This is not idle speculation; at least one implementation was done this way. </p>


<p><b>Proposed resolution:</b></p>
<p>Add in 27.5.2.5 [ios.base.storage], in both paragraph 2 and also in
paragraph 4, replace the sentence: </p>

<blockquote>
  <p>The reference returned may become invalid after another call to the object's iword
  [pword] member with a different index, after a call to its copyfmt member, or when the
  object is destroyed. </p>
</blockquote>

<p>with: </p>

<blockquote>
  <p>The reference returned is invalid after any other operations on the object. However,
  the value of the storage referred to is retained, so that until the next call to copyfmt,
  calling iword [pword] with the same index yields another reference to the same value. </p>
</blockquote>

<p>substituting "iword" or "pword" as appropriate. </p>





<hr>
<h3><a name="37"></a>37. Leftover "global" reference</h3>
<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the overview of locale semantics, paragraph 4, is the sentence </p>

<blockquote>
  <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
  the standard exception bad_cast. </p>
</blockquote>

<p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
from an old draft. </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.3.1 [locale], paragraph 4, delete the parenthesized
expression </p>

<blockquote>
  <p>(or, failing that, in the global locale) </p>
</blockquote>





<hr>
<h3><a name="38"></a>38. Facet definition incomplete</h3>
<p><b>Section:</b> 22.3.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It has been noticed by Esa Pulkkinen that the definition of
"facet" is incomplete. In particular, a class derived from
another facet, but which does not define a member <i>id</i>, cannot
safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
because there is no guarantee that a reference to the facet instance
stored in <i>loc</i> is safely convertible to <i>F</i>. </p>


<p><b>Proposed resolution:</b></p>
<p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
reads: </p>

<blockquote>
  <p>Get a reference to a facet of a locale. </p>
</blockquote>

<p>with: </p>

<blockquote>
  <p>Requires: <tt>Facet</tt> is a facet class whose definition
  contains the public static member <tt>id</tt> as defined in 22.3.1.1.2 [locale.facet]. </p>
</blockquote>

<p><i>[
Kona: strike as overspecification the text "(not inherits)"
from the original resolution, which read "... whose definition
contains (not inherits) the public static member
<tt>id</tt>..."
]</i></p>







<hr>
<h3><a name="39"></a>39. istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3>
<p><b>Section:</b> 24.6.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
3, the standard contains three lines of garbage text left over from a previous edit. </p>

<blockquote>
  <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
sbuf_-&gt;sbumpc();
return(tmp); </pre>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>In 24.6.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
end of paragraph 3. </p>





<hr>
<h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3>
<p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 3 of the locale examples is a description of part of an
implementation technique that has lost its referent, and doesn't mean
anything. </p>


<p><b>Proposed resolution:</b></p>
<p>Delete 22.4.8 [facets.examples] paragraph 3 which begins "This
initialization/identification system depends...", or (at the
editor's option) replace it with a place-holder to keep the paragraph
numbering the same. </p>





<hr>
<h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3>
<p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p>
<p><b>Discussion:</b></p>
<p>The description of ios_base::iword() and pword() in 27.5.2.4 [ios.members.static], say that if they fail, they "set badbit,
which may throw an exception". However, ios_base offers no
interface to set or to test badbit; those interfaces are defined in
basic_ios&lt;&gt;. </p>


<p><b>Proposed resolution:</b></p>
<p>Change the description in 27.5.2.5 [ios.base.storage] in
paragraph 2, and also in paragraph 4, as follows. Replace</p>

<blockquote>
  <p>If the function fails it sets badbit, which may throw an exception.</p>
</blockquote>

<p>with</p>

<blockquote>
  <p>If the function fails, and <tt>*this</tt> is a base sub-object of
  a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
  equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
  on the derived object (which may throw <tt>failure</tt>).</p>
</blockquote>

<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
setstate(badbit).]</i></p>







<hr>
<h3><a name="42"></a>42. String ctors specify wrong default allocator</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The basic_string&lt;&gt; copy constructor: </p>

<pre>basic_string(const basic_string&amp; str, size_type pos = 0,
             size_type n = npos, const Allocator&amp; a = Allocator()); </pre>

<p>specifies an Allocator argument default value that is
counter-intuitive. The natural choice for a the allocator to copy from
is str.get_allocator(). Though this cannot be expressed in
default-argument notation, overloading suffices. </p>

<p>Alternatively, the other containers in Clause 23 (deque, list,
vector) do not have this form of constructor, so it is inconsistent,
and an evident source of confusion, for basic_string&lt;&gt; to have
it, so it might better be removed. </p>


<p><b>Proposed resolution:</b></p>
<p> In 21.4 [basic.string], replace the declaration of the copy
constructor as follows: </p>

<blockquote>
  <pre>basic_string(const basic_string&amp; str);
basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
             const Allocator&amp; a = Allocator());</pre>
</blockquote>

<p>In 21.4.1 [string.require], replace the copy constructor declaration
as above. Add to paragraph 5, Effects:</p>

<blockquote>
  <p>In the first form, the Allocator value used is copied from
  <tt>str.get_allocator()</tt>.</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>The LWG believes the constructor is actually broken, rather than
just an unfortunate design choice.</p>

<p>The LWG considered two other possible resolutions:</p>

<p>A. In 21.4 [basic.string], replace the declaration of the copy
constructor as follows:</p>

<blockquote>
  <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
             size_type n = npos);
basic_string(const basic_string&amp; str, size_type pos,
             size_type n, const Allocator&amp; a); </pre>
</blockquote>

<p>In 21.4.1 [string.require], replace the copy constructor declaration
as above. Add to paragraph 5, Effects: </p>

<blockquote>
  <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
  value <tt>str.get_allocator()</tt>. </p>
</blockquote>

<p>B. In 21.4 [basic.string], and also in 21.4.1 [string.require], replace
the declaration of the copy constructor as follows: </p>

<blockquote>
  <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
             size_type n = npos); </pre>
</blockquote>

<p>The proposed resolution reflects the original intent of the LWG. It
was also noted by Pete Becker that this fix "will cause
a small amount of existing code to now work correctly."</p>

<p><i>[
Kona: issue editing snafu fixed - the proposed resolution now correctly
reflects the LWG consensus.
]</i></p>






<hr>
<h3><a name="44"></a>44. Iostreams use operator== on int_type values</h3>
<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Many of the specifications for iostreams specify that character
values or their int_type equivalents are compared using operators ==
or !=, though in other places traits::eq() or traits::eq_int_type is
specified to be used throughout. This is an inconsistency; we should
change uses of == and != to use the traits members instead. </p>


<p><b>Proposed resolution:</b></p>

<p><i>[Pre-Kona: Dietmar supplied wording]</i></p>


<p>List of changes to clause 27:</p>
<ol>
<li>
   In lib.basic.ios.members paragraph 13 (postcondition clause for
   'fill(cT)') change

<blockquote><pre>     fillch == fill()
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(fillch, fill())
</pre></blockquote>


</li>
<li>
   In lib.istream.unformatted paragraph 7 (effects clause for
   'get(cT,streamsize,cT)'), third bullet, change

<blockquote><pre>     c == delim for the next available input character c
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(c, delim) for the next available input character c
</pre></blockquote>

</li>
<li>
   In lib.istream.unformatted paragraph 12 (effects clause for
   'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change

<blockquote><pre>     c == delim for the next available input character c
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(c, delim) for the next available input character c
</pre></blockquote>

</li>
<li>
   In lib.istream.unformatted paragraph 17 (effects clause for
   'getline(cT,streamsize,cT)'), second bullet, change

<blockquote><pre>     c == delim for the next available input character c
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(c, delim) for the next available input character c
  </pre></blockquote>

</li>
<li>
   In lib.istream.unformatted paragraph 24 (effects clause for
   'ignore(int,int_type)'), second bullet, change

<blockquote><pre>     c == delim for the next available input character c
</pre></blockquote>

   to

<blockquote><pre>     traits::eq_int_type(c, delim) for the next available input
     character c
</pre></blockquote>
  
</li>
<li>
   In lib.istream.unformatted paragraph 25 (notes clause for
   'ignore(int,int_type)'), second bullet, change

<blockquote><pre>     The last condition will never occur if delim == traits::eof()
</pre></blockquote>

   to

<blockquote><pre>     The last condition will never occur if
     traits::eq_int_type(delim, traits::eof()).
</pre></blockquote>

</li>
<li>
   In lib.istream.sentry paragraph 6 (example implementation for the
   sentry constructor) change

<blockquote><pre>     while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
</pre></blockquote>

   to

<blockquote><pre>     while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
</pre></blockquote>

</li>
</ol>

<p>List of changes to Chapter 21:</p>

<ol>
<li>
   In lib.string::find paragraph 1 (effects clause for find()),
   second bullet, change

<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
</pre></blockquote>

</li>
<li>
   In lib.string::rfind paragraph 1 (effects clause for rfind()),
   second bullet, change

<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
</pre></blockquote>

</li>
<li>
   In lib.string::find.first.of paragraph 1 (effects clause for
   find_first_of()), second bullet, change

<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
</pre></blockquote>

</li>
<li>
   In lib.string::find.last.of paragraph 1 (effects clause for
   find_last_of()), second bullet, change

<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
</pre></blockquote>

</li>
<li>
   In lib.string::find.first.not.of paragraph 1 (effects clause for
   find_first_not_of()), second bullet, change

<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
</pre></blockquote>
</li>

<li>
   In lib.string::find.last.not.of paragraph 1 (effects clause for
   find_last_not_of()), second bullet, change

<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
</pre></blockquote>
</li>

<li>
   In lib.string.ios paragraph 5 (effects clause for getline()),
   second bullet, change

<blockquote><pre>     c == delim for the next available input character c 
</pre></blockquote>

   to

<blockquote><pre>     traits::eq(c, delim) for the next available input character c 
</pre></blockquote>
</li>

</ol>

<p>Notes:</p>
<ul>
<li>
  Fixing this issue highlights another sloppyness in
  lib.istream.unformatted paragraph 24: this clause mentions a "character"
  which is then compared to an 'int_type' (see item 5. in the list
  below). It is not clear whether this requires explicit words and
  if so what these words are supposed to be. A similar issue exists,
  BTW, for operator*() of istreambuf_iterator which returns the result
  of sgetc() as a character type (see lib.istreambuf.iterator::op*
  paragraph 1), and for operator++() of istreambuf_iterator which
  passes the result of sbumpc() to a constructor taking a char_type
  (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
  assignment operator ostreambuf_iterator passes a char_type to a function
  taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
</li>
<li>
  It is inconsistent to use comparisons using the traits functions in
  Chapter 27 while not using them in Chapter 21, especially as some
  of the inconsistent uses actually involve streams (eg. getline() on
  streams). To avoid leaving this issue open still longer due to this
  inconsistency (it is open since 1998), a list of changes to Chapter
  21 is below.
</li>
<li>
  In Chapter 24 there are several places with statements like "the end
  of stream is reached (streambuf_type::sgetc() returns traits::eof())"
  (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
  paragraph 5). It is unclear whether these should be clarified to use
  traits::eq_int_type() for detecting traits::eof().
</li>
</ul>






<hr>
<h3><a name="46"></a>46. Minor Annex D errors</h3>
<p><b>Section:</b> D.9 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p>

<p><b>Proposed resolution:</b></p>
<p>Change D.9.1 [depr.strstreambuf] (since streambuf is a typedef of
basic_streambuf&lt;char&gt;) from:</p>

<pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>

<p>to:</p>

<pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>

<p>In D.9.4 [depr.strstream] insert the semicolon now missing after
int_type:</p>

<pre>     namespace std {
       class strstream
         : public basic_iostream&lt;char&gt; {
       public:
         // Types
         typedef char                                char_type;
         typedef typename char_traits&lt;char&gt;::int_type int_type
         typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>





<hr>
<h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3>
<p><b>Section:</b> 27.5.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
section has two RETURNS clauses, and they make no sense as
stated. They make perfect sense, though, if you swap them. Am I
correct in thinking that paragraphs 2 and 4 just got mixed up by
accident?</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.5.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>





<hr>
<h3><a name="48"></a>48. Use of non-existent exception constructor</h3>
<p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
base class, exception, with exception(msg). Class exception (see
18.6.1) has no such constructor.</p>


<p><b>Proposed resolution:</b></p>
<p>Replace 27.5.2.1.1 [ios::failure], paragraph 2, with</p>

<blockquote>
  <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
</blockquote>





<hr>
<h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3>
<p><b>Section:</b> 27.5.2.4 [ios.members.static] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Two problems</p>

<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
returns. Does it return f, or does it return the previous
synchronization state? My guess is the latter, but the standard
doesn't say so.</p>

<p>(2) 27.4.2.4 doesn't say what it means for streams to be
synchronized with stdio.  Again, of course, I can make some
guesses. (And I'm unhappy about the performance implications of those
guesses, but that's another matter.)</p>


<p><b>Proposed resolution:</b></p>
<p>Change the following sentence in 27.5.2.4 [ios.members.static]
returns clause from:</p>

<blockquote>
  <p><tt>true</tt> if the standard iostream objects (27.3) are
  synchronized and otherwise returns <tt>false</tt>.</p>
</blockquote>

<p>to:</p>

<blockquote>
  <p><tt>true</tt> if the previous state of the standard iostream
  objects (27.3) was synchronized and otherwise returns
  <tt>false</tt>.</p>
</blockquote>

<p>Add the following immediately after 27.5.2.4 [ios.members.static],
paragraph 2:</p>

<blockquote>
<p>When a standard iostream object str is <i>synchronized</i> with a
standard stdio stream f, the effect of inserting a character c by</p>
<pre>  fputc(f, c);
</pre>

<p>is the same as the effect of</p>
<pre>  str.rdbuf()-&gt;sputc(c);
</pre>

<p>for any sequence of characters; the effect of extracting a
character c by</p>
<pre>  c = fgetc(f);
</pre>

<p>is the same as the effect of:</p>
<pre>  c = str.rdbuf()-&gt;sbumpc(c);
</pre>

<p>for any sequences of characters; and the effect of pushing
back a character c by</p>
<pre>  ungetc(c, f);
</pre>

<p>is the same as the effect of</p>
<pre>  str.rdbuf()-&gt;sputbackc(c);
</pre>

<p>for any sequence of characters.  [<i>Footnote</i>: This implies
that operations on a standard iostream object can be mixed arbitrarily
with operations on the corresponding stdio stream.  In practical
terms, synchronization usually means that a standard iostream object
and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
</blockquote>

<p><i>[pre-Copenhagen: PJP and Matt contributed the definition
of "synchronization"]</i></p>


<p><i>[post-Copenhagen: proposed resolution was revised slightly:
text was added in the non-normative footnote to say that operations
on the two streams can be mixed arbitrarily.]</i></p>






<hr>
<h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3>
<p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>As written, ios_base has a copy constructor and an assignment
operator. (Nothing in the standard says it doesn't have one, and all
classes have copy constructors and assignment operators unless you
take specific steps to avoid them.) However, nothing in 27.4.2 says
what the copy constructor and assignment operator do. </p>

<p>My guess is that this was an oversight, that ios_base is, like
basic_ios, not supposed to have a copy constructor or an assignment
operator.</p>

<p>
Jerry Schwarz comments: Yes, its an oversight, but in the opposite
sense to what you're suggesting. At one point there was a definite
intention that you could copy ios_base. It's an easy way to save the
entire state of a stream for future use. As you note, to carry out
that intention would have required a explicit description of the
semantics (e.g. what happens to the iarray and parray stuff).
</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.5.2 [ios.base], class ios_base, specify the copy
constructor and operator= members as being private.</p>


<p><b>Rationale:</b></p>
<p>The LWG believes the difficulty of specifying correct semantics
outweighs any benefit of allowing ios_base objects to be copyable.</p>





<hr>
<h3><a name="51"></a>51. Requirement to not invalidate iterators missing</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> David Vandevoorde <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The std::sort algorithm can in general only sort a given sequence
by moving around values. The list&lt;&gt;::sort() member on the other
hand could move around values or just update internal pointers. Either
method can leave iterators into the list&lt;&gt; dereferencable, but
they would point to different things. </p>

<p>Does the FDIS mandate anywhere which method should be used for
list&lt;&gt;::sort()?</p>

<p>Matt Austern comments:</p>

<p>I think you've found an omission in the standard. </p>

<p>The library working group discussed this point, and there was
supposed to be a general requirement saying that list, set, map,
multiset, and multimap may not invalidate iterators, or change the
values that iterators point to, except when an operation does it
explicitly. So, for example, insert() doesn't invalidate any iterators
and erase() and remove() only invalidate iterators pointing to the
elements that are being erased. </p>

<p>I looked for that general requirement in the FDIS, and, while I
found a limited form of it for the sorted associative containers, I
didn't find it for list. It looks like it just got omitted. </p>

<p>The intention, though, is that list&lt;&gt;::sort does not
invalidate any iterators and does not change the values that any
iterator points to. There would be no reason to have the member
function otherwise.</p>


<p><b>Proposed resolution:</b></p>
<p>Add a new paragraph at the end of 23.1:</p>

<blockquote>
  <p>Unless otherwise specified (either explicitly or by defining a function in terms of
  other functions), invoking a container member function or passing a container as an
  argument to a library function shall not invalidate iterators to, or change the values of,
  objects within that container. </p>
</blockquote>


<p><b>Rationale:</b></p>
<p>This was US issue CD2-23-011; it was accepted in London but the
change was not made due to an editing oversight. The wording in the
proposed resolution below is somewhat updated from CD2-23-011,
particularly the addition of the phrase "or change the values
of"</p>





<hr>
<h3><a name="52"></a>52. Small I/O problems</h3>
<p><b>Section:</b> 27.5.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos.operations">issues</a> in [fpos.operations].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>First, 27.5.4.1 [basic.ios.cons], table 89. This is pretty obvious:
it should be titled "basic_ios&lt;&gt;() effects", not
"ios_base() effects". </p>

<p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for
resolution.]</p>

<p>Second, 27.5.3.2 [fpos.operations] table 88 . There are a couple
different things wrong with it, some of which I've already discussed
with Jerry, but the most obvious mechanical sort of error is that it
uses expressions like P(i) and p(i), without ever defining what sort
of thing "i" is.
</p>

<p>(The other problem is that it requires support for streampos
arithmetic. This is impossible on some systems, i.e. ones where file
position is a complicated structure rather than just a number. Jerry
tells me that the intention was to require syntactic support for
streampos arithmetic, but that it wasn't actually supposed to do
anything meaningful except on platforms, like Unix, where genuine
arithmetic is possible.) </p>


<p><b>Proposed resolution:</b></p>
<p>Change 27.5.4.1 [basic.ios.cons] table 89 title from
"ios_base() effects" to "basic_ios&lt;&gt;()
effects". </p>





<hr>
<h3><a name="53"></a>53. Basic_ios destructor unspecified</h3>
<p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
The important question is whether basic_ios::~basic_ios() destroys
rdbuf().</p>


<p><b>Proposed resolution:</b></p>
<p>Add after 27.5.4.1 [basic.ios.cons] paragraph 2:</p>

<blockquote>
  <p><tt>virtual ~basic_ios();</tt></p>
  <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
</blockquote>


<p><b>Rationale:</b></p> 
<p>The LWG reviewed the additional question of whether or not
<tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
clearly yes; it may be set via <tt>clear()</tt>.  See 27.5.4.2 [basic.ios.members], paragraph 6.  This issue was reviewed at length
by the LWG, which removed from the original proposed resolution a
footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
<tt>badbit</tt>".</p>





<hr>
<h3><a name="54"></a>54. Basic_streambuf's destructor</h3>
<p><b>Section:</b> 27.6.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The class synopsis for basic_streambuf shows a (virtual)
destructor, but the standard doesn't say what that destructor does. My
assumption is that it does nothing, but the standard should say so
explicitly. </p>


<p><b>Proposed resolution:</b></p>
<p>Add after 27.6.2.1 [streambuf.cons] paragraph 2:</p>

<blockquote>
  <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
  <p><b>Effects</b>: None.</p>
</blockquote>





<hr>
<h3><a name="55"></a>55. Invalid stream position is undefined</h3>
<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Several member functions in clause 27 are defined in certain
circumstances to return an "invalid stream position", a term
that is defined nowhere in the standard. Two places (27.5.2.4.2,
paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
a definition in _lib.iostreams.definitions_, a nonexistent
section. </p>

<p>I suspect that the invalid stream position is just supposed to be
pos_type(-1).  Probably best to say explicitly in (for example)
27.5.2.4.2 that the return value is pos_type(-1), rather than to use
the term "invalid stream position", define that term
somewhere, and then put in a cross-reference. </p>

<p>The phrase "invalid stream position" appears ten times in
the C++ Standard.  In seven places it refers to a return value, and it
should be changed. In three places it refers to an argument, and it
should not be changed. Here are the three places where "invalid
stream position" should not be changed:</p>

<blockquote>
  <p>27.8.1.4 [stringbuf.virtuals], paragraph 14<br>
  27.9.1.5 [filebuf.virtuals], paragraph 14<br>
  D.9.1.3 [depr.strstreambuf.virtuals], paragraph 17
  </p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
object of class pos_type that stores an invalid stream position
(_lib.iostreams.definitions_)" to "Returns
<tt>pos_type(off_type(-1))</tt>".
</p>

<p>In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
an object of class pos_type that stores an invalid stream
position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>

<p>In 27.8.1.4 [stringbuf.virtuals], paragraph 13, change "the object
stores an invalid stream position" to "the return value is
<tt>pos_type(off_type(-1))</tt>". </p>

<p>In 27.9.1.5 [filebuf.virtuals], paragraph 13, change "returns an
invalid stream position (27.4.3)" to "returns
<tt>pos_type(off_type(-1))</tt>" </p>

<p>In 27.9.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
returns an invalid stream position (_lib.iostreams.definitions_)"
to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
</p>

<p>In D.9.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object
stores an invalid stream position" to "the return value is
<tt>pos_type(off_type(-1))</tt>" </p>

<p>In D.9.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object
stores an invalid stream position" to "the return value is
<tt>pos_type(off_type(-1))</tt>"</p>





<hr>
<h3><a name="56"></a>56. Showmanyc's return type</h3>
<p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
showmanyc has return type int. However, 27.5.2.4.3 says that its
return type is streamsize. </p>


<p><b>Proposed resolution:</b></p>
<p>Change <tt>showmanyc</tt>'s return type in the
27.6.2 [streambuf] class summary to <tt>streamsize</tt>.</p>





<hr>
<h3><a name="57"></a>57. Mistake in char_traits</h3>
<p><b>Section:</b> 21.2.3.4 [char.traits.specializations.wchar.t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>21.1.3.2, paragraph 3, says "The types streampos and
wstreampos may be different if the implementation supports no shift
encoding in narrow-oriented iostreams but supports one or more shift
encodings in wide-oriented streams". </p>

<p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
in 27.2 says that streampos and wstreampos are, respectively, synonyms
for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
char_traits&lt;char&gt;::state_type and
char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>


<p><b>Proposed resolution:</b></p>
<p>Remove the sentence in 21.2.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
begins "The types streampos and wstreampos may be
different..." . </p>





<hr>
<h3><a name="59"></a>59. Ambiguity in specification of gbump</h3>
<p><b>Section:</b> 27.6.2.3.2 [streambuf.get.area] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
next pointer for the input sequence by n." </p>

<p>The straightforward interpretation is that it is just gptr() +=
n. An alternative interpretation, though, is that it behaves as if it
calls sbumpc n times. (The issue, of course, is whether it might ever
call underflow.) There is a similar ambiguity in the case of
pbump. </p>

<p>(The "classic" AT&amp;T implementation used the
former interpretation.)</p>


<p><b>Proposed resolution:</b></p>
<p>Change 27.6.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>

<blockquote>
  <p>Effects: Advances the next pointer for the input sequence by n.</p>
</blockquote>

<p>to:</p>

<blockquote>
  <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
</blockquote>

<p>Make the same change to 27.6.2.3.3 [streambuf.put.area] paragraph 4 pbump
effects.</p>





<hr>
<h3><a name="60"></a>60. What is a formatted input function?</h3>
<p><b>Section:</b> 27.7.1.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#163">163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a></p>
<p><b>Discussion:</b></p>
<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
formatted input functions. Some of the functions defined in section
27.6.1.2 explicitly say that those requirements apply ("Behaves
like a formatted input member (as described in 27.6.1.2.1)"), but
others don't. The question: is 27.6.1.2.1 supposed to apply to
everything in 27.6.1.2, or only to those member functions that
explicitly say "behaves like a formatted input member"? Or
to put it differently: are we to assume that everything that appears
in a section called "Formatted input functions" really is a
formatted input function? I assume that 27.6.1.2.1 is intended to
apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
is not intended to apply to extractors like </p>

<pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>

<p>and </p>

<pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>

<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
output. </p>

<p>Comments from Judy Ward: It seems like the problem is that the
basic_istream and basic_ostream operator &lt;&lt;()'s that are used
for the manipulators and streambuf* are in the wrong section and
should have their own separate section or be modified to make it clear
that the "Common requirements" listed in section 27.6.1.2.1
(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
apply to them. </p>

<p>Additional comments from Dietmar K�hl: It appears to be somewhat
nonsensical to consider the functions defined in 27.7.1.2.3 [istream::extractors] paragraphs 1 to 5 to be "Formatted input
function" but since these functions are defined in a section
labeled "Formatted input functions" it is unclear to me
whether these operators are considered formatted input functions which
have to conform to the "common requirements" from 27.7.1.2.1 [istream.formatted.reqmts]: If this is the case, all manipulators, not
just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
set (... but setting <tt>noskipws</tt> using the manipulator syntax
would also skip whitespace :-)</p> <p>It is not clear which functions
are to be considered unformatted input functions. As written, it seems
that all functions in 27.7.1.3 [istream.unformatted] are unformatted input
functions. However, it does not really make much sense to construct a
sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
unclear what happens to the <tt>gcount()</tt> if
eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
<tt>sync()</tt> is called: These functions don't extract characters,
some of them even "unextract" a character. Should this still
be reflected in <tt>gcount()</tt>? Of course, it could be read as if
after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
(the last unformatted input function, <tt>gcount()</tt>, didn't
extract any character) and after a call to <tt>putback()</tt>
<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
function <tt>putback()</tt> did "extract" back into the
stream). Correspondingly for <tt>unget()</tt>. Is this what is
intended?  If so, this should be clarified. Otherwise, a corresponding
clarification should be used.</p>


<p><b>Proposed resolution:</b></p>
<p>
In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
Change the beginning of the second sentence from "The conversion
occurs" to "These extractors behave as formatted input functions (as
described in 27.6.1.2.1).  After a sentry object is constructed,
the conversion occurs"
</p>

<p>
In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
Add an effects clause.  "Effects: None.  This extractor does
not behave as a formatted input function (as described in
27.6.1.2.1).
</p>

<p>
In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
effects clause to "Effects: Calls pf(*this).  This extractor does not
behave as a formatted input function (as described in 27.6.1.2.1).
</p>

<p>
In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
effects clause to "Effects: Calls pf(*this).  This extractor does not
behave as a formatted input function (as described in 27.6.1.2.1).
</p>

<p>
In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
first two sentences from "If sb is null, calls setstate(failbit),
which may throw ios_base::failure (27.4.4.3).  Extracts characters
from *this..." to "Behaves as a formatted input function (as described
in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
throw ios_base::failure (27.4.4.3).  After a sentry object is
constructed, extracts characters from *this...".
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
effects clause.  "Effects: none. This member function does not behave
as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
beginning of the first sentence of the effects clause from "Extracts a
character" to "Behaves as an unformatted input function (as described
in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
character"
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
beginning of the first sentence of the effects clause from "Extracts a
character" to "Behaves as an unformatted input function (as described
in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
character"
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
beginning of the first sentence of the effects clause from "Extracts
characters" to "Behaves as an unformatted input function (as described
in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
characters"
</p>

<p>
[No change needed in paragraph 10, because it refers to paragraph 7.]
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
beginning of the first sentence of the effects clause from "Extracts
characters" to "Behaves as an unformatted input function (as described
in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
characters"
</p>

<p>
[No change needed in paragraph 15.]
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
beginning of the first sentence of the effects clause from "Extracts
characters" to "Behaves as an unformatted input function (as described
in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
characters"
</p>

<p>
[No change needed in paragraph 23.]
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
beginning of the first sentence of the effects clause from "Extracts
characters" to "Behaves as an unformatted input function (as described
in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
characters"
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
Effects clause: "Effects: Behaves as an unformatted input function (as
described in 27.6.1.3, paragraph 1).  After constructing a sentry
object, reads but does not extract the current input character."
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
first sentence of the Effects clause from "If !good() calls" to
Behaves as an unformatted input function (as described in 27.6.1.3,
paragraph 1).  After constructing a sentry object, if !good() calls"
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
first sentence of the Effects clause from "If !good() calls" to
"Behaves as an unformatted input function (as described in 27.6.1.3,
paragraph 1).  After constructing a sentry object, if !good() calls"
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
first sentence of the Effects clause from "If !good() calls..." to
"Behaves as an unformatted input function (as described in 27.6.1.3,
paragraph 1).  After constructing a sentry object, if !good()
calls..."  Add a new sentence to the end of the Effects clause:
"[Note: this function extracts no characters, so the value returned
by the next call to gcount() is 0.]"
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
first sentence of the Effects clause from "If !good() calls" to
"Behaves as an unformatted input function (as described in 27.6.1.3,
paragraph 1).  After constructing a sentry object, if !good() calls".
Add a new sentence to the end of the Effects clause: "[Note: this
function extracts no characters, so the value returned by the next
call to gcount() is 0.]"
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
as an unformatted input function (as described in 27.6.1.3, paragraph
1), except that it does not count the number of characters extracted
and does not affect the value returned by subsequent calls to
gcount().  After constructing a sentry object, if rdbuf() is"
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
Effects clause: "Effects: Behaves as an unformatted input function (as
described in 27.6.1.3, paragraph 1), except that it does not count the
number of characters extracted and does not affect the value returned
by subsequent calls to gcount()."  Change the first sentence of
paragraph 37 from "if fail()" to "after constructing a sentry object,
if fail()".
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
first sentence of the Effects clause from "If fail()" to "Behaves
as an unformatted input function (as described in 27.6.1.3, paragraph
1), except that it does not count the number of characters extracted
and does not affect the value returned by subsequent calls to
gcount().  After constructing a sentry object, if fail()
</p>

<p>
In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
first sentence of the Effects clause from "If fail()" to "Behaves
as an unformatted input function (as described in 27.6.1.3, paragraph
1), except that it does not count the number of characters extracted
and does not affect the value returned by subsequent calls to
gcount().  After constructing a sentry object, if fail()
</p>

<p>
In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
the beginning of the third sentence from "The formatting conversion"
to "These extractors behave as formatted output functions (as
described in 27.6.2.5.1).  After the sentry object is constructed, the
conversion occurs".
</p>

<p>
In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
effects clause: "Effects: None. Does not behave as a formatted output
function (as described in 27.6.2.5.1).".
</p>

<p>
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
effects clause to "Effects: calls pf(*this).  This extractor does not
behave as a formatted output function (as described in 27.6.2.5.1).".
</p>

<p>
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
effects clause to "Effects: calls pf(*this).  This extractor does not
behave as a formatted output function (as described in 27.6.2.5.1).".
</p>

<p>
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
sentence from "If sb" to "Behaves as a formatted output function (as
described in 27.6.2.5.1).  After the sentry object is constructed, if
sb".
</p>

<p>
In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
sentence from "Inserts the character" to "Behaves as an unformatted
output function (as described in 27.6.2.6, paragraph 1).  After
constructing a sentry object, inserts the character".
</p>

<p>
In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
sentence from "Obtains characters" to "Behaves as an unformatted
output function (as described in 27.6.2.6, paragraph 1).  After
constructing a sentry object, obtains characters".
</p>

<p>
In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
sentence at the end of the paragraph: "Does not behave as an
unformatted output function (as described in 27.6.2.6, paragraph 1)."
</p>


<p><b>Rationale:</b></p>
<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
by Judy Ward and Matt Austern.  This proposed resolution is section
VI of that paper.</p>





<hr>
<h3><a name="61"></a>61. Ambiguity in iostreams exception policy</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The introduction to the section on unformatted input (27.6.1.3)
says that every unformatted input function catches all exceptions that
were thrown during input, sets badbit, and then conditionally rethrows
the exception. That seems clear enough. Several of the specific
functions, however, such as get() and read(), are documented in some
circumstances as setting eofbit and/or failbit. (The standard notes,
correctly, that setting eofbit or failbit can sometimes result in an
exception being thrown.) The question: if one of these functions
throws an exception triggered by setting failbit, is this an exception
"thrown during input" and hence covered by 27.6.1.3, or does
27.6.1.3 only refer to a limited class of exceptions? Just to make
this concrete, suppose you have the following snippet. </p>

<pre>  
  char buffer[N];
  istream is;
  ...
  is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
  is.read(buffer, N);</pre>

<p>Now suppose we reach EOF before we've read N characters. What
iostate bits can we expect to be set, and what exception (if any) will
be thrown? </p>


<p><b>Proposed resolution:</b></p>
<p>
In 27.6.1.3, paragraph 1, after the sentence that begins
"If an exception is thrown...", add the following
parenthetical comment: "(Exceptions thrown from 
<tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
</p>


<p><b>Rationale:</b></p>
<p>The LWG looked to two alternative wordings, and choose the proposed
resolution as better standardese.</p>





<hr>
<h3><a name="62"></a>62. <tt>Sync</tt>'s return value</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
"calls rdbuf()-&gt;pubsync() and, if that function returns -1
... returns traits::eof()." </p>

<p>That looks suspicious, because traits::eof() is of type
traits::int_type while the return type of sync() is int. </p>


<p><b>Proposed resolution:</b></p>
<p>In 27.7.1.3 [istream.unformatted], paragraph 36, change "returns
<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
</p>





<hr>
<h3><a name="63"></a>63. Exception-handling policy for unformatted output</h3>
<p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Clause 27 details an exception-handling policy for formatted input,
unformatted input, and formatted output. It says nothing for
unformatted output (27.6.2.6). 27.6.2.6 should either include the same
kind of exception-handling policy as in the other three places, or
else it should have a footnote saying that the omission is
deliberate. </p>


<p><b>Proposed resolution:</b></p>
<p>
In 27.6.2.6, paragraph 1, replace the last sentence ("In any
case, the unformatted output function ends by destroying the sentry
object, then returning the value specified for the formatted output
function.") with the following text:
</p>
<blockquote><p>
If an exception is thrown during output, then <tt>ios::badbit</tt> is
turned on [Footnote: without causing an <tt>ios::failure</tt> to be
thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
badbit) != 0</tt> then the exception is rethrown.  In any case, the
unformatted output function ends by destroying the sentry object,
then, if no exception was thrown, returning the value specified for
the formatted output function.
</p></blockquote>


<p><b>Rationale:</b></p>
<p>
This exception-handling policy is consistent with that of formatted
input, unformatted input, and formatted output.
</p>





<hr>
<h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt></h3>
<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
different ways, depending on whether the second sentence is read as an
elaboration of the first. </p>


<p><b>Proposed resolution:</b></p>
<p>Replace 27.7.1.2.3 [istream::extractors], paragraph 13, which begins
"If the function inserts no characters ..." with:</p>

<blockquote>
  <p>If the function inserts no characters, it calls
  <tt>setstate(failbit)</tt>, which may throw
  <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
  because it caught an exception thrown while extracting characters
  from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
  (27.4.4.3), then the caught exception is rethrown. </p>
</blockquote>





<hr>
<h3><a name="66"></a>66. Strstreambuf::setbuf</h3>
<p><b>Section:</b> D.9.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
"Performs an operation that is defined separately for each class
derived from strstreambuf". This is obviously an incorrect
cut-and-paste from basic_streambuf. There are no classes derived from
strstreambuf. </p>


<p><b>Proposed resolution:</b></p>
<p>D.9.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects
clause which currently says "Performs an operation that is
defined separately for each class derived from strstreambuf"
with:</p>

<blockquote>
  <p><b>Effects</b>: implementation defined, except that
  <tt>setbuf(0,0)</tt> has no effect.</p>
</blockquote>





<hr>
<h3><a name="68"></a>68. Extractors for char* should store null at end</h3>
<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-07-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Extractors for char* (27.6.1.2.3) do not store a null character
after the extracted character sequence whereas the unformatted
functions like get() do. Why is this?</p>

<p>Comment from Jerry Schwarz: There is apparently an editing
glitch. You'll notice that the last item of the list of what stops
extraction doesn't make any sense. It was supposed to be the line that
said a null is stored.</p>


<p><b>Proposed resolution:</b></p>
<p>27.7.1.2.3 [istream::extractors], paragraph 7, change the last list
item from:</p>

<blockquote><p>
  A null byte (<tt>charT()</tt>) in the next position, which may be
  the first position if no characters were extracted.
</p></blockquote>

<p>to become a new paragraph which reads:</p>

<blockquote><p>
  Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
  next position, which may be the first position if no characters were
  extracted.
</p></blockquote>





<hr>
<h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3>
<p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1998-07-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>

<p>(Please note that this is entirely separate from the question of
whether a vector iterator is required to be a pointer; the answer to
that question is clearly "no," as it would rule out
debugging implementations)</p>


<p><b>Proposed resolution:</b></p>
<p>Add the following text to the end of 23.4.1 [vector],
paragraph 1. </p>

<blockquote>
  <p>The elements of a vector are stored contiguously, meaning that if
  v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
  other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
  == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>The LWG feels that as a practical matter the answer is clearly
"yes".  There was considerable discussion as to the best way
to express the concept of "contiguous", which is not
directly defined in the standard.  Discussion included:</p>

<ul>
  <li>An operational definition similar to the above proposed resolution is 
    already used for valarray (26.6.2.3 [valarray.access]).</li>
  <li>There is no need to explicitly consider a user-defined operator&amp; 
    because elements must be copyconstructible (23.2 [container.requirements] para 3) 
    and copyconstructible (20.2.1 [utility.arg.requirements]) specifies
    requirements for operator&amp;.</li>
  <li>There is no issue of one-past-the-end because of language rules.</li>
</ul>





<hr>
<h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3>
<p><b>Section:</b> 18.8 [support.exception], 18.8.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-08-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>

<p>uncaught_exception() doesn't have a throw specification.</p>

<p>It is intentional ? Does it means that one should be prepared to
handle exceptions thrown from uncaught_exception() ?</p>

<p>uncaught_exception() is called in exception handling contexts where
exception safety is very important.</p>


<p><b>Proposed resolution:</b></p>
<p>In 15.5.3 [except.uncaught], paragraph 1, 18.8 [support.exception], and 18.8.4 [uncaught], add "throw()" to uncaught_exception().</p>




<hr>
<h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3>
<p><b>Section:</b> 22.4.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
is described in 22.4.5.1.2 [locale.time.get.virtuals] with five arguments,
consistent with do_get_weekday and with its specified use by member
get_monthname. However, in the synopsis, it is specified instead with
four arguments. The missing argument is the "end" iterator
value.</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.5.1 [locale.time.get], add an "end" argument to
the declaration of member do_monthname as follows:</p>

<pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
                                     ios_base::iostate&amp; err, tm* t) const;</pre>




<hr>
<h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></h3>
<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
parentheses and a spurious <b>n</b>.</p>


<p><b>Proposed resolution:</b></p>
<p>Replace 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
following:</p>

<blockquote><p>
  <b>Returns</b>: The maximum value that
  <tt>do_length(state, from, from_end, 1)</tt> can return for any
  valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
  <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
  mbstate_t&gt;::do_max_length()</tt> returns 1.
</p></blockquote>




<hr>
<h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3>
<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b>  Matt
Austern <b>Opened:</b> 1998-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
parameter of the member functions <tt>length</tt> and
<tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
synopsis or the summary must be changed. </p>

<p>If (as I believe) the member function descriptions are correct,
then we must also add text saying how <tt>do_length</tt> changes its
<tt>stateT</tt> argument. </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.1.4 [locale.codecvt], and also in 22.4.1.5 [locale.codecvt.byname],
change the <tt>stateT</tt> argument type on both member
<tt>length()</tt> and member <tt>do_length()</tt> from </p>

<blockquote>
  <p><tt>const stateT&amp;</tt></p>
</blockquote>

<p>to</p>

<blockquote>
  <p><tt>stateT&amp;</tt></p>
</blockquote>

<p>In 22.4.1.4.2 [locale.codecvt.virtuals], add to the definition for member
<tt>do_length</tt> a paragraph:</p>

<blockquote>
  <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
  it called <tt>do_in(state, from, from_end, from, to, to+max,
  to)</tt> for <tt>to</tt> pointing to a buffer of at least
  <tt>max</tt> elements.</p>
</blockquote>




<hr>
<h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3>
<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>This issue concerns the requirements on classes derived from
<tt>codecvt</tt>, including user-defined classes. What are the
restrictions on the conversion from external characters
(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
the I/O library make? </p>

<p>The question is whether it's possible to convert from internal
characters to external characters one internal character at a time,
and whether, given a valid sequence of external characters, it's
possible to pick off internal characters one at a time. Or, to put it
differently: given a sequence of external characters and the
corresponding sequence of internal characters, does a position in the
internal sequence correspond to some position in the external
sequence? </p>

<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
sequence of <i>M</i> external characters and that <tt>[ifirst,
ilast)</tt> is the corresponding sequence of <i>N</i> internal
characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
ilast)</tt>. Now the question: does there necessarily exist a
subsequence of external characters, <tt>[first, last_1)</tt>, such
that the corresponding sequence of internal characters is the single
character <tt>*ifirst</tt>?
</p>

<p>(What a "no" answer would mean is that
<tt>my_encoding</tt> translates sequences only as blocks. There's a
sequence of <i>M</i> external characters that maps to a sequence of
<i>N</i> internal characters, but that external sequence has no
subsequence that maps to <i>N-1</i> internal characters.) </p>

<p>Some of the wording in the standard, such as the description of
<tt>codecvt::do_max_length</tt> (22.4.1.4.2 [locale.codecvt.virtuals],
paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.9.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
possible to pick off internal characters one at a time from a sequence
of external characters. However, this is never explicitly stated one
way or the other. </p>

<p>This issue seems (and is) quite technical, but it is important if
we expect users to provide their own encoding facets. This is an area
where the standard library calls user-supplied code, so a well-defined
set of requirements for the user-supplied code is crucial. Users must
be aware of the assumptions that the library makes. This issue affects
positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
and several of <tt>codecvt</tt>'s member functions. </p>


<p><b>Proposed resolution:</b></p>
<p>Add the following text as a new paragraph, following 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>

<blockquote>
<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
(27.9 [file.streams]) must have the property that if</p>
<pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
</pre>
<p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p>
<pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
</pre>
<p>must also return <tt>ok</tt>, and that if</p>
<pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
</pre>
<p>would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then</p>
<pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
</pre>
<p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
means that <tt>basic_filebuf</tt> assumes that the mapping from
internal to external characters is 1 to N: a <tt>codecvt</tt> that is
used by <tt>basic_filebuf</tt> must be able to translate characters
one internal character at a time.  <i>--End Footnote</i>]</p>
</blockquote>

<p><i>[Redmond: Minor change in proposed resolution.  Original
proposed resolution talked about "success", with a parenthetical
comment that success meant returning <tt>ok</tt>.  New wording
removes all talk about "success", and just talks about the
return value.]</i></p>




<p><b>Rationale:</b></p>

  <p>The proposed resoluion says that conversions can be performed one
  internal character at a time.  This rules out some encodings that
  would otherwise be legal.  The alternative answer would mean there
  would be some internal positions that do not correspond to any
  external file position.</p>
  <p>
  An example of an encoding that this rules out is one where the
  <tt>internT</tt> and <tt>externT</tt> are of the same type, and
  where the internal sequence <tt>c1 c2</tt> corresponds to the
  external sequence <tt>c2 c1</tt>.
  </p>
  <p>It was generally agreed that <tt>basic_filebuf</tt> relies
  on this property: it was designed under the assumption that
  the external-to-internal mapping is N-to-1, and it is not clear
  that <tt>basic_filebuf</tt> is implementable without that 
  restriction.
  </p>
  <p>
  The proposed resolution is expressed as a restriction on
  <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
  than a blanket restriction on all <tt>codecvt</tt> facets,
  because <tt>basic_filebuf</tt> is the only other part of the 
  library that uses <tt>codecvt</tt>.  If a user wants to define
  a <tt>codecvt</tt> facet that implements a more general N-to-M
  mapping, there is no reason to prohibit it, so long as the user
  does not expect <tt>basic_filebuf</tt> to be able to use it.
  </p>





<hr>
<h3><a name="78"></a>78. Typo: event_call_back</h3>
<p><b>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>typo: event_call_back should be event_callback &nbsp; </p>


<p><b>Proposed resolution:</b></p>
<p>In the 27.5.2 [ios.base] synopsis change
"event_call_back" to "event_callback". </p>




<hr>
<h3><a name="79"></a>79. Inconsistent declaration of polar()</h3>
<p><b>Section:</b> 26.4.1 [complex.syn], 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.syn">issues</a> in [complex.syn].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 26.4.1 [complex.syn] polar is declared as follows:</p>
<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>

<p>In 26.4.7 [complex.value.ops] it is declared as follows:</p>
<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>

<p>Thus whether the second parameter is optional is not clear. </p>


<p><b>Proposed resolution:</b></p>
<p>In 26.4.1 [complex.syn] change:</p>
<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>

<p>to:</p>
<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>





<hr>
<h3><a name="80"></a>80. Global Operators of complex declared twice</h3>
<p><b>Section:</b> 26.4.1 [complex.syn], 26.4.2 [complex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.syn">issues</a> in [complex.syn].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
class complex. This redundancy should be removed.</p>


<p><b>Proposed resolution:</b></p>
<p>Reduce redundancy according to the general style of the standard. </p>




<hr>
<h3><a name="83"></a>83. String::npos vs. string::max_size()</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
<p><b>Discussion:</b></p>
<p>Many string member functions throw if size is getting or exceeding
npos. However, I wonder why they don't throw if size is getting or
exceeding max_size() instead of npos.  May be npos is known at compile
time, while max_size() is known at runtime. However, what happens if
size exceeds max_size() but not npos, then? It seems the standard
lacks some clarifications here.</p>


<p><b>Proposed resolution:</b></p>
<p>After 21.4 [basic.string] paragraph 4 ("The functions
described in this clause...") add a new paragraph:</p>

<blockquote>
  <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
  <tt> max_size()</tt> then
  the operation throws <tt>length_error</tt>.</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>The LWG believes length_error is the correct exception to throw.</p>




<hr>
<h3><a name="86"></a>86. String constructors don't describe exceptions</h3>
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The constructor from a range:</p>

<pre>template&lt;class InputIterator&gt; 
         basic_string(InputIterator begin, InputIterator end, 
                      const Allocator&amp; a = Allocator());</pre>

<p>lacks a throws clause. However, I would expect that it throws
according to the other constructors if the numbers of characters in
the range equals npos (or exceeds max_size(), see above). </p>


<p><b>Proposed resolution:</b></p>
<p>In 21.4.1 [string.require], Strike throws paragraphs for
constructors which say "Throws: length_error if n ==
npos."</p>


<p><b>Rationale:</b></p>
<p>Throws clauses for length_error if n == npos are no longer needed
because they are subsumed by the general wording added by the
resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>




<hr>
<h3><a name="90"></a>90. Incorrect description of operator &gt;&gt; for strings</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The effect of operator &gt;&gt; for strings contain the following item:</p>

<p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
character c.</p>

<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>


<p><b>Proposed resolution:</b></p>
<p>In 21.4.8.9 [string.io] paragraph 1 Effects clause replace:</p>

<blockquote>
  <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
</blockquote>

<p>with:</p>

<blockquote>
  <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
</blockquote>





<hr>
<h3><a name="91"></a>91. Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Operator &gt;&gt; and getline() for strings read until eof()
in the input stream is true. However, this might never happen, if the
stream can't read anymore without reaching EOF. So shouldn't it be
changed into that it reads until !good() ? </p>


<p><b>Proposed resolution:</b></p>
<p>In 21.4.8.9 [string.io], paragraph 1, replace:</p>
<blockquote><p>
Effects: Begins by constructing a sentry object k as if k were
constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
bool( k) is true, it calls str.erase() and then extracts characters
from is and appends them to str as if by calling str.append(1, c). If
is.width() is greater than zero, the maximum number n of characters
appended is is.width(); otherwise n is str.max_size(). Characters are
extracted and appended until any of the following occurs:
</p></blockquote>
<p>with:</p>
<blockquote><p>
Effects: Behaves as a formatted input function (27.7.1.2.1 [istream.formatted.reqmts]).  After constructing a sentry object, if the
sentry converts to true, calls str.erase() and then extracts
characters from is and appends them to str as if by calling
str.append(1,c). If is.width() is greater than zero, the maximum
number n of characters appended is is.width(); otherwise n is
str.max_size(). Characters are extracted and appended until any of the
following occurs:
</p></blockquote>

<p>In 21.4.8.9 [string.io], paragraph 6, replace</p>
<blockquote><p>
Effects: Begins by constructing a sentry object k as if by typename
basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
it calls str.erase() and then extracts characters from is and appends
them to str as if by calling str.append(1, c) until any of the
following occurs:
</p></blockquote>
<p>with:</p>
<blockquote><p>
Effects: Behaves as an unformatted input function (27.7.1.3 [istream.unformatted]), except that it does not affect the value returned
by subsequent calls to basic_istream&lt;&gt;::gcount().  After
constructing a sentry object, if the sentry converts to true, calls
str.erase() and then extracts characters from is and appends them to
str as if by calling str.append(1,c) until any of the following
occurs:
</p></blockquote>

<p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
should be a formatted input function, not an unformatted input function.
<tt>getline</tt> should not be required to set <tt>gcount</tt>, since
there is no mechanism for <tt>gcount</tt> to be set except by one of
<tt>basic_istream</tt>'s member functions.]</i></p>


<p><i>[Cura�ao: Nico agrees with proposed resolution.]</i></p>




<p><b>Rationale:</b></p>
<p>The real issue here is whether or not these string input functions
get their characters from a streambuf, rather than by calling an
istream's member functions, a streambuf signals failure either by
returning eof or by throwing an exception; there are no other
possibilities.  The proposed resolution makes it clear that these two
functions do get characters from a streambuf.</p>





<hr>
<h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3>
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The standard does not state, how often a function object is copied,
called, or the order of calls inside an algorithm. This may lead to
surprising/buggy behavior. Consider the following example: </p>

<pre>class Nth {    // function object that returns true for the nth element 
  private: 
    int nth;     // element to return true for 
    int count;   // element counter 
  public: 
    Nth (int n) : nth(n), count(0) { 
    } 
    bool operator() (int) { 
        return ++count == nth; 
    } 
}; 
.... 
// remove third element 
    list&lt;int&gt;::iterator pos; 
    pos = remove_if(coll.begin(),coll.end(),  // range 
                    Nth(3)),                  // remove criterion 
    coll.erase(pos,coll.end()); </pre>

<p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
happens because the usual implementation of the algorithm copies the
function object internally: </p>

<pre>template &lt;class ForwIter, class Predicate&gt; 
ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op) 
{ 
    beg = find_if(beg, end, op); 
    if (beg == end) { 
        return beg; 
    } 
    else { 
        ForwIter next = beg; 
        return remove_copy_if(++next, end, beg, op); 
    } 
} </pre>

<p>The algorithm uses find_if() to find the first element that should
be removed. However, it then uses a copy of the passed function object
to process the resulting elements (if any). Here, Nth is used again
and removes also the sixth element. This behavior compromises the
advantage of function objects being able to have a state. Without any
cost it could be avoided (just implement it directly instead of
calling find_if()). </p>


<p><b>Proposed resolution:</b></p>

<p>Add a new paragraph following 25 [algorithms] paragraph 8:</p>
<blockquote><p>
[Note: Unless otherwise specified, algorithms that take function
objects as arguments are permitted to copy those function objects
freely.  Programmers for whom object identity is important should
consider using a wrapper class that points to a noncopied
implementation object, or some equivalent solution.]
</p></blockquote>

<p><i>[Dublin: Pete Becker felt that this may not be a defect,
but rather something that programmers need to be educated about.
There was discussion of adding wording to the effect that the number
and order of calls to function objects, including predicates, not
affect the behavior of the function object.]</i></p>


<p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
have a clear statement of "predicate" in the
standard. People including me seemed to think "a function
returning a Boolean value and being able to be called by an STL
algorithm or be used as sorting criterion or ... is a
predicate". But a predicate has more requirements: It should
never change its behavior due to a call or being copied. IMHO we have
to state this in the standard. If you like, see section 8.1.4 of my
library book for a detailed discussion.]</i></p>


<p><i>[Kona: Nico will provide wording to the effect that "unless
otherwise specified, the number of copies of and calls to function
objects by algorithms is unspecified".&nbsp; Consider placing in
25 [algorithms] after paragraph 9.]</i></p>


<p><i>[Santa Cruz: The standard doesn't currently guarantee that
  functions object won't be copied, and what isn't forbidden is
  allowed.  It is believed (especially since implementations that were
  written in concert with the standard do make copies of function
  objects) that this was intentional.  Thus, no normative change is
  needed.  What we should put in is a non-normative note suggesting to
  programmers that if they want to guarantee the lack of copying they
  should use something like the <tt>ref</tt> wrapper.]</i></p>


<p><i>[Oxford: Matt provided wording.]</i></p>








<hr>
<h3><a name="98"></a>98. Input iterator requirements are badly written</h3>
<p><b>Section:</b> 24.2.3 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Table 72 in 24.2.3 [input.iterators] specifies semantics for
<tt>*r++</tt> of:</p>

<p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>

<p>There are two problems with this.  First, the return type is
specified to be "T", as opposed to something like "convertible to T".
This is too specific: we want to allow *r++ to return an lvalue.</p>

<p>Second, writing the semantics in terms of code misleadingly
suggests that the effects *r++ should precisely replicate the behavior
of this code, including side effects.  (Does this mean that *r++
should invoke the copy constructor exactly as many times as the sample
code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar
problem.</p>



<p><b>Proposed resolution:</b></p>
<p>In Table 72 in 24.2.3 [input.iterators], change the return type
for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>


<p><b>Rationale:</b></p>
<p>This issue has two parts: the return type, and the number of times
  the copy constructor is invoked.</p>

<p>The LWG believes the the first part is a real issue.  It's
  inappropriate for the return type to be specified so much more
  precisely for *r++ than it is for *r.  In particular, if r is of
  (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
  but <tt>int&amp;</tt>.</p>

<p>The LWG does not believe that the number of times the copy
  constructor is invoked is a real issue.  This can vary in any case,
  because of language rules on copy constructor elision.  That's too
  much to read into these semantics clauses.</p>

<p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since 
   we're told (24.1/3) that forward iterators satisfy all the requirements
   of input iterators, we can't impose any requirements in the Input
   Iterator requirements table that forward iterators don't satisfy.</p>





<hr>
<h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Set::iterator is described as implementation-defined with a
reference to the container requirement; the container requirement says
that const_iterator is an iterator pointing to const T and iterator an
iterator pointing to T.</p>

<p>23.1.2 paragraph 2 implies that the keys should not be modified to
break the ordering of elements. But that is not clearly
specified. Especially considering that the current standard requires
that iterator for associative containers be different from
const_iterator. Set, for example, has the following: </p>

<p><tt>typedef implementation defined iterator;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>

<p>23.2 [container.requirements] actually requires that iterator type pointing
to T (table 65). Disallowing user modification of keys by changing the
standard to require an iterator for associative container to be the
same as const_iterator would be overkill since that will unnecessarily
significantly restrict the usage of associative container. A class to
be used as elements of set, for example, can no longer be modified
easily without either redesigning the class (using mutable on fields
that have nothing to do with ordering), or using const_cast, which
defeats requiring iterator to be const_iterator. The proposed solution
goes in line with trusting user knows what he is doing. </p>

<p><b>Other Options Evaluated:</b> </p>

<p>Option A.&nbsp;&nbsp; In 23.2.4 [associative.reqmts], paragraph 2, after
first sentence, and before "In addition,...", add one line:
</p>

<blockquote>
  <p>Modification of keys shall not change their strict weak ordering. </p>
</blockquote>

<p>Option B.&nbsp;Add three new sentences to 23.2.4 [associative.reqmts]:</p>

<blockquote>
  <p>At the end of paragraph 5: "Keys in an associative container
  are immutable." At the end of paragraph 6: "For
  associative containers where the value type is the same as the key
  type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
  constant iterators. It is unspecified whether or not
  <tt>iterator</tt> and <tt>const_iterator</tt> are the same
  type."</p>
</blockquote>

<p>Option C.&nbsp;To 23.2.4 [associative.reqmts], paragraph 3, which
currently reads:</p>

<blockquote>
  <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
  comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
  container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
  == false &amp;&amp; comp(k2, k1) == false.</p>
</blockquote>

<p>&nbsp; add the following:</p>

<blockquote>
  <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
  value whenever it is evaluated. [Note: If k2 is removed from the container and later
  reinserted, comp(k1, k2) must still return a consistent value but this value may be
  different than it was the first time k1 and k2 were in the same container. This is
  intended to allow usage like a string key that contains a filename, where comp compares
  file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
  reinserted, comp(k1, k2) must again return a consistent value but this value may be
  different than it was the previous time k2 was in the container.]</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>Add the following to 23.2.4 [associative.reqmts] at
the indicated location:</p>

<blockquote>
  <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
  calling comp(k1, k2) shall always return the same
  value."</p>
  <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
  <p>At the end of paragraph 6: "For associative containers where the value type is the
  same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
  iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
  are the same type."</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>Several arguments were advanced for and against allowing set elements to be
mutable as long as the ordering was not effected. The argument which swayed the
LWG was one of safety; if elements were mutable, there would be no compile-time
way to detect of a simple user oversight which caused ordering to be
modified.  There was a report that this had actually happened in practice,
and had been painful to diagnose.  If users need to modify elements,
it is possible to use mutable members or const_cast.</p>

<p>Simply requiring that keys be immutable is not sufficient, because the comparison
object may indirectly (via pointers) operate on values outside of the keys.</p>

<p>
The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
to be different types to allow for potential future work in which some
member functions might be overloaded between the two types.  No such
member functions exist now, and the LWG believes that user functionality
will not be impaired by permitting the two types to be the same.  A
function that operates on both iterator types can be defined for 
<tt>const_iterator</tt> alone, and can rely on the automatic
conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
</p>

<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>






<hr>
<h3><a name="106"></a>106. Numeric library private members are implementation defined</h3>
<p><b>Section:</b> 26.6.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>This is the only place in the whole standard where the implementation has to document
something private.</p>


<p><b>Proposed resolution:</b></p>
<p>
Remove the comment which says "// remainder implementation defined" from:
</p>

<ul>
  <li>26.6.5 [template.slice.array]</li>
  <li>26.6.7 [template.gslice.array]</li>
  <li>26.6.8 [template.mask.array]</li>
  <li>26.6.9 [template.indirect.array]</li>
</ul>





<hr>
<h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</h3>
<p><b>Section:</b> 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
exception::what() is left unspecified. This issue has implications
with exception safety of exception handling: some exceptions should
not throw bad_alloc.</p>


<p><b>Proposed resolution:</b></p>
<p>Add to 18.7.1 [type.info] paragraph 9 (exception::what notes
clause) the sentence:</p>

<blockquote>
  <p>The return value remains valid until the exception object from which it is obtained is
  destroyed or a non-const member function of the exception object is called.</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>If an exception object has non-const members, they may be used
to set internal state that should affect the contents of the string
returned by <tt>what()</tt>.
</p>





<hr>
<h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3>
<p><b>Section:</b> D.11 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>There are no versions of binders that apply to non-const elements
of a sequence. This makes examples like for_each() using bind2nd() on
page 521 of "The C++ Programming Language (3rd)"
non-conforming. Suitable versions of the binders need to be added.</p>

<p>Further discussion from Nico:</p>

<p>What is probably meant here is shown in the following example:</p>

<pre>class Elem { 
  public: 
    void print (int i) const { } 
    void modify (int i) { } 
}; </pre>
<pre>int main() 
{ 
    vector&lt;Elem&gt; coll(2); 
    for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK 
    for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR 
}</pre>

<p>The error results from the fact that bind2nd() passes its first
argument (the argument of the sequence) as constant reference. See the
following typical implementation:</p>

<blockquote>
  <pre>template &lt;class Operation&gt; 
class binder2nd 
  : public unary_function&lt;typename Operation::first_argument_type, 
                          typename Operation::result_type&gt; { 
protected: 
  Operation op; 
  typename Operation::second_argument_type value; 
public: 
  binder2nd(const Operation&amp; o, 
            const typename Operation::second_argument_type&amp; v) 
      : op(o), value(v) {} </pre>
  <pre> typename Operation::result_type 
  operator()(const typename Operation::first_argument_type&amp; x) const { 
    return op(x, value); 
  } 
};</pre>
</blockquote>

<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>

<blockquote>
  <pre>template &lt;class Operation&gt; 
class binder2nd 
  : public unary_function&lt;typename Operation::first_argument_type, 
                          typename Operation::result_type&gt; { 
protected: 
  Operation op; 
  typename Operation::second_argument_type value; 
public: 
  binder2nd(const Operation&amp; o, 
            const typename Operation::second_argument_type&amp; v) 
      : op(o), value(v) {} </pre>
  <pre> typename Operation::result_type 
  operator()(const typename Operation::first_argument_type&amp; x) const { 
    return op(x, value); 
  } 
  typename Operation::result_type 
  operator()(typename Operation::first_argument_type&amp; x) const { 
    return op(x, value); 
  } 
};</pre>
</blockquote>


<p><b>Proposed resolution:</b></p>

<p><b>Howard believes there is a flaw</b> in this resolution.
See c++std-lib-9127.  We may need to reopen this issue.</p>

<p>In D.11 [depr.lib.binders] in the declaration of binder1st after:</p>
<blockquote>
  <p><tt>typename Operation::result_type<br>
  &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
</blockquote>
<p>insert:</p>
<blockquote>
  <p><tt>typename Operation::result_type<br>
  &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
</blockquote>
<p>In D.11 [depr.lib.binders] in the declaration of binder2nd after:</p>
<blockquote>
  <p><tt>typename Operation::result_type<br>
  &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
</blockquote>
<p>insert:</p>
<blockquote>
  <p><tt>typename Operation::result_type<br>
  &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
</blockquote>

<p><i>[Kona: The LWG discussed this at some length.It was agreed that
this is a mistake in the design, but there was no consensus on whether
it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
proposed resolution - 3.  Leave open - 6.]</i></p>


<p><i>[Copenhagen: It was generally agreed that this was a defect.
Strap poll: NAD - 0.  Accept proposed resolution - 10. 
Leave open - 1.]</i></p>







<hr>
<h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3>
<p><b>Section:</b> 24.6.3 [istreambuf.iterator], 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Member istreambuf_iterator&lt;&gt;::equal is not declared
"const", yet 24.6.3.6 [istreambuf.iterator::op==] says that operator==,
which is const, calls it. This is contradictory. </p>


<p><b>Proposed resolution:</b></p>
<p>In 24.6.3 [istreambuf.iterator] and also in 24.6.3.5 [istreambuf.iterator::equal],
replace:</p>

<blockquote>
  <pre>bool equal(istreambuf_iterator&amp; b);</pre>
</blockquote>

<p>with:</p>

<blockquote>
  <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
</blockquote>





<hr>
<h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3>
<p><b>Section:</b> 24.6.4.1 [ostreambuf.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-10-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
reads "<i>s</i> is not null". However, <i>s</i> is a
reference, and references can't be null. </p>


<p><b>Proposed resolution:</b></p>
<p>In 24.6.4.1 [ostreambuf.iter.cons]:</p>

<p>Move the current paragraph 1, which reads "Requires: s is not
null.", from the first constructor to the second constructor.</p>

<p>Insert a new paragraph 1 Requires clause for the first constructor
reading:</p>

<blockquote>
  <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
</blockquote>





<hr>
<h3><a name="114"></a>114. Placement forms example in error twice</h3>
<p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p>
<p><b>Discussion:</b></p>
<p>Section 18.5.1.3 contains the following example: </p>

<pre>[Example: This can be useful for constructing an object at a known address:
        char place[sizeof(Something)];
        Something* p = new (place) Something();
 -end example]</pre>

<p>First code line: "place" need not have any special alignment, and the
following constructor could fail due to misaligned data.</p>

<p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
believes the () are correct.]</p>

<p>Examples are not normative, but nevertheless should not show code that is invalid or
likely to fail.</p>


<p><b>Proposed resolution:</b></p>
<p>Replace the first line of code in the example in 
18.6.1.3 [new.delete.placement] with:
</p>

<blockquote>
  <pre>void* place = operator new(sizeof(Something));</pre>
</blockquote>





<hr>
<h3><a name="115"></a>115. Typo in strstream constructors</h3>
<p><b>Section:</b> D.9.4.1 [depr.strstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-11-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>D.7.4.1 strstream constructors paragraph 2 says: </p>

<blockquote>
  <p>Effects: Constructs an object of class strstream, initializing the base class with
  iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
  <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
  elements. The constructor is strstreambuf(s, n, s). </p>
  <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
  elements that contains an NTBS whose first element is designated by s. The constructor is
  strstreambuf(s, n, s+std::strlen(s)).</p>
</blockquote>

<p>Notice the second condition is the same as the first. I think the second condition
should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
the append bit is set.</p>


<p><b>Proposed resolution:</b></p>
<p>In D.9.3.1 [depr.ostrstream.cons] paragraph 2 and D.9.4.1 [depr.strstream.cons]
paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>





<hr>
<h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3>
<p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The <b>effects</b> clause for numeric inserters says that
insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
delegated to <tt>num_put</tt>, and that insertion is performed as if
through the following code fragment: </p>

<pre>bool failed = use_facet&lt;
   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt; 
   &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>

<p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
void*</tt>. That is, the code fragment in the standard is incorrect
(it is diagnosed as ambiguous at compile time) for the types
<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
int</tt>, and <tt>float</tt>. </p>

<p>We must either add new member functions to <tt>num_put</tt>, or
else change the description in <tt>ostream</tt> so that it only calls
functions that are actually there. I prefer the latter. </p>


<p><b>Proposed resolution:</b></p>
<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>

<blockquote>
<p>
The classes num_get&lt;&gt; and num_put&lt;&gt; handle locale-dependent numeric
formatting and parsing.  These inserter functions use the imbued
locale value to perform numeric formatting.  When val is of type bool,
long, unsigned long, double, long double, or const void*, the
formatting conversion occurs as if it performed the following code
fragment:
</p>

<pre>bool failed = use_facet&lt;
   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
   &gt;(getloc()).put(*this, *this, fill(), val). failed();
</pre>

<p>
When val is of type short the formatting conversion occurs as if it
performed the following code fragment:
</p>

<pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
bool failed = use_facet&lt;
   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
   &gt;(getloc()).put(*this, *this, fill(),
      baseflags == ios_base::oct || baseflags == ios_base::hex
         ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
         : static_cast&lt;long&gt;(val)). failed();
</pre>

<p>
When val is of type int the formatting conversion occurs as if it performed
the following code fragment:
</p>

<pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
bool failed = use_facet&lt;
   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
   &gt;(getloc()).put(*this, *this, fill(),
      baseflags == ios_base::oct || baseflags == ios_base::hex
         ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
         : static_cast&lt;long&gt;(val)). failed();
</pre>

<p>
When val is of type unsigned short or unsigned int the formatting conversion
occurs as if it performed the following code fragment:
</p>

<pre>bool failed = use_facet&lt;
   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
   &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
failed();
</pre>

<p>
When val is of type float the formatting conversion occurs as if it
performed the following code fragment:
</p>

<pre>bool failed = use_facet&lt;
   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
   &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
failed();
</pre>

</blockquote>

<p><i>[post-Toronto: This differs from the previous proposed
resolution; PJP provided the new wording.  The differences are in
signed short and int output.]</i></p>



<p><b>Rationale:</b></p>
<p>The original proposed resolution was to cast int and short to long,
unsigned int and unsigned short to unsigned long, and float to double,
thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
member functions.  The current proposed resolution is more
complicated, but gives more expected results for hex and octal output
of signed short and signed int.  (On a system with 16-bit short, for
example, printing short(-1) in hex format should yield 0xffff.)</p>





<hr>
<h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3>
<p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>

<pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget; 
iostate err = 0; 
use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val); 
setstate(err);</pre>

<p>According to section 22.4.2.1.1 [facet.num.get.members], however,
<tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
<tt>void*</tt>. Comparing the lists from the two sections, we find
that 27.6.1.2.2 is using a nonexistent function for types
<tt>short</tt> and <tt>int</tt>. </p>


<p><b>Proposed resolution:</b></p>
<p>In 27.7.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
two lines (1st and 3rd) which read:</p>
<blockquote>
  <pre>operator&gt;&gt;(short&amp; val);
...
operator&gt;&gt;(int&amp; val);</pre>
</blockquote>

<p>And add the following at the end of that section (27.6.1.2.2) :</p>

<blockquote>
  <pre>operator&gt;&gt;(short&amp; val);</pre>
  <p>The conversion occurs as if performed by the following code fragment (using
  the same notation as for the preceding code fragment):</p>
  <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
  iostate err = 0;
  long lval;
  use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
        if (err == 0
                &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
                err = ios_base::failbit;
  setstate(err);</pre>
  <pre>operator&gt;&gt;(int&amp; val);</pre>
  <p>The conversion occurs as if performed by the following code fragment (using
  the same notation as for the preceding code fragment):</p>
  <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
  iostate err = 0;
  long lval;
  use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
        if (err == 0
                &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
                err = ios_base::failbit;
  setstate(err);</pre>
</blockquote>

<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>






<hr>
<h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
<p><b>Section:</b> 17.6.4.12 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 17.6.4.12 [res.on.exception.handling] states: </p>

<p>"An implementation may strengthen the exception-specification
for a function by removing listed exceptions." </p>

<p>The problem is that if an implementation is allowed to do this for
virtual functions, then a library user cannot write a class that
portably derives from that class. </p>

<p>For example, this would not compile if ios_base::failure::~failure
had an empty exception specification: </p>

<pre>#include &lt;ios&gt;
#include &lt;string&gt;

class D : public std::ios_base::failure {
public:
        D(const std::string&amp;);
        ~D(); // error - exception specification must be compatible with 
              // overridden virtual function ios_base::failure::~failure()
};</pre>


<p><b>Proposed resolution:</b></p>
<p>Change Section 17.6.4.12 [res.on.exception.handling] from:</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
exception-specification for a function"</p>

<p>to:</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
exception-specification for a non-virtual function". </p>





<hr>
<h3><a name="120"></a>120. Can an implementor add specializations?</h3>
<p><b>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>The original issue asked whether a library implementor could
specialize standard library templates for built-in types.  (This was
an issue because users are permitted to explicitly instantiate
standard library templates.)</p>

<p>Specializations are no longer a problem, because of the resolution
to core issue 259.  Under the proposed resolution, it will be legal
for a translation unit to contain both a specialization and an
explicit instantiation of the same template, provided that the
specialization comes first.  In such a case, the explicit
instantiation will be ignored.  Further discussion of library issue
120 assumes that the core 259 resolution will be adopted.</p>

<p>However, as noted in lib-7047, one piece of this issue still
remains: what happens if a standard library implementor explicitly
instantiates a standard library templates?  It's illegal for a program
to contain two different explicit instantiations of the same template
for the same type in two different translation units (ODR violation),
and the core working group doesn't believe it is practical to relax
that restriction.</p>

<p>The issue, then, is: are users allowed to explicitly instantiate
standard library templates for non-user defined types?  The status quo
answer is 'yes'.  Changing it to 'no' would give library implementors
more freedom.</p>

<p>This is an issue because, for performance reasons, library
implementors often need to explicitly instantiate standard library
templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
users freedom to explicitly instantiate standard library templates for
non-user defined types make it impossible or painfully difficult for
library implementors to do this?</p>

<p>John Spicer suggests, in lib-8957, that library implementors have a
mechanism they can use for explicit instantiations that doesn't
prevent users from performing their own explicit instantiations: put
each explicit instantiation in its own object file.  (Different
solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
some platforms, library implementors might not need to do anything
special: the "undefined behavior" that results from having two
different explicit instantiations might be harmless.</p>



<p><b>Proposed resolution:</b></p>
  <p>Append to 17.6.3.3 [reserved.names] paragraph 1: </p>
  <blockquote><p>
    A program may explicitly instantiate any templates in the standard
    library only if the declaration depends on the name of a user-defined
    type of external linkage and the instantiation meets the standard library
    requirements for the original template.
  </p></blockquote>

<p><i>[Kona: changed the wording from "a user-defined name" to "the name of
  a user-defined type"]</i></p>




<p><b>Rationale:</b></p>
<p>The LWG considered another possible resolution:</p>
<blockquote>
  <p>In light of the resolution to core issue 259, no normative changes
  in the library clauses are necessary.  Add the following non-normative
  note to the end of 17.6.3.3 [reserved.names] paragraph 1:</p>
  <blockquote><p>
    [<i>Note:</i> A program may explicitly instantiate standard library
    templates, even when an explicit instantiation does not depend on
    a user-defined name. <i>--end note</i>]
  </p></blockquote>
</blockquote>

<p>The LWG rejected this because it was believed that it would make
  it unnecessarily difficult for library implementors to write
  high-quality implementations.  A program may not include an
  explicit instantiation of the same template, for the same template
  arguments, in two different translation units.  If users are
  allowed to provide explicit instantiations of Standard Library
  templates for built-in types, then library implementors aren't,
  at least not without nonportable tricks.</p>

<p>The most serious problem is a class template that has writeable
  static member variables.  Unfortunately, such class templates are
  important and, in existing Standard Library implementations, are
  often explicitly specialized by library implementors: locale facets,
  which have a writeable static member variable <tt>id</tt>.  If a
  user's explicit instantiation collided with the implementations
  explicit instantiation, iostream initialization could cause locales
  to be constructed in an inconsistent state.</p>

<p>One proposed implementation technique was for Standard Library
  implementors to provide explicit instantiations in separate object
  files, so that they would not be picked up by the linker when the
  user also provides an explicit instantiation.  However, this
  technique only applies for Standard Library implementations that
  are packaged as static archives.  Most Standard Library
  implementations nowadays are packaged as dynamic libraries, so this
  technique would not apply.</p>

<p>The Committee is now considering standardization of dynamic
  linking.  If there are such changes in the future, it may be
  appropriate to revisit this issue later.</p>





<hr>
<h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</h3>
<p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 27.5.2 describes the streambuf classes this way: </p>

<blockquote>

<p>The class streambuf is a specialization of the template class basic_streambuf
specialized for the type char. </p>

<p>The class wstreambuf is a specialization of the template class basic_streambuf
specialized for the type wchar_t. </p>

</blockquote>

<p>This implies that these classes must be template specializations, not typedefs. </p>

<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>


<p><b>Proposed resolution:</b></p>
<p>Remove 27.6.2 [streambuf] paragraphs 2 and 3 (the above two
sentences). </p>


<p><b>Rationale:</b></p>
<p>The <tt>streambuf</tt>  synopsis already has a declaration for the
typedefs and that is sufficient. </p>





<hr>
<h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
<p><b>Section:</b> 26.6.5.3 [slice.arr.fill], 26.6.7.3 [gslice.array.fill], 26.6.8.3 [mask.array.fill], 26.6.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>One of the operator= in the valarray helper arrays is const and one
is not. For example, look at slice_array. This operator= in Section
26.6.5.1 [slice.arr.assign] is const: </p>

<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>

<p>but this one in Section 26.6.5.3 [slice.arr.fill] is not: </p>

<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>

<p>The description of the semantics for these two functions is similar. </p>


<p><b>Proposed resolution:</b></p>

<p>26.6.5 [template.slice.array] Template class slice_array</p>
<blockquote>

   <p>In the class template definition for slice_array, replace the member
   function declaration</p>
    <pre>      void operator=(const T&amp;);
    </pre>
   <p>with</p>
    <pre>      void operator=(const T&amp;) const;
    </pre>
</blockquote>

<p>26.6.5.3 [slice.arr.fill] slice_array fill function</p>
<blockquote>

   <p>Change the function declaration</p>
    <pre>      void operator=(const T&amp;);
    </pre>
   <p>to</p>
    <pre>      void operator=(const T&amp;) const;
    </pre>
</blockquote>

<p>26.6.7 [template.gslice.array] Template class gslice_array</p>
<blockquote>

   <p>In the class template definition for gslice_array, replace the member
   function declaration</p>
    <pre>      void operator=(const T&amp;);
    </pre>
   <p>with</p>
    <pre>      void operator=(const T&amp;) const;
    </pre>
</blockquote>

<p>26.6.7.3 [gslice.array.fill] gslice_array fill function</p>
<blockquote>

   <p>Change the function declaration</p>
    <pre>      void operator=(const T&amp;);
    </pre>
   <p>to</p>
    <pre>      void operator=(const T&amp;) const;
    </pre>
</blockquote>

<p>26.6.8 [template.mask.array] Template class mask_array</p>
<blockquote>

   <p>In the class template definition for mask_array, replace the member
   function declaration</p>
    <pre>      void operator=(const T&amp;);
    </pre>
   <p>with</p>
    <pre>      void operator=(const T&amp;) const;
    </pre>
</blockquote>

<p>26.6.8.3 [mask.array.fill] mask_array fill function</p>
<blockquote>

   <p>Change the function declaration</p>
    <pre>      void operator=(const T&amp;);
    </pre>
   <p>to</p>
    <pre>      void operator=(const T&amp;) const;
    </pre>
</blockquote>

<p>26.6.9 [template.indirect.array] Template class indirect_array</p>
<blockquote>

   <p>In the class template definition for indirect_array, replace the member
   function declaration</p>
    <pre>      void operator=(const T&amp;);
    </pre>
   <p>with</p>
    <pre>      void operator=(const T&amp;) const;
    </pre>
</blockquote>

<p>26.6.9.3 [indirect.array.fill] indirect_array fill function</p>
<blockquote>

   <p>Change the function declaration</p>
    <pre>      void operator=(const T&amp;);
    </pre>
   <p>to</p>
    <pre>      void operator=(const T&amp;) const;
    </pre>
</blockquote>


<p><i>[Redmond: Robert provided wording.]</i></p>




<p><b>Rationale:</b></p>
<p>There's no good reason for one version of operator= being const and
another one not.  Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now
matters: these functions are now callable in more circumstances.  In
many existing implementations, both versions are already const.</p>





<hr>
<h3><a name="124"></a>124. ctype_byname&lt;charT&gt;::do_scan_is &amp; do_scan_not return type should be const charT*</h3>
<p><b>Section:</b> 22.4.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In Section 22.4.1.2 [locale.ctype.byname]
ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
to return a const char* not a const charT*. </p>


<p><b>Proposed resolution:</b></p>
<p>Change Section 22.4.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
<tt>do_scan_not()</tt> to return a <tt> const
charT*</tt>. </p>





<hr>
<h3><a name="125"></a>125. valarray&lt;T&gt;::operator!() return type is inconsistent</h3>
<p><b>Section:</b> 26.6.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In Section 26.6.2 [template.valarray] valarray&lt;T&gt;::operator!() is
declared to return a valarray&lt;T&gt;, but in Section 26.6.2.5 [valarray.unary] it is declared to return a valarray&lt;bool&gt;. The
latter appears to be correct. </p>


<p><b>Proposed resolution:</b></p>
<p>Change in Section 26.6.2 [template.valarray] the declaration of
<tt>operator!()</tt> so that the return type is
<tt>valarray&lt;bool&gt;</tt>. </p>




<hr>
<h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</h3>
<p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p>

<p><b>Proposed resolution:</b></p>
<p>In Section 22.4.1.1.2 [locale.ctype.virtuals] change: </p>

<pre>   do_widen(do_narrow(c),0) == c</pre>

<p>to:</p>

<pre>   do_widen(do_narrow(c,0)) == c</pre>

<p>and change:</p>

<pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>

<p>to:</p>

<pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>





<hr>
<h3><a name="127"></a>127. auto_ptr&lt;&gt; conversion issues</h3>
<p><b>Section:</b> D.12.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Greg Colvin <b>Opened:</b> 1999-02-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There are two problems with the current <tt>auto_ptr</tt> wording
in the standard: </p>

<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
<tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
Nathan Myers, with the same proposed resolution.</i></p>

<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
<tt>auto_ptr_ref</tt> argument. </p>

<p>I have discussed these problems with my proposal coauthor, Bill
Gibbons, and with some compiler and library implementors, and we
believe that these problems are not desired or desirable implications
of the standard. </p>

<p>25 Aug 1999: The proposed resolution now reflects changes suggested
by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
"assignment operator" to "public assignment
operator", 2) changed effects to specify use of release(), 3)
made the conversion to auto_ptr_ref const. </p>

<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
states that the conversion from auto_ptr to auto_ptr_ref should
be const.  This is not acceptable, because it would allow
initialization and assignment from _any_ const auto_ptr!  It also
introduces an implementation difficulty in writing this conversion
function -- namely, somewhere along the line, a const_cast will be
necessary to remove that const so that release() may be called.  This
may result in undefined behavior [7.1.5.1/4]. The conversion
operator does not have to be const, because a non-const implicit
object parameter may be bound to an rvalue [13.3.3.1.4/3]
[13.3.1/5]. </p>

  <p>Tokyo: The LWG removed the following from the proposed resolution:</p>

  <p>In 20.7.4 [meta.unary], paragraph 2, and 20.7.4.3 [meta.unary.prop], 
  paragraph 2, make the conversion to auto_ptr_ref const:</p>
  <blockquote>
    <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
  </blockquote>


<p><b>Proposed resolution:</b></p>
<p>In 20.7.4 [meta.unary], paragraph 2, move
the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>

<p>In 20.7.4 [meta.unary], paragraph 2, add
a public assignment operator to the <tt>auto_ptr</tt> definition: </p>

<blockquote>
  <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
</blockquote>

<p>Also add the assignment operator to 20.7.4.3 [meta.unary.prop]: </p>

<blockquote>
  <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>

  <p><b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
  p</tt> that <tt>r</tt> holds a reference to.<br>
  <b>Returns: </b><tt>*this</tt>.</p>

</blockquote>





<hr>
<h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted], 27.7.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-02-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Currently, the standard does not specify how seekg() and seekp()
indicate failure. They are not required to set failbit, and they can't
return an error indication because they must return *this, i.e. the
stream. Hence, it is undefined what happens if they fail. And they
<i>can</i> fail, for instance, when a file stream is disconnected from the
underlying file (is_open()==false) or when a wide character file
stream must perform a state-dependent code conversion, etc. </p>

<p>The stream functions seekg() and seekp() should set failbit in the
stream state in case of failure.</p>


<p><b>Proposed resolution:</b></p>
<p>Add to the Effects: clause of&nbsp; seekg() in 
27.7.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
27.7.2.5 [ostream.seeks]: </p>

<blockquote>
  <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
  </p>
</blockquote>


<p><b>Rationale:</b></p>
<p>Setting failbit is the usual error reporting mechanism for streams</p>




<hr>
<h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p>
<p><b>Discussion:</b></p>
<p>Table 67 (23.1.1) says that container::erase(iterator) returns an
iterator. Table 69 (23.1.2) says that in addition to this requirement,
associative containers also say that container::erase(iterator)
returns void.  That's not an addition; it's a change to the
requirements, which has the effect of making associative containers
fail to meet the requirements for containers.</p>


<p><b>Proposed resolution:</b></p>

<p>
In 23.2.4 [associative.reqmts], in Table 69 Associative container
requirements, change the return type of <tt>a.erase(q)</tt> from
<tt>void</tt> to <tt>iterator</tt>.  Change the
assertion/not/pre/post-condition from "erases the element pointed to
by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
Returns an iterator pointing to the element immediately following q
prior to the element being erased. If no such element exists, a.end()
is returned."
</p>

<p>
In 23.2.4 [associative.reqmts], in Table 69 Associative container
requirements, change the return type of <tt>a.erase(q1, q2)</tt>
from <tt>void</tt> to <tt>iterator</tt>.  Change the
assertion/not/pre/post-condition from "erases the elements in the
range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
q2)</tt>.  Returns q2."
</p>

<p>
In 23.6.1 [map], in the <tt>map</tt> class synopsis; and 
in 23.6.2 [multimap], in the <tt>multimap</tt> class synopsis; and
in 23.6.3 [set], in the <tt>set</tt> class synopsis; and
in 23.6.4 [multiset], in the <tt>multiset</tt> class synopsis:
change the signature of the first <tt>erase</tt> overload to
</p>
<pre>   iterator erase(iterator position);
</pre>
<p>and change the signature of the third <tt>erase</tt> overload to</p>
<pre>  iterator erase(iterator first, iterator last); 
</pre>


<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>


<p><i>[Post-Kona: the LWG agrees the return type should be
<tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
Matt provided wording.]</i></p>


<p><i>[
 Sydney: the proposed wording went in the right direction, but it
 wasn't good enough. We want to return an iterator from the range form
 of erase as well as the single-iterator form. Also, the wording is
 slightly different from the wording we have for sequences; there's no
 good reason for having a difference.  Matt provided new wording,
(reflected above) which we will review at the next meeting.
]</i></p>


<p><i>[
Redmond:  formally voted into WP.
]</i></p>







<hr>
<h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
<p><b>Section:</b> 23.3.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.capacity">issues</a> in [list.capacity].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description reads:</p>

<p>-1- Effects:</p>

<pre>         if (sz &gt; size())
           insert(end(), sz-size(), c);
         else if (sz &lt; size())
           erase(begin()+sz, end());
         else
           ;                           //  do nothing</pre>

<p>Obviously list::resize should not be specified in terms of random access iterators.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 23.3.4.2 [list.capacity] paragraph 1 to:</p>

<p>Effects:</p>

<pre>         if (sz &gt; size())
           insert(end(), sz-size(), c);
         else if (sz &lt; size())
         {
           iterator i = begin();
           advance(i, sz);
           erase(i, end());
         }</pre>

<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
with David Abrahams. They had a discussion and believe there is
no issue of exception safety with the proposed resolution.]</i></p>






<hr>
<h3><a name="133"></a>133. map missing get_allocator()</h3>
<p><b>Section:</b> 23.6.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p><p>The title says it all.</p>

<p><b>Proposed resolution:</b></p>
<p>Insert in 23.6.1 [map], paragraph 2,
after operator= in the map declaration:</p>

<pre>    allocator_type get_allocator() const;</pre>




<hr>
<h3><a name="134"></a>134. vector constructors over specified</h3>
<p><b>Section:</b> 23.4.1.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The complexity description says: "It does at most 2N calls to the copy constructor
of T and logN reallocations if they are just input iterators ...".</p>

<p>This appears to be overly restrictive, dictating the precise memory/performance
tradeoff for the implementor.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 23.4.1.1 [vector.cons], paragraph 1 to:</p>

<p>-1- Complexity: The constructor template &lt;class
InputIterator&gt; vector(InputIterator first, InputIterator last)
makes only N calls to the copy constructor of T (where N is the
distance between first and last) and no reallocations if iterators
first and last are of forward, bidirectional, or random access
categories. It makes order N calls to the copy constructor of T and
order logN reallocations if they are just input iterators.
</p>


<p><b>Rationale:</b></p>
<p>"at most 2N calls" is correct only if the growth factor
is greater than or equal to 2.
</p>




<hr>
<h3><a name="136"></a>136. seekp, seekg setting wrong streams?</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>I may be misunderstanding the intent, but should not seekg set only
the input stream and seekp set only the output stream? The description
seems to say that each should set both input and output streams. If
that's really the intent, I withdraw this proposal.</p>


<p><b>Proposed resolution:</b></p>
<p>In section 27.6.1.3 change:</p>

<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>

<p>To:</p>

<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>

<p>In section 27.6.1.3 change:</p>

<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>

<p>To:</p>

<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>

<p>In section 27.6.2.4, paragraph 2 change:</p>

<pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>

<p>To:</p>

<pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>

<p>In section 27.6.2.4, paragraph 4 change:</p>

<pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>

<p>To:</p>

<pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>

<p><i>[Dublin: Dietmar K�hl thinks this is probably correct, but would
like the opinion of more iostream experts before taking action.]</i></p>


<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
incorrect, his implementation already implements the Proposed
Resolution.]</i></p>


<p><i>[Post-Tokyo: Matt Austern comments:<br>
Is it a problem with basic_istream and basic_ostream, or is it a problem
with basic_stringbuf?
We could resolve the issue either by changing basic_istream and
basic_ostream, or by changing basic_stringbuf. I prefer the latter
change (or maybe both changes): I don't see any reason for the standard to
require that std::stringbuf s(std::string("foo"), std::ios_base::in);
s.pubseekoff(0, std::ios_base::beg); must fail.<br>
This requirement is a bit weird. There's no similar requirement
for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
basic_filebuf&lt;&gt;::seekpos.]</i></p>






<hr>
<h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3>
<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-03-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 22.3.1 [locale] says:</p>

<p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
chooses a facet, making available all members of the named type. If
Facet is not present in a locale (or, failing that, in the global
locale), it throws the standard exception bad_cast. A C++ program can
check if a locale implements a particular facet with the template
function has_facet&lt;Facet&gt;(). </p>

<p>This contradicts the specification given in section 
22.3.2 [locale.global.templates]:
<br><br>
template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
locale&amp;&nbsp; loc); <br>
<br>
-1- Get a reference to a facet of a locale. <br>
-2- Returns: a reference to the corresponding facet of loc, if present. <br>
-3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
-4- Notes: The reference returned remains valid at least as long as any copy of loc exists
</p>


<p><b>Proposed resolution:</b></p>
<p>Remove the phrase "(or, failing that, in the global locale)"
from section 22.1.1. </p>


<p><b>Rationale:</b></p>
<p>Needed for consistency with the way locales are handled elsewhere
in the standard.</p>




<hr>
<h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The sentence introducing the Optional sequence operation table
(23.1.1 paragraph 12) has two problems:</p>

<p>A. It says ``The operations in table 68 are provided only for the containers for which
they take constant time.''<br>
<br>
That could be interpreted in two ways, one of them being ``Even though table 68 shows
particular operations as being provided, implementations are free to omit them if they
cannot implement them in constant time.''<br>
<br>
B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>


<p><b>Proposed resolution:</b></p>
<p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
with:</p>

<blockquote>
  <p>Table 68 lists sequence operations that are provided for some types of sequential
  containers but not others. An implementation shall provide these operations for all
  container types shown in the ``container'' column, and shall implement them so as to take
  amortized constant time.</p>
</blockquote>




<hr>
<h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3>
<p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Arch Robison <b>Opened:</b> 1999-04-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
say:<br>
<br>
� <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>

<p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>

<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
proposed resolution.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
<br>
� <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
<br>
</tt>to:<br>
<tt><br>
</tt>� <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>




<hr>
<h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3>
<p><b>Section:</b> 25.4.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-06-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The lexicographical_compare complexity is specified as:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
applications of the corresponding comparison."<br>
<br>
The best I can do is twice that expensive.</p>

<p>Nicolai Josuttis comments in lib-6862: You mean, to check for
equality you have to check both &lt; and &gt;? Yes, IMO you are
right! (and Matt states this complexity in his book)</p>



<p><b>Proposed resolution:</b></p>
<p>Change 25.4.8 [alg.lex.comparison] complexity to:</p>
    <blockquote><p>
    At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
    applications of the corresponding comparison.
    </p></blockquote>

<p>Change the example at the end of paragraph 3 to read:</p>
    <blockquote><p>
    [Example:<br>
    <br>
    &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
    ++first1, ++first2) {<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
    &nbsp;&nbsp;&nbsp; }<br>
    &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
    &nbsp;&nbsp;&nbsp;<br>
    --end example]
    </p></blockquote>




<hr>
<h3><a name="144"></a>144. Deque constructor complexity wrong </h3>
<p><b>Section:</b> 23.3.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1999-05-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 23.3.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
to have complexity requirements which are incorrect, and which contradict the
complexity requirements for insert(). I suspect that the text in question,
below, was taken from vector:</p>
<blockquote>
  <p>Complexity: If the iterators first and last are forward iterators,
  bidirectional iterators, or random access iterators the constructor makes only
  N calls to the copy constructor, and performs no reallocations, where N is
  last - first.</p>
</blockquote>
<p>The word "reallocations" does not really apply to deque. Further,
all of the following appears to be spurious:</p>
<blockquote>
  <p>It makes at most 2N calls to the copy constructor of T and log N
  reallocations if they are input iterators.1)</p>
  <p>1) The complexity is greater in the case of input iterators because each
  element must be added individually: it is impossible to determine the distance
  between first abd last before doing the copying.</p>
</blockquote>
<p>This makes perfect sense for vector, but not for deque. Why should deque gain
an efficiency advantage from knowing in advance the number of elements to
insert?</p>


<p><b>Proposed resolution:</b></p>
<p>In 23.3.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
footnote, with the following text (which also corrects the "abd"
typo):</p>
<blockquote>
  <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
</blockquote>




<hr>
<h3><a name="146"></a>146. complex&lt;T&gt; Inserter and Extractor need sentries</h3>
<p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The extractor for complex numbers is specified as:&nbsp;</p>

<blockquote>

<p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
     basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
     operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
&nbsp;<br>
Effects: Extracts a complex number x of the form: u, (u), or (u,v),
where u is the real part and v is the imaginary part
(lib.istream.formatted).&nbsp;<br>
Requires: The input values be convertible to T. If bad input is
encountered, calls is.setstate(ios::failbit) (which may throw
ios::failure (lib.iostate.flags).&nbsp;<br>
Returns: is .</p>

</blockquote>
<p>Is it intended that the extractor for complex numbers does not skip
whitespace, unlike all other extractors in the standard library do?
Shouldn't a sentry be used?&nbsp;<br>
<br>
The inserter for complex numbers is specified as:</p>

<blockquote>

<p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
     basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
     operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
<br>
Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
<br>
     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
     basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
     operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
     {&nbsp;<br>
             basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
             s.flags(o.flags());&nbsp;<br>
             s.imbue(o.getloc());&nbsp;<br>
             s.precision(o.precision());&nbsp;<br>
             s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
             return o &lt;&lt; s.str();&nbsp;<br>
     }</p>

</blockquote>

<p>Is it intended that the inserter for complex numbers ignores the
field width and does not do any padding? If, with the suggested
implementation above, the field width were set in the stream then the
opening parentheses would be adjusted, but the rest not, because the
field width is reset to zero after each insertion.</p>

<p>I think that both operations should use sentries, for sake of
consistency with the other inserters and extractors in the
library. Regarding the issue of padding in the inserter, I don't know
what the intent was.&nbsp;</p>


<p><b>Proposed resolution:</b></p>
<p>After 26.4.6 [complex.ops] paragraph 14 (operator&gt;&gt;), add a
Notes clause:</p>

<blockquote>

<p>Notes: This extraction is performed as a series of simpler
extractions. Therefore, the skipping of whitespace is specified to be the
same for each of the simpler extractions.</p>

</blockquote>


<p><b>Rationale:</b></p>
<p>For extractors, the note is added to make it clear that skipping whitespace
follows an "all-or-none" rule.</p>

<p>For inserters, the LWG believes there is no defect; the standard is correct
as written.</p>




<hr>
<h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3>
<p><b>Section:</b> 17.6.4.4 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Lois Goldthwaite <b>Opened:</b> 1999-06-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The library had many global functions until 17.4.1.1 [lib.contents]
paragraph 2 was added: </p>

<blockquote>

<p>All library entities except macros, operator new and operator
delete are defined within the namespace std or namespaces nested
within namespace std. </p>

</blockquote>

<p>It appears "global function" was never updated in the following: </p>

<blockquote>

<p>17.4.4.3 - Global functions [lib.global.functions]<br>
<br>
-1- It is unspecified whether any global functions in the C++ Standard
Library are defined as inline (dcl.fct.spec).<br>
<br>
-2- A call to a global function signature described in Clauses
lib.language.support through lib.input.output behaves the same as if
the implementation declares no additional global function
signatures.*<br>
<br>
    [Footnote: A valid C++ program always calls the expected library
    global function. An implementation may also define additional
    global functions that would otherwise not be called by a valid C++
    program. --- end footnote]<br>
<br>
-3- A global function cannot be declared by the implementation as
taking additional default arguments.&nbsp;<br>
<br>
17.4.4.4 - Member functions [lib.member.functions]<br>
<br>
-2- An implementation can declare additional non-virtual member
function signatures within a class: </p>

  <blockquote>

<p>-- by adding arguments with default values to a member function
signature; The same latitude does not extend to the implementation of
virtual or global functions, however. </p>

  </blockquote>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>     Change "global" to "global or non-member" in:</p>
<blockquote>
  <p>17.4.4.3 [lib.global.functions] section title,<br>
  17.4.4.3 [lib.global.functions] para 1,<br>
  17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2 
           places in the footnote,<br>
  17.4.4.3 [lib.global.functions] para 3,<br>
  17.4.4.4 [lib.member.functions] para 2</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>
Because operator new and delete are global, the proposed resolution
was changed from "non-member" to "global or non-member.
</p>




<hr>
<h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3>
<p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 1999-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 22.4.8 [facets.examples] paragraph 13, the do_truename() and
do_falsename() functions in the example facet BoolNames should be
const. The functions they are overriding in
numpunct_byname&lt;char&gt; are const. </p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.8 [facets.examples] paragraph 13, insert "const" in
two places:</p>
<blockquote>
  <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
  string do_falsename() const { return "Mais Non!"; }</tt></p>
</blockquote>




<hr>
<h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-06-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>Suppose that c and c1 are sequential containers and i is an
iterator that refers to an element of c.  Then I can insert a copy of
c1's elements into c ahead of element i by executing </p>

<blockquote>

<pre>c.insert(i, c1.begin(), c1.end());</pre>

</blockquote>

<p>If c is a vector, it is fairly easy for me to find out where the
newly inserted elements are, even though i is now invalid: </p>

<blockquote>

<pre>size_t i_loc = i - c.begin();
c.insert(i, c1.begin(), c1.end());</pre>

</blockquote>

<p>and now the first inserted element is at c.begin()+i_loc and one
past the last is at c.begin()+i_loc+c1.size().<br>
<br>
But what if c is a list?  I can still find the location of one    past the last inserted element, because i is still valid.    To find the location of the first inserted element, though,    I must execute something like </p>

<blockquote>

<pre>for (size_t n = c1.size(); n; --n)
   --i;</pre>

</blockquote>

<p>because i is now no longer a random-access iterator.<br>
<br>
Alternatively, I might write something like </p>

<blockquote>

<pre>bool first = i == c.begin();
list&lt;T&gt;::iterator j = i;
if (!first) --j;
c.insert(i, c1.begin(), c1.end());
if (first)
   j = c.begin();
else
   ++j;</pre>

</blockquote>

<p>which, although wretched, requires less overhead.<br>
<br>
But I think the right solution is to change the definition of insert
so that instead of returning void, it returns an iterator that refers
to the first element inserted, if any, and otherwise is a copy of its
first argument.&nbsp; </p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Reopened by Alisdair.
</blockquote>

<p><i>[
Post Summit Alisdair adds:
]</i></p>


<blockquote>
<p>
In addition to the original rationale for C++03, this change also gives a
consistent interface for all container insert operations i.e. they all
return an iterator to the (first) inserted item.
</p>

<p>
Proposed wording provided.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Q: why isn't this change also proposed for associative containers?
</p>

<p>
A: The returned iterator wouldn't necessarily point to a contiguous range.
</p>

<p>
Moved to Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
<sef ref="[sequence.reqmts]"> Table 83
change return type from <tt>void</tt> to <tt>iterator</tt> for the following rows:
</sef></p>

<blockquote>
<table border="1">
<caption>Table 83 -- Sequence container requirements (in addition to container)</caption>
<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note pre-/post-condition</th>
</tr>
<tr>
<td>
<tt>a.insert(p,n,t)</tt>
</td>
<td>
<tt><del>void</del> <ins>iterator</ins></tt>
</td>
<td>
Inserts <tt>n</tt> copies of <tt>t</tt> before <tt>p</tt>.
</td>
</tr>

<tr>
<td>
<tt>a.insert(p,i,j)</tt>
</td>
<td>
<tt><del>void</del> <ins>iterator</ins></tt>
</td>
<td>
Each iterator in the range <tt>[i,j)</tt> shall be 
dereferenced exactly once. 
pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>. 
Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
</td>
</tr>

<tr>
<td>
<tt>a.insert(p,il)</tt>
</td>
<td>
<tt><del>void</del> <ins>iterator</ins></tt>
</td>
<td>
<tt>a.insert(p, il.begin(), il.end())</tt>.
</td>
</tr>
</tbody></table>
</blockquote>

<p>
Add after p6 23.2.3 [sequence.reqmts]:
</p>

<blockquote>
<p>-6- ...</p>

<p><ins>
The iterator returned from <tt>a.insert(p,n,t)</tt> points to the copy of the
first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>n == 0</tt>.
</ins></p>

<p><ins>
The iterator returned from <tt>a.insert(p,i,j)</tt> points to the copy of the
first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>i == j</tt>.
</ins></p>

<p><ins>
The iterator returned from <tt>a.insert(p,il)</tt> points to the copy of the
first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>il</tt> is empty.
</ins></p>

</blockquote>

<p>
p2 23.3.2 [deque] Update class definition, change return type
from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
template &lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
  <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
</pre></blockquote>

<p>
23.3.2.3 [deque.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>

<blockquote><pre>  <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
template &lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
</pre></blockquote>

<p>
Add the following (missing) declaration
</p>

<blockquote><pre><ins>iterator insert(const_iterator position, initializer_list&lt;T&gt;);</ins>
</pre></blockquote>

<p>
23.3.3 [forwardlist] Update class definition, change return type
from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
<del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
template &lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
</pre></blockquote>

<p>
p8 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
</pre></blockquote>

<p>
Add paragraph:
</p>

<blockquote>
Returns: position.
</blockquote>

<p>
p10 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre>template &lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
</pre></blockquote>

<p>
Add paragraph:
</p>

<blockquote>
Returns: position.
</blockquote>

<p>
p12 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
</pre></blockquote>

<p>
change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>

<p>
p2 23.3.4 [list] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);

template &lt;class InputIterator&gt;
<del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);

<del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
</pre></blockquote>

<p>
23.3.4.3 [list.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);

template &lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
</pre></blockquote>

<p>
Add the following (missing) declaration
</p>

<blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
</pre></blockquote>

<p>
p2 23.4.1 [vector]
</p>

<p>
Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, T&amp;&amp; x);

<del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);

template &lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);

<del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
</pre></blockquote>

<p>
23.4.1.4 [vector.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);

template &lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
</pre></blockquote>

<p>
Add the following (missing) declaration
</p>

<blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
</pre></blockquote>


<p>
p1 23.4.2 [vector.bool] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert (const_iterator position, size_type n, const bool&amp; x);

template &lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);

  <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;bool&gt; il);
</pre></blockquote>

<p>
p5 21.4 [basic.string] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);

template&lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);

<del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt;);
</pre></blockquote>

<p>
p13 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
</pre></blockquote>

<p>
Add paragraph:
</p>

<blockquote>
<i>Returns:</i> an iterator which refers to the copy of the first inserted
character, or <tt>p</tt> if <tt>n == 0</tt>.
</blockquote>

<p>
p15 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre>template&lt;class InputIterator&gt;
  <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
</pre></blockquote>

<p>
Add paragraph:
</p>

<blockquote>
<i>Returns:</i> an iterator which refers to the copy of the first inserted
character, or <tt>p</tt> if <tt>first == last</tt>.
</blockquote>

<p>
p17 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
</p>

<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt; il);
</pre></blockquote>

<p>
Add paragraph:
</p>

<blockquote>
<i>Returns:</i> an iterator which refers to the copy of the first inserted
character, or <tt>p</tt> if <tt>il</tt> is empty.
</blockquote>



<p><b>Rationale:</b></p>

<p><i>[
The following was the C++98/03 rationale and does not necessarily apply to the
proposed resolution in the C++0X time frame:
]</i></p>


<blockquote>
<p>The LWG believes this was an intentional design decision and so is
not a defect. It may be worth revisiting for the next standard.</p>
</blockquote>




<hr>
<h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
<p><b>Section:</b> 25.2.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt McClure <b>Opened:</b> 1999-06-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>


<p><b>Proposed resolution:</b></p>
<p>Change 25.2.7 [alg.find.first.of] paragraph 2 from:</p>

<blockquote>
<p>Returns: The first iterator i in the range [first1, last1) such
that for some integer j in the range [first2, last2) ...</p>
</blockquote>

<p>to:</p>

<blockquote>
<p>Returns: The first iterator i in the range [first1, last1) such
that for some iterator j in the range [first2, last2) ...</p>
</blockquote>




<hr>
<h3><a name="151"></a>151. Can't currently clear() empty container</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>For both sequences and associative containers, a.clear() has the
semantics of erase(a.begin(),a.end()), which is undefined for an empty
container since erase(q1,q2) requires that q1 be dereferenceable
(23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
not dereferenceable.<br>
<br>
The requirement that q1 be unconditionally dereferenceable causes many
operations to be intuitively undefined, of which clearing an empty
container is probably the most dire.<br>
<br>
Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
q2) is required to be a valid range, stating that q1 and q2 must be
iterators or certain kinds of iterators is unnecessary.
</p>


<p><b>Proposed resolution:</b></p>
<p>In 23.1.1, paragraph 3, change:</p>
<blockquote>
  <p>p and q2 denote valid iterators to a, q and q1 denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range
  in a</p>
</blockquote>
<p>In 23.1.2, paragraph 7, change:</p>
<blockquote>
  <p>p and q2 are valid iterators to a, q and q1 are valid dereferenceable
  iterators to a, [q1, q2) is a valid range</p>
</blockquote>
<p>to</p>
<blockquote>
  <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
  into a</p>
</blockquote>




<hr>
<h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</h3>
<p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
because there is no function <tt>is()</tt> which only takes a character as
argument. Also, in the effects clause (paragraph 3), the semantic is also kept
vague.</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
clause from:</p>
<blockquote>
  <p>"... such that <tt>is(*p)</tt>
would..."</p>
</blockquote>
<p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
 would...."</p>





<hr>
<h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3>
<p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p>
<p><b>Discussion:</b></p>
<p>The description of the array version of <tt>narrow()</tt> (in
paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
takes only three arguments because in addition to the range a default
character is needed.</p>

<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
two signatures followed by a <b>Returns</b> clause that only addresses
one of them.</p>



<p><b>Proposed resolution:</b></p>
<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
paragraph 10 from:</p>
<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>

<p>to:</p>
<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to), 
respectively.</p>

<p>Change 22.4.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
<pre>        char        narrow(char c, char /*dfault*/) const;
        const char* narrow(const char* low, const char* high,
                           char /*dfault*/, char* to) const;</pre>
<pre>        Returns: do_narrow(low, high, to).</pre>
<p>to:</p>
<pre>        char        narrow(char c, char dfault) const;
        const char* narrow(const char* low, const char* high,
                           char dfault, char* to) const;</pre>
<pre>        Returns: do_narrow(c, dfault) or
                 do_narrow(low, high, dfault, to), respectively.</pre>

<p><i>[Kona: 1) the problem occurs in additional places, 2) a user
defined version could be different.]</i></p>


<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
the LWG. He could find no other places the problem occurred. He
asks for clarification of the Kona "a user defined
version..." comment above.  Perhaps it was a circuitous way of
saying "dfault" needed to be uncommented?]</i></p>


<p><i>[Post-Toronto: the issues list maintainer has merged in the
proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
same paragraphs.]</i></p>






<hr>
<h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The table in paragraph 7 for the length modifier does not list the length
modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
standard asks the implementation to do undefined things when using <tt>scanf()</tt>
(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
is actually a problem I found quite often in production code, too).</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
Modifier table to say that for <tt>double</tt> a length modifier
<tt>l</tt> is to be used.</p>


<p><b>Rationale:</b></p>
<p>The standard makes an embarrassing beginner's mistake.</p>




<hr>
<h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></h3>
<p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There are conflicting statements about where the class
<tt>Init</tt> is defined. According to 27.4 [iostream.objects] paragraph 2
it is defined as <tt>basic_ios::Init</tt>, according to 27.5.2 [ios.base] it is defined as <tt>ios_base::Init</tt>.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 27.4 [iostream.objects] paragraph 2 from
"<tt>basic_ios::Init"</tt> to
"<tt>ios_base::Init"</tt>.</p>


<p><b>Rationale:</b></p>
<p>Although not strictly wrong, the standard was misleading enough to warrant
the change.</p>




<hr>
<h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3>
<p><b>Section:</b> 27.5.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There is a small discrepancy between the declarations of
<tt>imbue()</tt>: in 27.5.2 [ios.base] the argument is passed as
<tt>locale const&amp;</tt> (correct), in 27.5.2.3 [ios.base.locales] it
is passed as <tt>locale const</tt> (wrong).</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.5.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
from "<tt>locale const" to "locale
const&amp;".</tt></p>




<hr>
<h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3>
<p><b>Section:</b> 27.6.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The default behavior of <tt>setbuf()</tt> is described only for the
situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
namely to do nothing.  What has to be done in other situations&nbsp;
is not described although there is actually only one reasonable
approach, namely to do nothing, too.</p> 

<p>Since changing the buffer would almost certainly mess up most
buffer management of derived classes unless these classes do it
themselves, the default behavior of <tt>setbuf()</tt> should always be
to do nothing.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 27.6.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
to: "Default behavior: Does nothing. Returns this."</p>




<hr>
<h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3>
<p><b>Section:</b> 27.6.2.4.3 [streambuf.virt.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of the meaning of the result of
<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
this function only reads the current character but does not extract
it, <tt>uflow()</tt> would extract the current character. This should
be fixed to use <tt>sbumpc()</tt> instead.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 27.6.2.4.3 [streambuf.virt.get] paragraph 1,
<tt>showmanyc()</tt>returns clause, by replacing the word
"supplied" with the words "extracted from the
stream".</p>




<hr>
<h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3>
<p><b>Section:</b> 27.7.1.1 [istream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The paragraph 4 refers to the function <tt>exception()</tt> which
is not defined. Probably, the referred function is
<tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted], paragraph 1,
27.7.2.1 [ostream], paragraph 3, and 27.7.2.6.1 [ostream.formatted.reqmts],
paragraph 1, change "<tt>exception()" to
"exceptions()"</tt>.</p>

<p><i>[Note to Editor: "exceptions" with an "s"
is the correct spelling.]</i></p>






<hr>
<h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3>
<p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The note in the second paragraph pretends that the first argument
is an object of type <tt>istream_iterator</tt>. This is wrong: It is
an object of type <tt>istreambuf_iterator</tt>.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 27.7.1.2.2 [istream.formatted.arithmetic] from:</p>
<blockquote>
  <p>The first argument provides an object of the istream_iterator class...</p>
</blockquote>
<p>to</p>
<blockquote>
  <p>The first argument provides an object of the istreambuf_iterator class...</p>
</blockquote>





<hr>
<h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3>
<p><b>Section:</b> 22.4.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 22.4.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
as taking a fill character as an argument, but the description of the
function does not say whether the character is used at all and, if so,
in which way. The same holds for any format control parameters that
are accessible through the ios_base&amp; argument, such as the
adjustment or the field width. Is strftime() supposed to use the fill
character in any way? In any case, the specification of
time_put.do_put() looks inconsistent to me.<br> <br> Is the
signature of do_put() wrong, or is the effects clause incomplete?</p>


<p><b>Proposed resolution:</b></p>
<p>Add the following note after 22.4.5.3.2 [locale.time.put.virtuals]
paragraph 2:</p>
<blockquote>
  <p>  [Note: the <tt>fill</tt> argument may be used in the implementation-defined  formats, or by derivations.  A space character is a reasonable default
  for this argument. --end Note]</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>The LWG felt that while the normative text was correct,
users need some guidance on what to pass for the <tt>fill</tt>
argument since the standard doesn't say how it's used.</p>




<hr>
<h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3>
<p><b>Section:</b> 27.7.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
functions falling into one of the groups "formatted output functions"
and "unformatted output functions" calls any stream buffer function
which might call a virtual function other than <tt>overflow()</tt>. Basically
this is fine but this implies that <tt>sputn()</tt> (this function would call
the virtual function <tt>xsputn()</tt>) is never called by any of the standard
output functions. Is this really intended? At minimum it would be convenient to
call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
under "unformatted output functions").</p>
<p>In addition, I guess that the sentence starting with "They may use other
public members of <tt>basic_ostream</tt> ..." probably was intended to
start with "They may use other public members of <tt>basic_streamuf</tt>..."
although the problem with the virtual members exists in both cases.</p>
<p>I see two obvious resolutions:</p>
<ol>
  <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
    called by any ostream member and that this is intended.</li>
  <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
    Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
</ol>


<p><b>Proposed resolution:</b></p>
<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
<blockquote>
  <p>They may use other public members of basic_ostream except that they do not
  invoke any virtual members of rdbuf() except overflow().</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>They may use other public members of basic_ostream except that they shall
  not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
  sync().</p>
</blockquote>

<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
PJP why the standard is written this way.]</i></p>


<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
LWG. He comments: The rules can be made a little bit more specific if
necessary be explicitly spelling out what virtuals are allowed to be
called from what functions and eg to state specifically that flush()
is allowed to call sync() while other functions are not.]</i></p>






<hr>
<h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3>
<p><b>Section:</b> 27.7.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 4 states that the length is determined using
<tt>traits::length(s)</tt>.  Unfortunately, this function is not
defined for example if the character type is <tt>wchar_t</tt> and the
type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
the character type is <tt>char</tt> and the type of <tt>s</tt> is
either <tt>signed char const*</tt> or <tt>unsigned char
const*</tt>.</p>


<p><b>Proposed resolution:</b></p>
<p>Change 27.7.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
<blockquote>
  <p>Effects: Behaves like an formatted inserter (as described in
  lib.ostream.formatted.reqmts) of out. After a sentry object is
  constructed it inserts characters. The number of characters starting
  at s to be inserted is traits::length(s). Padding is determined as
  described in lib.facet.num.put.virtuals. The traits::length(s)
  characters starting at s are widened using out.widen
  (lib.basic.ios.members). The widened characters and any required
  padding are inserted into out. Calls width(0).</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>Effects: Behaves like a formatted inserter (as described in
  lib.ostream.formatted.reqmts) of out. After a sentry object is
  constructed it inserts <i>n</i> characters starting at <i>s</i>,
  where <i>n</i> is the number that would be computed as if by:</p>
  <ul>
  <li>traits::length(s) for the overload where the first argument is of
    type basic_ostream&lt;charT, traits&gt;&amp; and the second is
    of type const charT*, and also for the overload where the first
    argument is of type basic_ostream&lt;char, traits&gt;&amp; and
    the second is of type const char*.</li>
  <li>std::char_traits&lt;char&gt;::length(s) 
    for the overload where the first argument is of type 
    basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
    const char*.</li>
  <li>traits::length(reinterpret_cast&lt;const char*&gt;(s)) 
    for the other two overloads.</li>
  </ul>
  <p>Padding is determined as described in
  lib.facet.num.put.virtuals. The <i>n</i> characters starting at
  <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
  widened characters and any required padding are inserted into
  out. Calls width(0).</p>
</blockquote>

<p><i>[Santa Cruz: Matt supplied new wording]</i></p>


<p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
  number that would be computed as if by"]</i></p>
 



<p><b>Rationale:</b></p>
<p>We have five separate cases.  In two of them we can use the
user-supplied traits class without any fuss.  In the other three we
try to use something as close to that user-supplied class as possible.
In two cases we've got a traits class that's appropriate for
char and what we've got is a const signed char* or a const
unsigned char*; that's close enough so we can just use a reinterpret
cast, and continue to use the user-supplied traits class.  Finally,
there's one case where we just have to give up: where we've got a
traits class for some arbitrary charT type, and we somehow have to
deal with a const char*.  There's nothing better to do but fall back
to char_traits&lt;char&gt;</p>





<hr>
<h3><a name="168"></a>168. Typo: formatted vs. unformatted</h3>
<p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The first paragraph begins with a descriptions what has to be done
in <i>formatted</i> output functions. Probably this is a typo and the
paragraph really want to describe unformatted output functions...</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.7.2.7 [ostream.unformatted] paragraph 1, the first and last
sentences, change the word "formatted" to
"unformatted":</p>
<blockquote>
  <p>"Each <b>unformatted </b> output function begins ..."<br>
  "... value specified for the <b>unformatted </b>  output 
  function."</p>
</blockquote>




<hr>
<h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3>
<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 8, Notes, of this section seems to mandate an extremely
inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
especially in view of the restriction that <tt>basic_ostream</tt>
member functions are not allowed to use <tt>xsputn()</tt> (see 27.7.2.1 [ostream]): For each character to be inserted, a new buffer
is to be created.</p> 
<p>Of course, the resolution below requires some handling of
simultaneous input and output since it is no longer possible to update
<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
solution is to handle this in <tt>underflow()</tt>.</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.8.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
"at least" as in the following:</p>
<blockquote>
  <p>To make a write position available, the function reallocates (or initially
  allocates) an array object with a sufficient number of elements to hold the
  current array object (if any), plus <b>at least</b> one additional write
  position.</p>
</blockquote>




<hr>
<h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3>
<p><b>Section:</b> 27.8.4 [stringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The classes <tt>basic_stringstream</tt> (27.8.4 [stringstream]),
<tt>basic_istringstream</tt> (27.8.2 [istringstream]), and
<tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) are inconsistent
in their definition of the type <tt>traits_type</tt>: For
<tt>istringstream</tt>, this type is defined, for the other two it is
not. This should be consistent.</p>


<p><b>Proposed resolution:</b></p>
<p><b>Proposed resolution:</b></p> <p>To the declarations of
<tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) and
<tt>basic_stringstream</tt> (27.8.4 [stringstream]) add:</p>
<blockquote>
<pre>typedef traits traits_type;</pre>
</blockquote>




<hr>
<h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3>
<p><b>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Overridden virtual functions, seekpos()</p> <p>In 27.9.1.1 [filebuf] paragraph 3, it is stated that a joint input and
output position is maintained by <tt>basic_filebuf</tt>. Still, the
description of <tt>seekpos()</tt> seems to talk about different file
positions. In particular, it is unclear (at least to me) what is
supposed to happen to the output buffer (if there is one) if only the
input position is changed. The standard seems to mandate that the
output buffer is kept and processed as if there was no positioning of
the output position (by changing the input position). Of course, this
can be exactly what you want if the flag <tt>ios_base::ate</tt> is
set. However, I think, the standard should say something like
this:</p>
<ul>
  <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
    changed and the call fails. Otherwise, the joint read and write position is
    altered to correspond to <tt>sp</tt>.</li>
  <li>If there is an output buffer, the output sequences is updated and any
    unshift sequence is written before the position is altered.</li>
  <li>If there is an input buffer, the input sequence is updated after the
    position is altered.</li>
</ul>
<p>Plus the appropriate error handling, that is...</p>


<p><b>Proposed resolution:</b></p>
<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
paragraph 14 from:</p>
<blockquote>
  <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
  ios_base::out);</p>
  <p>Alters the file position, if possible, to correspond to the position stored
  in sp (as described below).</p>
  <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
  the input sequence</p>
  <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
  any unshift sequence, and set the file position to sp.</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
  ios_base::out);</p>
  <p>Alters the file position, if possible, to correspond to the position stored
  in sp (as described below). Altering the file position performs as follows:</p>
  <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
  write any unshift sequence;</p>
  <p>2. set the file position to sp;</p>
  <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
  <p>where om is the open mode passed to the last call to open(). The operation
  fails if is_open() returns false.</p>
</blockquote>

<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>

<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>






<hr>
<h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Greg Comeau, Dietmar K�hl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 27.7.1.1 [istream] the function
<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
argument. However, in 27.7.1.3 [istream.unformatted]
paragraph 23 the first argument is of type <tt>int.</tt></p>

<p>As far as I can see this is not really a contradiction because
everything is consistent if <tt>streamsize</tt> is typedef to be
<tt>int</tt>. However, this is almost certainly not what was
intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>

<p>Darin Adler also
submitted this issue, commenting: Either 27.6.1.1 should be modified
to show a first parameter of type int, or 27.6.1.3 should be modified
to show a first parameter of type streamsize and use
numeric_limits&lt;streamsize&gt;::max.</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.7.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
of <tt>int</tt> in the description of <tt>ignore()</tt> to
<tt>streamsize</tt>.</p>




<hr>
<h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3>
<p><b>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Greg Comeau, Dietmar K�hl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In 27.9.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
object of type <tt>streamsize</tt> as second argument. However, in
27.9.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
<tt>int</tt>.
</p>

<p>
As far as I can see this is not really a contradiction because
everything is consistent if <tt>streamsize</tt> is typedef to be
<tt>int</tt>. However, this is almost certainly not what was
intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
</p>



<p><b>Proposed resolution:</b></p>
<p>In 27.9.1.5 [filebuf.virtuals] paragraph 9, change all uses of
<tt>int</tt> in the description of <tt>setbuf()</tt> to
<tt>streamsize</tt>.</p>




<hr>
<h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3>
<p><b>Section:</b> D.8 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>


<p><b>Proposed resolution:</b></p>
<p>Change D.8 [depr.ios.members] paragraph 1 from "<tt>typedef
OFF_T streampos;</tt>" to "<tt>typedef POS_T
streampos;</tt>"</p>




<hr>
<h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3>
<p><b>Section:</b> D.8 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>According to paragraph 8 of this section, the methods
<tt>basic_streambuf::pubseekpos()</tt>,
<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
"may" be overloaded by a version of this function taking the
type <tt>ios_base::open_mode</tt> as last argument argument instead of
<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
in this section to be an alias for one of the integral types). The
clause specifies, that the last argument has a default argument in
three cases.  However, this generates an ambiguity with the overloaded
version because now the arguments are absolutely identical if the last
argument is not specified.</p>


<p><b>Proposed resolution:</b></p>
<p>In D.8 [depr.ios.members] paragraph 8, remove the default arguments for
<tt>basic_streambuf::pubseekpos()</tt>,
<tt>basic_ifstream::open()</tt>, and
<tt>basic_ofstream::open().</tt></p>




<hr>
<h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3>
<p><b>Section:</b> D.8 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The "overload" for the function <tt>exceptions()</tt> in
paragraph 8 gives the impression that there is another function of
this function defined in class <tt>ios_base</tt>. However, this is not
the case. Thus, it is hard to tell how the semantics (paragraph 9) can
be implemented: "Call the corresponding member function specified
in clause 27 [input.output]."</p>


<p><b>Proposed resolution:</b></p>
<p>In D.8 [depr.ios.members] paragraph 8, move the declaration of the
function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>




<hr>
<h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-07-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Currently the following will not compile on two well-known standard
library implementations:</p>

<blockquote>
  <pre>#include &lt;set&gt;
using namespace std;

void f(const set&lt;int&gt; &amp;s)
{
  set&lt;int&gt;::iterator i;
  if (i==s.end()); // s.end() returns a const_iterator
}</pre>
</blockquote>

<p>
The reason this doesn't compile is because operator== was implemented
as a member function of the nested classes set:iterator and
set::const_iterator, and there is no conversion from const_iterator to
iterator. Surprisingly, (s.end() == i) does work, though, because of
the conversion from iterator to const_iterator.
</p>

<p>
I don't see a requirement anywhere in the standard that this must
work. Should there be one?  If so, I think the requirement would need
to be added to the tables in section 24.1.1. I'm not sure about the
wording.  If this requirement existed in the standard, I would think
that implementors would have to make the comparison operators
non-member functions.</p>

<p>This issues was also raised on comp.std.c++ by Darin
Adler.&nbsp; The example given was:</p>

<blockquote>
  <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
std::deque&lt;int&gt;::const_iterator ci)
{
return i == ci;
}</pre>
</blockquote>

<p>Comment from John Potter:</p>
<blockquote>
    <p>
    In case nobody has noticed, accepting it will break reverse_iterator.
    </p>

    <p>
    The fix is to make the comparison operators templated on two types.
    </p>

    <pre>    template &lt;class Iterator1, class Iterator2&gt;
    bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
                     reverse_iterator&lt;Iterator2&gt; const&amp; y);
    </pre>

    <p>
    Obviously:  return x.base() == y.base();
    </p>

    <p>
    Currently, no reverse_iterator to const_reverse_iterator compares are
    valid.
    </p>

    <p>
    BTW, I think the issue is in support of bad code.  Compares should be
    between two iterators of the same type.  All std::algorithms require
    the begin and end iterators to be of the same type. 
    </p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>Insert this paragraph after 23.2 [container.requirements] paragraph 7:</p>
<blockquote>
  <p>In the expressions</p>
  <pre>    i == j
    i != j
    i &lt; j
    i &lt;= j
    i &gt;= j
    i &gt; j
    i - j
  </pre>
  <p>Where i and j denote objects of a container's iterator type,
  either or both may be replaced by an object of the container's
  const_iterator type referring to the same element with no
  change in semantics.</p>
</blockquote>

<p><i>[post-Toronto: Judy supplied a proposed resolution saying that
<tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
iterator comparison and difference operations.]</i></p>


<p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
explicitly listed expressions; there was concern that the previous
proposed resolution was too informal.]</i></p>



<p><b>Rationale:</b></p>
<p>
The LWG believes it is clear that the above wording applies only to
the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
where <tt>X</tt> is a container.  There is no requirement that
<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
can be mixed.  If mixing them is considered important, that's a
separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
</p>




<hr>
<h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 1999-07-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It is the constness of the container which should control whether
it can be modified through a member function such as erase(), not the
constness of the iterators. The iterators only serve to give
positioning information.</p>

<p>Here's a simple and typical example problem which is currently very
difficult or impossible to solve without the change proposed
below.</p>

<p>Wrap a standard container C in a class W which allows clients to
find and read (but not modify) a subrange of (C.begin(), C.end()]. The
only modification clients are allowed to make to elements in this
subrange is to erase them from C through the use of a member function
of W.</p>

<p><i>[
post Bellevue, Alisdair adds:
]</i></p>


<blockquote>
<p>
This issue was implemented by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
for everything but <tt>basic_string</tt>.
</p>

<p>
Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
we forgot to amend in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
so we might open this issue for that
single container?
</p>
</blockquote>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
This was a fix that was intended for all standard library containers,
and has been done for other containers, but string was missed.
</p>
<p>
The wording updated.
</p>
<p>
We did not make the change in <tt>replace</tt>, because this change would affect
the implementation because the string may be written into. This is an
issue that should be taken up by concepts.
</p>
<p>
We note that the supplied wording addresses the initializer list provided in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Update the following signature in the <tt>basic_string</tt> class template definition in
21.4 [basic.string], p5:
</p>
<blockquote><pre>namespace std {
  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
    class Allocator = allocator&lt;charT&gt; &gt;
  class basic_string {

    ...

    iterator insert(<ins>const_</ins>iterator p, charT c);
    void insert(<ins>const_</ins>iterator p, size_type n, charT c);
    template&lt;class InputIterator&gt;
      void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
    void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);

    ...

    iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
    iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);

    ...

  };
}
</pre></blockquote>

<p>
Update the following signatures in 21.4.6.4 [string::insert]:
</p>

<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
void insert(<ins>const_</ins>iterator p, size_type n, charT c);
template&lt;class InputIterator&gt;
  void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
</pre></blockquote>

<p>
Update the following signatures in 21.4.6.5 [string::erase]:
</p>

<blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
</pre></blockquote>



<p><b>Rationale:</b></p>
<p>The issue was discussed at length. It was generally agreed that 1)
There is no major technical argument against the change (although
there is a minor argument that some obscure programs may break), and
2) Such a change would not break const correctness. The concerns about
making the change were 1) it is user detectable (although only in
boundary cases), 2) it changes a large number of signatures, and 3) it
seems more of a design issue that an out-and-out defect.</p>

<p>The LWG believes that this issue should be considered as part of a
general review of const issues for the next revision of the
standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>




<hr>
<h3><a name="181"></a>181. make_pair() unintended behavior</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The claim has surfaced in Usenet that expressions such as<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
<br>
are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
<br>
I doubt anyone intended that behavior...
</p>


<p><b>Proposed resolution:</b></p>
<p>In 20.3 [utility], paragraph 1 change the following
declaration of make_pair():</p>
<blockquote>
  <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
</blockquote>
<p>to:</p>
<blockquote>
  <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
</blockquote>
<p>  In 20.3.5 [pairs] paragraph 7 and the line before, change:</p>
<blockquote>
<pre>template &lt;class T1, class T2&gt;
pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
</blockquote>
<p>to:</p>
<blockquote>
<pre>template &lt;class T1, class T2&gt;
pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
</blockquote>
<p>and add the following footnote to the effects clause:</p>
<blockquote>
  <p> According to 12.8 [class.copy], an implementation is permitted
  to not perform a copy of an argument, thus avoiding unnecessary
  copies.</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>Two potential fixes were suggested by Matt Austern and Dietmar
K�hl, respectively, 1) overloading with array arguments, and 2) use of
a reference_traits class with a specialization for arrays.  Andy
Koenig suggested changing to pass by value. In discussion, it appeared
that this was a much smaller change to the standard that the other two
suggestions, and any efficiency concerns were more than offset by the
advantages of the solution. Two implementors reported that the
proposed resolution passed their test suites.</p>




<hr>
<h3><a name="182"></a>182. Ambiguous references to size_t</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Al Stevens <b>Opened:</b> 1999-08-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Many references to <tt> size_t</tt> throughout the document
omit the <tt> std::</tt> namespace qualification.</p> <p>For
example, 17.6.3.6 [replacement.functions] paragraph 2:</p>
<blockquote>
<pre> operator new(size_t)
 operator new(size_t, const std::nothrow_t&amp;)
 operator new[](size_t)
 operator new[](size_t, const std::nothrow_t&amp;)</pre>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>   In 17.6.3.6 [replacement.functions] paragraph 2: replace:</p>
<blockquote>
<p><tt>     - operator new(size_t)<br>
     - operator new(size_t, const std::nothrow_t&amp;)<br>
     - operator new[](size_t)<br>
     - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
</blockquote>
<p>    by:</p>
<blockquote>
<pre>- operator new(std::size_t)
- operator new(std::size_t, const std::nothrow_t&amp;)
- operator new[](std::size_t)
- operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
</blockquote>
<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
<blockquote>
  <p>The typedef members pointer, const_pointer, size_type, and difference_type
  are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
</blockquote>
<p>&nbsp;by:</p>
<blockquote>
  <p>The typedef members pointer, const_pointer, size_type, and difference_type
  are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
  respectively.</p>
</blockquote>
<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
<blockquote>
  <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
  <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
  is unspecified when or how often this function is called. The use of hint is
  unspecified, but intended as an aid to locality if an implementation so
  desires.</p>
</blockquote>
<p>by:</p>
<blockquote>
  <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
  <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
  it is unspecified when or how often this function is called. The use of hint
  is unspecified, but intended as an aid to locality if an implementation so
  desires.</p>
</blockquote>
<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
<blockquote>
  <p>In Table 37, X denotes a Traits class defining types and functions for the
  character container type CharT; c and d denote values of type CharT; p and q
  denote values of type const CharT*; s denotes a value of type CharT*; n, i and
  j denote values of type size_t; e and f denote values of type X::int_type; pos
  denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
</blockquote>
<p>by:</p>
<blockquote>
  <p>In Table 37, X denotes a Traits class defining types and functions for the
  character container type CharT; c and d denote values of type CharT; p and q
  denote values of type const CharT*; s denotes a value of type CharT*; n, i and
  j denote values of type std::size_t; e and f denote values of type X::int_type;
  pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
</blockquote>
<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
X::length(p): "size_t" by "std::size_t".</p>
<p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
&nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
    by:<br>
&nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
<p>   In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the declaration of    template &lt;class charT&gt; class ctype.<br>
<br>
   In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
<br>
&nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
&nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
&nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>


<p><b>Rationale:</b></p>
<p>The LWG believes correcting names like <tt>size_t</tt> and
<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
to be essentially editorial.  There there can't be another size_t or
ptrdiff_t meant anyway because, according to 17.6.3.3.4 [extern.types],</p>

<blockquote><p>
For each type T from the Standard C library, the types ::T and std::T
are reserved to the implementation and, when defined, ::T shall be
identical to std::T.
</p></blockquote>

<p>The issue is treated as a Defect Report to make explicit the Project
Editor's authority to make this change.</p>

<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
request of the LWG.]</i></p>


<p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
address use of the name <tt>size_t</tt> in contexts outside of
namespace std, such as in the description of <tt>::operator new</tt>.
The proposed changes should be reviewed to make sure they are
correct.]</i></p>


<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
them to be correct.]</i></p>







<hr>
<h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3>
<p><b>Section:</b> 27.7.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-07-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.7.3 [std.manip] paragraph 3 says (clause numbering added for
exposition):</p>
<blockquote>
<p>Returns: An object s of unspecified type such that if [1] out is an (instance
of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
called, and if [2] in is an (instance of) basic_istream then the expression
in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
has type istream&amp; and value in.</p>
</blockquote>
<p>Given the definitions [1] and [2] for out and in, surely [3] should read:
"The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
[4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
..."</p>
<p>If the wording in the standard is correct, I can see no way of implementing
any of the manipulators so that they will work with wide character streams.</p>
<p>e.g. wcout &lt;&lt; setbase( 16 );</p>
<p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
doesn't).</p>
<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
8. In addition, Para 6 [setfill] has a similar error, but relates only to
ostreams.</p>
<p>I'd be happier if there was a better way of saying this, to make it clear
that the value of the expression is "the same specialization of
basic_ostream as out"&amp;</p>


<p><b>Proposed resolution:</b></p>
<p>Replace section 27.7.3 [std.manip] except paragraph 1 with the
following:</p>
<blockquote>
<p>2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each
function.<br>
<br>
<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
<br>
-3- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
as if f(s, mask) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if
f(s, mask) were called. The function f can be defined as:*<br>
<br>
[Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws) clears ios_base::skipws in the format flags stored in the
basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt; noskipws), and the expression cout &lt;&lt; resetiosflags(ios_base::showbase) clears
ios_base::showbase in the format flags stored in the basic_ostream&lt;charT,traits&gt; object cout (the same as cout &lt;&lt;
noshowbase). --- end footnote]<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
&nbsp;&nbsp; {<br>
&nbsp;&nbsp; //  reset specified flags<br>
&nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
&nbsp;&nbsp; return str;<br>
&nbsp;&nbsp; }<br>
</tt><br>
The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
<br>
&nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
<br>
-4- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
as if f(s, mask) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if f(s,
mask) were called. The function f can be defined as:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
&nbsp;&nbsp; {<br>
&nbsp;&nbsp; //  set specified flags<br>
&nbsp;&nbsp; str.setf(mask);<br>
&nbsp;&nbsp; return str;<br>
&nbsp;&nbsp; }<br>
</tt><br>
The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
<br>
<tt>smanip setbase(int base);</tt><br>
<br>
-5- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
as if f(s, base) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if f(s,
base) were called. The function f can be defined as:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
&nbsp;&nbsp; {<br>
&nbsp;&nbsp; //  set  basefield<br>
&nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
&nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
&nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
&nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
&nbsp;&nbsp; return str;<br>
&nbsp;&nbsp; }<br>
</tt><br>
The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
<br>
<tt>smanip setfill(char_type c);<br>
</tt><br>
-6- Returns: An object s of unspecified type such that if out is (or is derived from) basic_ostream&lt;charT,traits&gt; and c has type charT then the
expression out&lt;&lt;s behaves as if f(s, c) were called. The function f can be
defined as:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
&nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
&nbsp;&nbsp; {<br>
&nbsp;&nbsp; //  set fill character<br>
&nbsp;&nbsp; str.fill(c);<br>
&nbsp;&nbsp; return str;<br>
&nbsp;&nbsp; }<br>
</tt><br>
The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
<br>
<tt>smanip setprecision(int n);</tt><br>
<br>
-7- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
as if f(s, n) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if f(s, n)
were called. The function f can be defined as:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
&nbsp;&nbsp; {<br>
&nbsp;&nbsp; //  set precision<br>
&nbsp;&nbsp; str.precision(n);<br>
&nbsp;&nbsp; return str;<br>
&nbsp;&nbsp; }<br>
</tt><br>
The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
.<br>
<tt>smanip setw(int n);<br>
</tt><br>
-8- Returns: An object s of unspecified type such that if out is an instance of basic_ostream&lt;charT,traits&gt; then the expression out&lt;&lt;s behaves
as if f(s, n) were called, or if in is an instance of basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s behaves as if f(s, n)
were called. The function f can be defined as:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
&nbsp;&nbsp; {<br>
&nbsp;&nbsp; //  set width<br>
&nbsp;&nbsp; str.width(n);<br>
&nbsp;&nbsp; return str;<br>
&nbsp;&nbsp; }<br>
</tt><br>
The expression out&lt;&lt;s has type
basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
in.
</p>
</blockquote>

<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
the proposed resolution.]</i></p>


<p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves
the same paragraphs.]</i></p>


<p><i>[Post-Tokyo: The issues list maintainer combined the proposed
resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
intertwined that dealing with them separately appear fraught with
error.  The full text was supplied by Bill Plauger; it was cross
checked against changes supplied by Andy Sawyer. It should be further
checked by the LWG.]</i></p>






<hr>
<h3><a name="184"></a>184. numeric_limits&lt;bool&gt; wording problems</h3>
<p><b>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 1999-07-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>bools are defined by the standard to be of integer types, as per
3.9.1 [basic.fundamental] paragraph 7.  However "integer types"
seems to have a special meaning for the author of 18.2. The net effect
is an unclear and confusing specification for
numeric_limits&lt;bool&gt; as evidenced below.</p>

<p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
types, the number of non-sign bits in the representation.</p>

<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
arithmetical value converts to true.</p>

<p>I don't think it makes sense at all to require
numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
be meaningful.</p>

<p>The standard defines what constitutes a signed (resp. unsigned) integer
types. It doesn't categorize bool as being signed or unsigned. And the set of
values of bool type has only two elements.</p>

<p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
to be meaningful.</p>

<p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
<blockquote>
  <p>For integer types, specifies the base of the representation.186)</p>
</blockquote>

<p>This disposition is at best misleading and confusing for the standard
requires a "pure binary numeration system" for integer types as per
3.9.1/7</p>

<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
BCD)."&nbsp; This also erroneous as the standard never defines any integer
types with base representation other than 2.</p>

<p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>


<p><b>Proposed resolution:</b></p>
<p>Append to the end of 18.3.1.5 [numeric.special]:</p>
<blockquote>
  <p>The specialization for bool shall be provided as follows:</p>
  <pre>    namespace std {
       template&lt;&gt; class numeric_limits&lt;bool&gt; {
       public:
         static const bool is_specialized = true;
         static bool min() throw() { return false; }
         static bool max() throw() { return true; }

         static const int  digits = 1;
         static const int  digits10 = 0;
         static const bool is_signed = false;
         static const bool is_integer = true;
         static const bool is_exact = true;
         static const int  radix = 2;
         static bool epsilon() throw() { return 0; }
         static bool round_error() throw() { return 0; }

         static const int  min_exponent = 0;
         static const int  min_exponent10 = 0;
         static const int  max_exponent = 0;
         static const int  max_exponent10 = 0;

         static const bool has_infinity = false;
         static const bool has_quiet_NaN = false;
         static const bool has_signaling_NaN = false;
         static const float_denorm_style has_denorm = denorm_absent;
         static const bool has_denorm_loss = false;
         static bool infinity() throw() { return 0; }
         static bool quiet_NaN() throw() { return 0; }
         static bool signaling_NaN() throw() { return 0; }
         static bool denorm_min() throw() { return 0; }

         static const bool is_iec559 = false;
         static const bool is_bounded = true;
         static const bool is_modulo = false;

         static const bool traps = false;
         static const bool tinyness_before = false;
         static const float_round_style round_style = round_toward_zero;
       };
     }</pre>
</blockquote>

<p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
rather than more general wording in the original proposed
resolution.]</i></p>


<p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
Josuttis provided the above wording.]</i></p>






<hr>
<h3><a name="185"></a>185. Questionable use of term "inline"</h3>
<p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> UK Panel <b>Opened:</b> 1999-07-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 4 of 20.8 [function.objects] says:</p>
<blockquote>
  <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
  a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
  the addition and the negation. end example]</p>
</blockquote>
<p>(Note: The "addition" referred to in the above is in para 3) we can
find no other wording, except this (non-normative) example which suggests that
any "inlining" will take place in this case.</p>
<p>Indeed both:</p>
<blockquote>
  <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
  unspecified whether any global functions in the C++ Standard Library
  are defined as inline (7.1.2).</p>
</blockquote>
<p>and</p>
<blockquote>
  <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
  unspecified whether any member functions in the C++ Standard Library
  are defined as inline (7.1.2).</p>
</blockquote>
<p>take care to state that this may indeed NOT be the case.</p>
<p>Thus the example "mandates" behavior that is explicitly
not required elsewhere.</p>


<p><b>Proposed resolution:</b></p>
<p>In 20.8 [function.objects] paragraph 1, remove the sentence:</p>
<blockquote>
<p>They are important for the effective use of the library.</p>
</blockquote>
<p>Remove 20.8 [function.objects] paragraph 2, which reads:</p>
<blockquote>
  <p> Using function objects together with function templates
  increases the expressive power of the library as well as making the
  resulting code much more efficient.</p>
</blockquote>
<p>In 20.8 [function.objects] paragraph 4, remove the sentence:</p>
<blockquote>
  <p>The corresponding functions will inline the addition and the
  negation.</p>
</blockquote>

<p><i>[Kona: The LWG agreed there was a defect.]</i></p>

<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>






<hr>
<h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3>
<p><b>Section:</b> 20.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Darin Adler <b>Opened:</b> 1999-08-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In section 20.5.2 [bitset.members], paragraph 13 defines the
bitset::set operation to take a second parameter of type int. The
function tests whether this value is non-zero to determine whether to
set the bit to true or false. The type of this second parameter should
be bool. For one thing, the intent is to specify a Boolean value. For
another, the result type from test() is bool. In addition, it's
possible to slice an integer that's larger than an int. This can't
happen with bool, since conversion to bool has the semantic of
translating 0 to false and any non-zero value to true.</p>


<p><b>Proposed resolution:</b></p>
<p>In 20.5 [template.bitset] Para 1 Replace:</p>
<blockquote>
<pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
</blockquote>
<p>With:</p>
<blockquote>
  <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
</blockquote>
<p>In 20.5.2 [bitset.members] Para 12(.5) Replace:</p>
<blockquote>
  <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
</blockquote>
<p>With:</p>
<blockquote>
  <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
</blockquote>

<p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
on better P/R wording.]</i></p>

<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>



<p><b>Rationale:</b></p>
<p><tt>bool</tt> is a better choice.  It is believed that binary
compatibility is not an issue, because this member function is
usually implemented as <tt>inline</tt>, and because it is already
the case that users cannot rely on the type of a pointer to a
nonvirtual member of a standard library class.</p>





<hr>
<h3><a name="187"></a>187. iter_swap underspecified</h3>
<p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of iter_swap in 25.2.2 paragraph 7,says that it
``exchanges the values'' of the objects to which two iterators
refer.<br> <br> What it doesn't say is whether it does so using swap
or using the assignment operator and copy constructor.<br> <br> This
question is an important one to answer, because swap is specialized to
work efficiently for standard containers.<br> For example:</p>
<blockquote>
<pre>vector&lt;int&gt; v1, v2;
iter_swap(&amp;v1, &amp;v2);</pre>
</blockquote>
<p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
Or is it equivalent to</p>
<blockquote>
<pre>{
vector&lt;int&gt; temp = v1;
v1 = v2;
v2 = temp;
}</pre>
</blockquote>
<p>The first alternative is O(1); the second is O(n).</p>
<p>A LWG member, Dave Abrahams, comments:</p>
<blockquote>
<p>Not an objection necessarily, but I want to point out the cost of
that requirement:</p>
  <blockquote>
<p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
  </blockquote>
<p>can currently be specialized to be more efficient than
iter_swap(T*,T*) for many T (by using splicing). Your proposal would
make that optimization illegal.&nbsp;</p>
</blockquote>

<p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
which are no longer permitted.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
<blockquote>
<p>Exchanges the values pointed to by the two iterators a and b.</p>
</blockquote>
<p>to</p>
<blockquote>
<p><tt>swap(*a, *b)</tt>.</p>
</blockquote>



<p><b>Rationale:</b></p>
<p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
  some iterators for which we want to specialize <tt>iter_swap</tt>,
  but the fully general version should have a general specification.</p>

<p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
iter_swap should not be specialized as suggested above.  That would do
much more than exchanging the two iterators' values: it would change
predecessor/successor relationships, possibly moving the iterator from
one list to another.  That would surely be inappropriate.</p>





<hr>
<h3><a name="189"></a>189. setprecision() not specified correctly</h3>
<p><b>Section:</b> 27.5.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
and includes a parenthetical note saying that it is the number of
digits after the decimal point.<br>
<br>
This claim is not strictly correct.  For example, in the default
floating-point output format, setprecision sets the number of
significant digits printed, not the number of digits after the decimal
point.<br>
<br>
I would like the committee to look at the definition carefully and
correct the statement in 27.4.2.2</p>


<p><b>Proposed resolution:</b></p>
<p>Remove from 27.5.2.2 [fmtflags.state], paragraph 9, the text
"(number of digits after the decimal point)".</p>




<hr>
<h3><a name="193"></a>193. Heap operations description incorrect</h3>
<p><b>Section:</b> 25.4.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 1999-09-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p>
<p><b>Discussion:</b></p>
<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
is<br>
<br>
&nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
<br>
I think this is incorrect and should be changed to the wording in the proposed
resolution.</p>
<p>Actually there are two independent changes:</p>
<blockquote>
  <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
  [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
  <p>B-Take 'an oldest' from that equivalence class, otherwise the heap functions  could not be used for a
  priority queue as explained in 23.2.3.2.2 [lib.priqueue.members] (where I assume that a "priority queue" respects  priority AND time).</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>Change 25.4.6 [alg.heap.operations] property (1) from:</p>
<blockquote>
  <p>(1) *a is the largest element</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>(1) There is no element greater than <tt>*a</tt></p>
</blockquote>





<hr>
<h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3>
<p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-10-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
should set failbit. Should it set eofbit as well?  The standard
doesn't seem to answer that question.</p>

<p>On the one hand, nothing in 27.7.1.1.3 [istream::sentry] says that
<tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
other hand, 27.7.1.1 [istream] paragraph 4 says that if
extraction from a <tt>streambuf</tt> "returns
<tt>traits::eof()</tt>, then the input function, except as explicitly
noted otherwise, completes its actions and does
<tt>setstate(eofbit)"</tt>.  So the question comes down to
whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
input function.</p>

<p>Comments from Jerry Schwarz:</p>
<blockquote>
<p>It was always my intention that eofbit should be set any time that a
virtual returned something to indicate eof, no matter what reason
iostream code had for calling the virtual.</p>
<p>
The motivation for this is that I did not want to require streambufs
to behave consistently if their virtuals are called after they have
signaled eof.</p>
<p>
The classic case is a streambuf reading from a UNIX file.  EOF isn't
really a state for UNIX file descriptors.  The convention is that a
read on UNIX returns 0 bytes to indicate "EOF", but the file
descriptor isn't shut down in any way and future reads do not
necessarily also return 0 bytes.  In particular, you can read from
tty's on UNIX even after they have signaled "EOF".  (It
isn't always understood that a ^D on UNIX is not an EOF indicator, but
an EOL indicator.  By typing a "line" consisting solely of
^D you cause a read to return 0 bytes, and by convention this is
interpreted as end of file.)</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
<blockquote>
<p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
returns <tt>traits::eof()</tt>, the function calls
<tt>setstate(failbit | eofbit)</tt> (which may throw
<tt>ios_base::failure</tt>).
</p>
</blockquote>




<hr>
<h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</h3>
<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1999-11-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is a pointer or reference obtained from an iterator still valid after
destruction of the iterator?
</p>
<p>
Is a pointer or reference obtained from an iterator still valid after the value
of the iterator changes?
</p>
<blockquote>
<pre>#include &lt;iostream&gt;
#include &lt;vector&gt;
#include &lt;iterator&gt;

int main()
{
    typedef std::vector&lt;int&gt; vec_t;
    vec_t v;
    v.push_back( 1 );

    // Is a pointer or reference obtained from an iterator still
    // valid after destruction of the iterator?
    int * p = &amp;*v.begin();
    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?

    // Is a pointer or reference obtained from an iterator still
    // valid after the value of the iterator changes?
    vec_t::iterator iter( v.begin() );
    p = &amp;*iter++;
    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?

    return 0;
}
</pre>
</blockquote>

<p>The standard doesn't appear to directly address these
questions. The standard needs to be clarified. At least two real-world
cases have been reported where library implementors wasted
considerable effort because of the lack of clarity in the
standard. The question is important because requiring pointers and
references to remain valid has the effect for practical purposes of
prohibiting iterators from pointing to cached rather than actual
elements of containers.</p>

<p>The standard itself assumes that pointers and references obtained
from an iterator are still valid after iterator destruction or
change. The definition of reverse_iterator::operator*(), 24.5.1.3.3 [reverse.iter.conv], which returns a reference, defines
effects:</p>

<blockquote>
  <pre>Iterator tmp = current;
return *--tmp;</pre>
</blockquote>
<p>The definition of reverse_iterator::operator-&gt;(), 24.5.1.3.4 [reverse.iter.op.star], which returns a pointer, defines effects:</p>
<blockquote>
  <pre>return &amp;(operator*());</pre>
</blockquote>

<p>Because the standard itself assumes pointers and references remain
valid after iterator destruction or change, the standard should say so
explicitly. This will also reduce the chance of user code breaking
unexpectedly when porting to a different standard library
implementation.</p>


<p><b>Proposed resolution:</b></p>
<p>Add a new paragraph to X [iterator.concepts]:</p>
<blockquote><p>
Destruction of an iterator may invalidate pointers and references
previously obtained from that iterator.
</p></blockquote>

<p>Replace paragraph 1 of 24.5.1.3.3 [reverse.iter.conv] with:</p>

<blockquote>
<p><b>Effects:</b></p>
<pre>  this-&gt;tmp = current;
  --this-&gt;tmp;
  return *this-&gt;tmp;
</pre>

<p>
[<i>Note:</i> This operation must use an auxiliary member variable,
rather than a temporary variable, to avoid returning a reference that
persists beyond the lifetime of its associated iterator.  (See
X [iterator.concepts].)  The name of this member variable is shown for
exposition only.  <i>--end note</i>]
</p>
</blockquote>

<p><i>[Post-Tokyo: The issue has been reformulated purely
in terms of iterators.]</i></p>


<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
assumption by reverse_iterator. The issue and proposed resolution was
reformulated yet again to reflect this reality.]</i></p>


<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
assumes its underlying iterator has persistent pointers and
references.  Andy Koenig pointed out that it is possible to rewrite
reverse_iterator so that it no longer makes such an assupmption.
However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>.  If we
decide it is intentional that <tt>p[n]</tt> may return by value
instead of reference when <tt>p</tt> is a Random Access Iterator,
other changes in reverse_iterator will be necessary.]</i></p>



<p><b>Rationale:</b></p>
<p>This issue has been discussed extensively.  Note that it is
<i>not</i> an issue about the behavior of predefined iterators.  It is
asking whether or not user-defined iterators are permitted to have
transient pointers and references.  Several people presented examples
of useful user-defined iterators that have such a property; examples
include a B-tree iterator, and an "iota iterator" that doesn't point
to memory.  Library implementors already seem to be able to cope with
such iterators: they take pains to avoid forming references to memory
that gets iterated past.  The only place where this is a problem is
<tt>reverse_iterator</tt>, so this issue changes
<tt>reverse_iterator</tt> to make it work.</p>

<p>This resolution does not weaken any guarantees provided by
predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
Clause 23 should be reviewed to make sure that guarantees for
predefined iterators are as strong as users expect.</p>






<hr>
<h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</h3>
<p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Suppose that <tt>A</tt> is a class that conforms to the
Allocator requirements of Table 32, and <tt>a</tt> is an
object of class <tt>A</tt>  What should be the return
value of <tt>a.allocate(0)</tt>?  Three reasonable
possibilities: forbid the argument <tt>0</tt>, return
a null pointer, or require that the return value be a
unique non-null pointer.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add a note to the <tt>allocate</tt> row of Table 32:
"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>


<p><b>Rationale:</b></p>
<p>A key to understanding this issue is that the ultimate use of
allocate() is to construct an iterator, and that iterator for zero
length sequences must be the container's past-the-end
representation.  Since this already implies special case code, it
would be over-specification to mandate the return value.
</p>




<hr>
<h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3>
<p><b>Section:</b> 24.2.5 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In table 74, the return type of the expression <tt>*a</tt> is given
as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
For constant iterators, however, this is wrong.  ("Value type"
is never defined very precisely, but it is clear that the value type
of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
<tt>int</tt>, not <tt>const int</tt>.)
</p>


<p><b>Proposed resolution:</b></p>
<p>
In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
In the <tt>a-&gt;m</tt> row, change the return type from
"<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
otherwise <tt>const U&amp;</tt>".
</p>

<p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
there are multiple const problems with the STL portion of the library
and that these should be addressed as a single package.&nbsp; Note
that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a> has already been declared NAD Future for
that very reason.]</i></p>


<p><i>[Redmond: the LWG thinks this is separable from other constness
issues.  This issue is just cleanup; it clarifies language that was
written before we had iterator_traits.  Proposed resolution was
modified: the original version only discussed *a.  It was pointed out
that we also need to worry about *r++ and a-&gt;m.]</i></p>







<hr>
<h3><a name="201"></a>201. Numeric limits terminology wrong</h3>
<p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 1999-12-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In some places in this section, the terms "fundamental types" and
"scalar types" are used when the term "arithmetic types" is intended.
The current usage is incorrect because void is a fundamental type and
pointers are scalar types, neither of which should have
specializations of numeric_limits.
</p>
<p><i>[Lillehammer: it remains true that numeric_limits is using
  imprecise language. However, none of the proposals for changed
  wording are clearer.  A redesign of numeric_limits is needed, but this
  is more a task than an open issue.]</i></p>



<p><b>Proposed resolution:</b></p>

<p>
Change 18.3 [support.limits] to:
</p>

<blockquote>
<p>
-1- The headers <tt>&lt;limits&gt;</tt>, <tt>&lt;climits&gt;</tt>,
<tt>&lt;cfloat&gt;</tt>, and <tt>&lt;cinttypes&gt;</tt> supply
characteristics of implementation-dependent <del>fundamental</del>
<ins>arithmetic</ins> types (3.9.1).
</p>
</blockquote>

<p>
Change 18.3.1 [limits] to:
</p>

<blockquote>
<p>
-1- The <tt>numeric_limits</tt> component provides a C++ program with
information about various properties of the implementation's
representation of the <del>fundamental</del> <ins>arithmetic</ins>
types.
</p>
<p>
-2- Specializations shall be provided for each <del>fundamental</del>
<ins>arithmetic</ins> type, both floating point and integer, including
<tt>bool</tt>. The member <tt>is_specialized</tt> shall be <tt>true</tt>
for all such specializations of <tt>numeric_limits</tt>.
</p>
<p>
-4- Non-<del>fundamental</del><ins>arithmetic</ins> standard types, such
as <tt>complex&lt;T&gt;</tt> (26.3.2), shall not have specializations.
</p>
</blockquote>

<p>
Change 18.3.1.1 [numeric.limits] to:
</p>

<blockquote>
<p>
<del>-1- The member <tt>is_specialized</tt> makes it possible to distinguish
between fundamental types, which have specializations, and non-scalar types,
which do not.</del>
</p>
</blockquote>






<hr>
<h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3>
<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-01-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
What should unique() do if you give it a predicate that is not an
equivalence relation?  There are at least two plausible answers:
</p>

<blockquote>

<p>
   1. You can't, because 25.2.8 says that it it "eliminates all but
   the first element from every consecutive group of equal
   elements..." and it wouldn't make sense to interpret "equal" as
   meaning anything but an equivalence relation.  [It also doesn't
   make sense to interpret "equal" as meaning ==, because then there
   would never be any sense in giving a predicate as an argument at
   all.]
</p>

<p>
   2. The word "equal" should be interpreted to mean whatever the
   predicate says, even if it is not an equivalence relation
   (and in particular, even if it is not transitive).
</p>

</blockquote>

<p>
The example that raised this question is from Usenet:
</p>

<blockquote>

<pre>int f[] = { 1, 3, 7, 1, 2 };
int* z = unique(f, f+5, greater&lt;int&gt;());</pre>

</blockquote>

<p>
If one blindly applies the definition using the predicate
greater&lt;int&gt;, and ignore the word "equal", you get:
</p>

<blockquote>

<p>
    Eliminates all but the first element from every consecutive group    
    of elements referred to by the iterator i in the range [first, last)    
    for which *i &gt; *(i - 1).
</p>

</blockquote>

<p>
The first surprise is the order of the comparison.  If we wanted to
allow for the predicate not being an equivalence relation, then we
should surely compare elements the other way: pred(*(i - 1), *i).  If
we do that, then the description would seem to say: "Break the
sequence into subsequences whose elements are in strictly increasing
order, and keep only the first element of each subsequence".  So the
result would be 1, 1, 2.  If we take the description at its word, it
would seem to call for strictly DEcreasing order, in which case the
result should be 1, 3, 7, 2.<br>
<br>
In fact, the SGI implementation of unique() does neither: It yields 1,
3, 7.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 25.3.9 [alg.unique] paragraph 1 to:</p>
<blockquote><p>
For a nonempty range, eliminates all but the first element from every
consecutive group of equivalent elements referred to by the iterator
<tt>i</tt> in the range [first+1, last) for which the following
conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
false</tt>.
</p></blockquote>

<p>
Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
comparison function must be an equivalence relation."
</p>

<p><i>[Redmond: discussed arguments for and against requiring the
comparison function to be an equivalence relation.  Straw poll:
14-2-5.  First number is to require that it be an equivalence
relation, second number is to explicitly not require that it be an
equivalence relation, third number is people who believe they need
more time to consider the issue.  A separate issue: Andy Sawyer
pointed out that "i-1" is incorrect, since "i" can refer to the first
iterator in the range.  Matt provided wording to address this
problem.]</i></p>


<p><i>[Cura�ao: The LWG changed "... the range (first,
last)..." to "...  the range [first+1, last)..." for
clarity. They considered this change close enough to editorial to not
require another round of review.]</i></p>




<p><b>Rationale:</b></p>
<p>The LWG also considered an alternative resolution: change 
25.3.9 [alg.unique] paragraph 1 to:</p>

<blockquote><p>
For a nonempty range, eliminates all but the first element from every
consecutive group of elements referred to by the iterator
<tt>i</tt> in the range (first, last) for which the following
conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
false</tt>.
</p></blockquote>

<p>
Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
comparison function need not be an equivalence relation."
</p>


<p>Informally: the proposed resolution imposes an explicit requirement
that the comparison function be an equivalence relation.  The
alternative resolution does not, and it gives enough information so
that the behavior of unique() for a non-equivalence relation is
specified.  Both resolutions are consistent with the behavior of
existing implementations.</p>





<hr>
<h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3>
<p><b>Section:</b> 18.6.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-08-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>As specified, the implementation of the nothrow version of operator
new does not necessarily call the ordinary operator new, but may
instead simply call the same underlying allocator and return a null
pointer instead of throwing an exception in case of failure.</p>

<p>Such an implementation breaks code that replaces the ordinary
version of new, but not the nothrow version. If the ordinary version
of new/delete is replaced, and if the replaced delete is not
compatible with pointers returned from the library versions of new,
then when the replaced delete receives a pointer allocated by the
library new(nothrow), crash follows.</p>

<p>The fix appears to be that the lib version of new(nothrow) must
call the ordinary new. Thus when the ordinary new gets replaced, the
lib version will call the replaced ordinary new and things will
continue to work.</p>

<p>An alternative would be to have the ordinary new call
new(nothrow). This seems sub-optimal to me as the ordinary version of
new is the version most commonly replaced in practice. So one would
still need to replace both ordinary and nothrow versions if one wanted
to replace the ordinary version.</p>

<p>Another alternative is to put in clear text that if one version is
replaced, then the other must also be replaced to maintain
compatibility. Then the proposed resolution below would just be a
quality of implementation issue. There is already such text in
paragraph 7 (under the new(nothrow) version). But this nuance is
easily missed if one reads only the paragraphs relating to the
ordinary new.</p>

<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html">N2158</a>
has been written explaining the rationale for the proposed resolution below.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change 18.5.1.1 [new.delete.single]:
</p>

<blockquote>
<pre>void* operator new(std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Same as above, except that it is called by a placement
version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
an error indication, instead of a <tt>bad_alloc</tt> exception.
</p>

<p>
-6- <i>Replaceable:</i> a C++ program may define a function with this function
signature that displaces the default version defined by the C++ Standard
library.
</p>

<p>
-7- <i>Required behavior:</i> Return a non-null pointer to suitably aligned
storage (3.7.4), or else return a null pointer. This nothrow version of operator
new returns a pointer obtained as if acquired from the <ins>(possibly
replaced)</ins> ordinary version. This requirement is binding on a replacement
version of this function.
</p>

<p>
-8- <i>Default behavior:</i>
</p>
<ul>
<li><ins>
Calls <tt>operator new(<i>size</i>)</tt>.
</ins></li>
<li><ins>
If the call to <tt>operator new(<i>size</i>)</tt> returns normally, returns
the result of that call, else
</ins></li>
<li><ins>
if the call to <tt>operator new(<i>size</i>)</tt> throws an exception, returns
a null pointer.
</ins></li>
<li><del>
Executes a loop: Within the loop, the function first attempts to allocate the
requested storage. Whether the attempt involves a call to the Standard C library
function <tt>malloc</tt> is unspecified.
</del></li>
<li><del>
Returns a pointer to the allocated storage if the attempt is successful.
Otherwise, if the last argument to <tt>set_new_handler()</tt> was a null
pointer, return a null pointer.
</del></li>
<li><del>
Otherwise, the function calls the current <i>new_handler</i> (18.5.2.2). If the
called function returns, the loop repeats.
</del></li>
<li><del>
The loop terminates when an attempt to allocate the requested storage is
successful or when a called <i>new_handler</i> function does not return. If the
called <i>new_handler</i> function terminates by throwing a <tt>bad_alloc
exception</tt>, the function returns a null pointer.
</del></li>
</ul>
<p>
-9- [<i>Example:</i>
</p>
<blockquote><pre>T* p1 = new T;                 <i>// throws bad_alloc if it fails</i>
T* p2 = new(nothrow) T;        <i>// returns 0 if it fails</i>
</pre></blockquote>
<p>
--<i>end example</i>]
</p>
</blockquote>

<pre>void operator delete(void* <i>ptr</i>) throw();
<del>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</del>
</pre>

<blockquote>
<p>
-10- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by a
<i>delete-expression</i> to render the value of <tt><i>ptr</i></tt> invalid.
</p>
<p>
-11- <i>Replaceable:</i> a C++ program may define a function with this function
signature that displaces the default version defined by the C++ Standard
library.
</p>
<p>
-12- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the value
returned by an earlier call to the <del>default</del> <ins>(possibly
replaced)</ins> <tt>operator new(std::size_t)</tt> or <tt>operator
new(std::size_t, const std::nothrow_t&amp;)</tt>.
</p>
<p>
-13- <i>Default behavior:</i>
</p>
<ul>
<li>
For a null value of <tt><i>ptr</i></tt>, do nothing.
</li>
<li>
Any other value of <tt><i>ptr</i></tt> shall be a value returned earlier by a
call to the default <tt>operator new</tt>, which was not invalidated by an
intervening call to <tt>operator delete(void*)</tt> (17.4.3.7). For such a
non-null value of <tt><i>ptr</i></tt>, reclaims storage allocated by the earlier
call to the default <tt>operator new</tt>.
</li>
</ul>
<p>
-14- <i>Remarks:</i>  It is unspecified under what conditions part or all of
such reclaimed storage is allocated by a subsequent call to <tt>operator
new</tt> or any of <tt>calloc</tt>, <tt>malloc</tt>, or <tt>realloc</tt>,
declared in <tt>&lt;cstdlib&gt;</tt>.
</p>
</blockquote>

<pre><ins>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</ins>
</pre>

<blockquote>
<p><ins>
-15- <i>Effects:</i> Same as above, except that it is called by the
implementation when an exception propagates from a nothrow placement version
of the <i>new-expression</i> (i.e. when the constructor throws an exception).
</ins></p>
<p><ins>
-16- <i>Replaceable:</i> a C++ program may define a function with this function
signature that displaces the default version defined by the C++ Standard
library.
</ins></p>
<p><ins>
-17- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the
value returned by an earlier call to the (possibly replaced) <tt>operator
new(std::size_t)</tt> or <tt>operator new(std::size_t, const
std::nothrow_t&amp;)</tt>. </ins></p>
<p><ins>
-18- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 18.5.1.2 [new.delete.array]
</p>

<blockquote>
<pre>void* operator new[](std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
</pre>

<blockquote>
<p>
-5- <i>Effects:</i> Same as above, except that it is called by a placement
version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
an error indication, instead of a <tt>bad_alloc</tt> exception.
</p>

<p>
-6- <i>Replaceable:</i>  a C++ program can define a function with this function
signature that displaces the default version defined by the C++ Standard
library.
</p>

<p>
-7- <i>Required behavior:</i> <del>Same as for operator <tt>new(std::size_t,
const std::nothrow_t&amp;)</tt>. This nothrow version of operator <tt>new[]</tt>
returns a pointer obtained as if acquired from the ordinary version.</del>
<ins>Return a non-null pointer to suitably aligned storage (3.7.4), or else
return a null pointer. This nothrow version of operator new returns a pointer
obtained as if acquired from the (possibly replaced) <tt>operator
new[](std::size_t <i>size</i>)</tt>. This requirement is binding on a
replacement version of this function.</ins>
</p>

<p>
-8- <i>Default behavior:</i> <del>Returns <tt>operator new(<i>size</i>,
nothrow)</tt>.</del>
</p>

<ul>
<li><ins>
Calls <tt>operator new[](<i>size</i>)</tt>.
</ins></li>
<li><ins>
If the call to <tt>operator new[](<i>size</i>)</tt> returns normally, returns
the result of that call, else
</ins></li>
<li><ins>
if the call to <tt>operator new[](<i>size</i>)</tt> throws an exception, returns
a null pointer.
</ins></li>
</ul>
</blockquote>

<pre>void operator delete[](void* <i>ptr</i>) throw(); 
void operator delete[](void* <i>ptr</i>, const std::nothrow_t&amp;) throw();
</pre>

<blockquote>
<p>
-9- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by the
array form of a <i>delete-expression</i> to render the value of
<tt><i>ptr</i></tt> invalid.
</p>

<p>
-10- <i>Replaceable:</i> a C++ program can define a function with this function
signature that displaces the default version defined by the C++ Standard
library.
</p>

<p>
-11- <i>Requires:</i> the value of
<tt><i>ptr</i></tt> is null or the value returned by an earlier call to
<tt>operator new[](std::size_t)</tt> or <tt>operator new[](std::size_t, const
std::nothrow_t&amp;)</tt>.
</p>

<p>
-12- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt> or
<tt>operator delete<ins>[]</ins>(<i>ptr</i><del>, std::nothrow</del>)</tt> respectively.
</p>
</blockquote>

</blockquote>



<p><b>Rationale:</b></p>
<p>Yes, they may become unlinked, and that is by design. If a user
replaces one, the user should also replace the other.</p>

<p><i>[
Reopened due to a gcc conversation between Howard, Martin and Gaby.  Forwarding
or not is visible behavior to the client and it would be useful for the client
to know which behavior it could depend on.
]</i></p>


<p><i>[
Batavia: Robert voiced serious reservations about backwards compatibility for
his customers.
]</i></p>






<hr>
<h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</h3>
<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 2000-02-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
past-the-end values are always non-singular."</p>
<p>This places an unnecessary restriction on past-the-end iterators for
containers with forward iterators (for example, a singly-linked list). If the
past-the-end value on such a container was a well-known singular value, it would
still satisfy all forward iterator requirements.</p>
<p>Removing this restriction would allow, for example, a singly-linked list
without a "footer" node.</p>
<p>This would have an impact on existing code that expects past-the-end
iterators obtained from different (generic) containers being not equal.</p>


<p><b>Proposed resolution:</b></p>
<p>Change X [iterator.concepts] paragraph 5, the last sentence, from:</p>
<blockquote>
<p>Dereferenceable and past-the-end values are always non-singular.</p>
</blockquote>
<p>to:</p>
<blockquote>
<p>Dereferenceable values are always non-singular.&nbsp;</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>For some kinds of containers, including singly linked lists and
zero-length vectors, null pointers are perfectly reasonable past-the-end
iterators.  Null pointers are singular.
</p>




<hr>
<h3><a name="209"></a>209. basic_string declarations inconsistent</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Igor Stauder <b>Opened:</b> 2000-02-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In Section 21.4 [basic.string] the basic_string member function
declarations use a consistent style except for the following functions:</p>
<blockquote>
  <pre>void push_back(const charT);
basic_string&amp; assign(const basic_string&amp;);
void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
</blockquote>
<p>- push_back, assign, swap: missing argument name&nbsp;<br>
- push_back: use of const with charT (i.e. POD type passed by value
not by reference - should be charT or const charT&amp; )<br>
- swap: redundant use of template parameters in argument
basic_string&lt;charT,traits,Allocator&gt;&amp;</p>


<p><b>Proposed resolution:</b></p>
<p>In Section 21.4 [basic.string] change the basic_string member
function declarations push_back, assign, and swap to:</p>
<blockquote>
  <pre>void push_back(charT c); 

basic_string&amp; assign(const basic_string&amp; str);
void swap(basic_string&amp; str);</pre>
</blockquote>


<p><b>Rationale:</b></p>
<p>Although the standard is in general not consistent in declaration
style, the basic_string declarations are consistent other than the
above.  The LWG felt that this was sufficient reason to merit the
change.
</p>




<hr>
<h3><a name="210"></a>210. distance first and last confused</h3>
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-02-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In paragraph 9 of section 25 [algorithms], it is written:</p>
<blockquote>
  <p>      In the description of the algorithms operators + and - are used
           for some of the iterator categories for which they do not have to
           be defined. In these cases the semantics of [...] a-b is the same
           as of<br>
  <br>
  &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>On the last line of paragraph 9 of section 25 [algorithms] change
<tt>"a-b"</tt> to <tt>"b-a".</tt></p>


<p><b>Rationale:</b></p>
<p>There are two ways to fix the defect; change the description to b-a
or change the return to distance(b,a).  The LWG preferred the
former for consistency.</p>




<hr>
<h3><a name="211"></a>211. operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Scott Snyder <b>Opened:</b> 2000-02-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The description of the stream extraction operator for std::string (section
21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
the case that the operator fails to extract any characters from the input
stream.</p>
<p>This implies that the typical construction</p>
<blockquote>
  <pre>std::istream is;
std::string str;
...
while (is &gt;&gt; str) ... ;</pre>
</blockquote>
<p>(which tests failbit) is not required to terminate at EOF.</p>
<p>Furthermore, this is inconsistent with other extraction operators,
which do include this requirement. (See sections 27.7.1.2 [istream.formatted] and 27.7.1.3 [istream.unformatted]), where this
requirement is present, either explicitly or implicitly, for the
extraction operators. It is also present explicitly in the description
of getline (istream&amp;, string&amp;, charT) in section 21.4.8.9 [string.io] paragraph 8.)</p>


<p><b>Proposed resolution:</b></p>
<p>Insert new paragraph after paragraph 2 in section 21.4.8.9 [string.io]:</p>
<blockquote>

<p>If the function extracts no characters, it calls
is.setstate(ios::failbit) which may throw ios_base::failure
(27.4.4.3).</p>
</blockquote>




<hr>
<h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The standard doesn't specify what min_element() and max_element() shall
return if the range is empty (first equals last). The usual implementations
return last. This problem seems also apply to partition(), stable_partition(),
next_permutation(), and prev_permutation().</p>


<p><b>Proposed resolution:</b></p>
<p>In 25.4.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
9, append: Returns last if first==last.</p>


<p><b>Rationale:</b></p>
<p>The LWG looked in some detail at all of the above mentioned
algorithms, but believes that except for min_element() and
max_element() it is already clear that last is returned if first ==
last.</p>




<hr>
<h3><a name="214"></a>214. set::find() missing const overload</h3>
<p><b>Section:</b> 23.6.3 [set], 23.6.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p>
<p><b>Discussion:</b></p>
<p>The specification for the associative container requirements in
Table 69 state that the find member function should "return
iterator; const_iterator for constant a". The map and multimap
container descriptions have two overloaded versions of find, but set
and multiset do not, all they have is:</p>
<blockquote>
  <pre>iterator find(const key_type &amp; x) const;</pre>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
equal_range() in section 23.6.3 [set] and section 23.6.4 [multiset] to each have two overloads:</p>
<blockquote>
  <pre>iterator find(const key_type &amp; x);
const_iterator find(const key_type &amp; x) const;</pre>
  <pre>iterator lower_bound(const key_type &amp; x);
const_iterator lower_bound(const key_type &amp; x) const;</pre>
  <pre>iterator upper_bound(const key_type &amp; x);
const_iterator upper_bound(const key_type &amp; x) const;</pre>
  <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
</blockquote>

<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
extending the proposed resolution to lower_bound, upper_bound, and
equal_range.]</i></p>






<hr>
<h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3>
<p><b>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-02-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
must be const in order for it to be callable on a const object (a reference to
which which is what std::use_facet&lt;&gt;() returns).</p>
<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
name of the namespace `My'.</p>
<p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
in main(), the name of the facet is misspelled: it should read `My::JCtype'
rather than `My::JCType'.</p>


<p><b>Proposed resolution:</b></p>
<p>Replace the "Classifying Japanese characters" example in 22.2.8,
paragraph 11 with the following:</p>
<pre>#include &lt;locale&gt;</pre>
<pre>namespace My {
    using namespace std;
    class JCtype : public locale::facet {
    public:
        static locale::id id;     //  required for use as a new locale facet
        bool is_kanji (wchar_t c) const;
        JCtype() {}
    protected:
        ~JCtype() {}
    };
}</pre>
<pre>//  file:  filt.C
#include &lt;iostream&gt;
#include &lt;locale&gt;
#include "jctype"                 //  above
std::locale::id My::JCtype::id;   //  the static  JCtype  member
declared above.</pre>
<pre>int main()
{
    using namespace std;
    typedef ctype&lt;wchar_t&gt; wctype;
    locale loc(locale(""),              //  the user's preferred locale...
               new My::JCtype);         //  and a new feature ...
    wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
    if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
        cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
    return 0;
}</pre>




<hr>
<h3><a name="220"></a>220. ~ios_base() usage valid?</h3>
<p><b>Section:</b> 27.5.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Opened:</b> 2000-03-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
paragraph 2:</p>
<blockquote>
  <p>Effects: Destroys an object of class ios_base. Calls each registered
  callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
  time that any ios_base member function called from within fn has well defined
  results.</p>
</blockquote>
<p>But what is not clear is: If no callback functions were ever registered, does
it matter whether the ios_base members were ever initialized?</p>
<p>For instance, does this program have defined behavior:</p>
<blockquote>
  <pre>#include &lt;ios&gt;</pre>
  <pre>class D : public std::ios_base { };</pre>
  <pre>int main() { D d; }</pre>
</blockquote>
<p>It seems that registration of a callback function would surely affect the
state of an ios_base. That is, when you register a callback function with an
ios_base, the ios_base must record that fact somehow.</p>
<p>But if after construction the ios_base is in an indeterminate state, and that
state is not made determinate before the destructor is called, then how would
the destructor know if any callbacks had indeed been registered? And if the
number of callbacks that had been registered is indeterminate, then is not the
behavior of the destructor undefined?</p>
<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
it explicit that destruction before initialization results in undefined
behavior.</p>


<p><b>Proposed resolution:</b></p>
<p>Modify 27.4.2.7 paragraph 1 from</p>
<blockquote>
  <p>Effects: Each ios_base member has an indeterminate value after
  construction.</p>
</blockquote>
<p>to</p>
<blockquote>
  <p>Effects: Each ios_base member has an indeterminate value after
  construction. These members must be initialized by calling basic_ios::init. If an ios_base object is destroyed before these initializations
  have taken place, the behavior is undefined.</p>
</blockquote>




<hr>
<h3><a name="221"></a>221. num_get&lt;&gt;::do_get stage 2 processing broken</h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-03-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Stage 2 processing of numeric conversion is broken.</p>

<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
conversion specifier is %i. A %i specifier determines a number's base
by its prefix (0 for octal, 0x for hex), so the intention is clearly
that a 0x prefix is allowed.  Paragraph 8 in the same section,
however, describes very precisely how characters are processed. (It
must be done "as if" by a specified code fragment.) That
description does not allow a 0x prefix to be recognized.</p>

<p>Very roughly, stage 2 processing reads a char_type ct. It converts
ct to a char, not by using narrow but by looking it up in a
translation table that was created by widening the string literal
"0123456789abcdefABCDEF+-". The character "x" is
not found in that table, so it can't be recognized by stage 2
processing.</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
<blockquote>
  <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
</blockquote>
<p>with the line:</p>
<blockquote>
  <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
</blockquote>


<p><b>Rationale:</b></p>
<p>If we're using the technique of widening a string literal, the
string literal must contain every character we wish to recognize.
This technique has the consequence that alternate representations
of digits will not be recognized.  This design decision was made
deliberately, with full knowledge of that limitation.</p>





<hr>
<h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3>
<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-03-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
<blockquote>
  <pre>21.3.6.8 - basic_string::compare [lib.string::compare]

int compare(size_type pos1, size_type n1,
                const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
                size_type  pos2 , size_type  n2 ) const;

-4- Returns: 

    basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
                 basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
</blockquote>
<p>and the constructor that's implicitly called by the above is
defined to throw an out-of-range exception if pos &gt; str.size(). See
section 21.4.1 [string.require] paragraph 4.</p>

<p>On the other hand, the compare function descriptions themselves don't have
"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
that do not apply to a function are omitted.</p>
<p>So it seems there is an inconsistency in the standard -- are the
"Effects" clauses correct, or are the "Throws" clauses
missing?</p>


<p><b>Proposed resolution:</b></p>
<p>In 17.5.1.4 [structure.specifications] paragraph 3, the footnote 148 attached to
the sentence "Descriptions of function semantics contain the
following elements (as appropriate):", insert the word
"further" so that the foot note reads:</p>
<blockquote>
  <p>To save space, items that do not apply to a function are
  omitted. For example, if a function does not specify any further
  preconditions, there will be no "Requires" paragraph.</p>
</blockquote>


<p><b>Rationale:</b></p>
<p>The standard is somewhat inconsistent, but a failure to note a
throw condition in a throws clause does not grant permission not to
throw.  The inconsistent wording is in a footnote, and thus
non-normative. The proposed resolution from the LWG clarifies the
footnote.</p>




<hr>
<h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3>
<p><b>Section:</b> 25.3.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-03-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>


<p><b>Proposed resolution:</b></p>
<p>In 25.3.10 [alg.reverse], replace:</p>
  <blockquote><p>
  Effects: For each non-negative integer i &lt;= (last - first)/2, 
  applies swap to all pairs of iterators first + i, (last - i) - 1.
  </p></blockquote>
<p>with:</p>
  <blockquote><p>
  Effects: For each non-negative integer i &lt;= (last - first)/2, 
  applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
  </p></blockquote>




<hr>
<h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Ed Brey <b>Opened:</b> 2000-03-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In the associative container requirements table in 23.1.2 paragraph 7,
a.clear() has complexity "log(size()) + N". However, the meaning of N
is not defined.</p>


<p><b>Proposed resolution:</b></p>
<p>In the associative container requirements table in 23.1.2 paragraph
7, the complexity of a.clear(), change "log(size()) + N" to
"linear in <tt>size()</tt>".</p>


<p><b>Rationale:</b></p>
<p>It's the "log(size())", not the "N", that is in
error: there's no difference between <i>O(N)</i> and <i>O(N +
log(N))</i>.  The text in the standard is probably an incorrect
cut-and-paste from the range version of <tt>erase</tt>.</p>




<hr>
<h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3>
<p><b>Section:</b> 17.6.4.4 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
user namespaces might be found through Koenig lookup?</p>
<p>For example, a popular standard library implementation includes this
implementation of std::unique:</p>
<blockquote>
<pre>namespace std {
    template &lt;class _ForwardIter&gt;
    _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
      __first = adjacent_find(__first, __last);
      return unique_copy(__first, __last, __first);
    }
    }</pre>
</blockquote>
<p>Imagine two users on opposite sides of town, each using unique on his own
sequences bounded by my_iterators . User1 looks at his standard library
implementation and says, "I know how to implement a more efficient
unique_copy for my_iterators", and writes:</p>
<blockquote>
<pre>namespace user1 {
    class my_iterator;
    // faster version for my_iterator
    my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
    }</pre>
</blockquote>
<p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
<p>User2 has other needs, and writes:</p>
<blockquote>
<pre>namespace user2 {
    class my_iterator;
    // Returns true iff *c is a unique copy of *a and *b.
    bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
    }</pre>
</blockquote>
<p>User2 is shocked to find later that his fully-qualified use of
std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
compile (if he's lucky). Looking in the standard, he sees the following Effects
clause for unique():</p>
<blockquote>
  <p>Effects: Eliminates all but the first element from every consecutive group
  of equal elements referred to by the iterator i in the range [first, last) for
  which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
  *(i - 1)) != false</p>
</blockquote>
<p>The standard gives user2 absolutely no reason to think he can interfere with
std::unique by defining names in namespace user2. His standard library has been
built with the template export feature, so he is unable to inspect the
implementation. User1 eventually compiles his code with another compiler, and
his version of unique_copy silently stops being called. Eventually, he realizes
that he was depending on an implementation detail of his library and had no
right to expect his unique_copy() to be called portably.</p>
<p>On the face of it, and given above scenario, it may seem obvious that the
implementation of unique() shown is non-conforming because it uses unique_copy()
rather than ::std::unique_copy(). Most standard library implementations,
however, seem to disagree with this notion.</p>
<p> <i>[Tokyo:&nbsp; Steve Adamczyk from
the core working group indicates that "std::" is sufficient;&nbsp;
leading "::" qualification is not required because any namespace
qualification is sufficient to suppress Koenig lookup.]</i></p>


<p><b>Proposed resolution:</b></p>
<p>Add a paragraph and a note at the end of 
17.6.4.4 [global.functions]:</p>
<blockquote>

<p>Unless otherwise specified, no global or non-member function in the
standard library shall use a function from another namespace which is
found through <i>argument-dependent name lookup</i> (3.4.2 [basic.lookup.argdep]).</p>

<p>[Note: the phrase "unless otherwise specified" is intended to
allow Koenig lookup in cases like that of ostream_iterators:<br>

<br>
  Effects:</p>
  <blockquote>
<p>*out_stream &lt;&lt; value;<br>
      if(delim != 0) *out_stream &lt;&lt; delim;<br>
      return (*this);</p>
    <p>--end note]</p>
  </blockquote>
</blockquote>

<p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
is as yet unsure if the proposed resolution is the best
solution. Furthermore, the LWG believes that the same problem of
unqualified library names applies to wording in the standard itself,
and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>


<p><i>[Toronto: The LWG is not sure if this is a defect in the
standard.  Most LWG members believe that an implementation of
<tt>std::unique</tt> like the one quoted in this issue is already
illegal, since, under certain circumstances, its semantics are not
those specified in the standard.  The standard's description of
<tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
should have any effect.]</i></p>


<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
225, 226, and 229.  Their conclusion was that the issues should be
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
EWG portion (Dave will write a proposal). The LWG and EWG had
(separate) discussions of this plan the next day.  The proposed
resolution for this issue is in accordance with Howard's paper.]</i></p>




<p><b>Rationale:</b></p>
<p>It could be argued that this proposed isn't strictly necessary,
  that the Standard doesn't grant implementors license to write a
  standard function that behaves differently than specified in the
  Standard just because of an unrelated user-defined name in some
  other namespace.  However, this is at worst a clarification.  It is
  surely right that algorithsm shouldn't pick up random names, that
  user-defined names should have no effect unless otherwise specified.
  Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> deals with the question of when it is
  appropriate for the standard to explicitly specify otherwise.</p>





<hr>
<h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3>
<p><b>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The issues are:&nbsp;</p>
<p>1. How can a 3rd party library implementor (lib1) write a version of a standard
algorithm which is specialized to work with his own class template?&nbsp;</p>
<p>2. How can another library implementor (lib2) write a generic algorithm which 
will take advantage of the specialized algorithm in lib1?</p>
<p>This appears to be the only viable answer under current language rules:</p>
<blockquote>
  <pre>namespace lib1
{
    // arbitrary-precision numbers using T as a basic unit
    template &lt;class T&gt;
    class big_num { //...
    };
    </pre>
  <pre>    // defining this in namespace std is illegal (it would be an
    // overload), so we hope users will rely on Koenig lookup
    template &lt;class T&gt;
    void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
}</pre>
  <pre>#include &lt;algorithm&gt;
namespace lib2
{
    template &lt;class T&gt;
    void generic_sort(T* start, T* end)
    {
            ...
        // using-declaration required so we can work on built-in types
        using std::swap;
        // use Koenig lookup to find specialized algorithm if available
        swap(*x, *y);
    }
}</pre>
</blockquote>
<p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
and somewhat slippery. The implementor needs to remember to write the
using-declaration, or generic_sort will fail to compile when T is a built-in
type. The second drawback is that the use of this style in lib2 effectively
"reserves" names in any namespace which defines types which may
eventually be used with lib2. This may seem innocuous at first when applied to
names like swap, but consider more ambiguous names like unique_copy() instead.
It is easy to imagine the user wanting to define these names differently in his
own namespace. A definition with semantics incompatible with the standard
library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p>
<p>Why, you may ask, can't we just partially specialize std::swap()? It's
because the language doesn't allow for partial specialization of function
templates. If you write:</p>
<blockquote>
  <pre>namespace std
{
    template &lt;class T&gt;
    void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
}</pre>
</blockquote>
<p>You have just overloaded std::swap, which is illegal under the current
language rules. On the other hand, the following full specialization is legal:</p>
<blockquote>
  <pre>namespace std
{
    template &lt;&gt;
    void swap(lib1::other_type&amp;, lib1::other_type&amp;);
}</pre>
</blockquote>

<p>This issue reflects concerns raised by the "Namespace issue
with specialized swap" thread on comp.lang.c++.moderated. A
similar set of concerns was earlier raised on the boost.org mailing
list and the ACCU-general mailing list.  Also see library reflector
message c++std-lib-7354.</p>

<p>
J. C. van Winkel points out (in c++std-lib-9565) another unexpected
fact: it's impossible to output a container of std::pair's using copy
and an ostream_iterator, as long as both pair-members are built-in or
std:: types.  That's because a user-defined operator&lt;&lt; for (for
example) std::pair&lt;const std::string, int&gt; will not be found:
lookup for operator&lt;&lt; will be performed only in namespace std.
Opinions differed on whether or not this was a defect, and, if so,
whether the defect is that something is wrong with user-defined
functionality and std, or whether it's that the standard library does
not provide an operator&lt;&lt; for std::pair&lt;&gt;.
</p>



<p><b>Proposed resolution:</b></p>

<p>Adopt the wording proposed in Howard Hinnant's paper
  N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>


<p><i>[Tokyo: Summary, "There is no conforming way to extend
std::swap for user defined templates."&nbsp; The LWG agrees that
there is a problem.  Would like more information before
proceeding. This may be a core issue.  Core issue 229 has been opened
to discuss the core aspects of this problem. It was also noted that
submissions regarding this issue have been received from several
sources, but too late to be integrated into the issues list.
]</i></p>


<p><i>[Post-Tokyo: A paper with several proposed resolutions,
J16/00-0029==WG21/N1252, "Shades of namespace std functions
" by Alan Griffiths, is in the Post-Tokyo mailing. It
should be considered a part of this issue.]</i></p>


<p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
resolution that involves core changes: it would add partial
specialization of function template.  The Core Working Group is
reluctant to add partial specialization of function templates.  It is
viewed as a large change, CWG believes that proposal presented leaves
some syntactic issues unanswered; if the CWG does add partial
specialization of function templates, it wishes to develop its own
proposal.  The LWG continues to believe that there is a serious
problem: there is no good way for users to force the library to use
user specializations of generic standard library functions, and in
certain cases (e.g. transcendental functions called by
<tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
lookup isn't adequate, since names within the library must be
qualified with <tt>std</tt> (see issue 225), specialization doesn't
work (we don't have partial specialization of function templates), and
users aren't permitted to add overloads within namespace std.
]</i></p>


<p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
focused on four options. (1) Relax restrictions on overloads within
namespace std. (2) Mandate that the standard library use unqualified
calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
helper class templates for <tt>swap</tt> and possibly other functions.
(4) Introduce partial specialization of function templates.  Every
option had both support and opposition.  Straw poll (first number is
support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
(4) 4, 4.]</i></p>


<p><i>[Redmond: Discussed, again no consensus.  Herb presented an
argument that a user who is defining a type <tt>T</tt> with an
associated <tt>swap</tt> should not be expected to put that
<tt>swap</tt> in namespace std, either by overloading or by partial
specialization.  The argument is that <tt>swap</tt> is part of
<tt>T</tt>'s interface, and thus should to in the same namespace as
<tt>T</tt> and only in that namespace.  If we accept this argument,
the consequence is that standard library functions should use
unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
try to put together a proposal before the next meeting.]</i></p>


<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
225, 226, and 229.  Their conclusion was that the issues should be
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
EWG portion (Dave will write a proposal). The LWG and EWG had
(separate) discussions of this plan the next day.  The proposed
resolution is the one proposed by Howard.]</i></p>


<p><i>[Santa Cruz: the LWG agreed with the general direction of
  Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
  we say otherwise; this issue is about when we do say otherwise.)
  However, there were concerns about wording.  Howard will provide new
  wording.  Bill and Jeremy will review it.]</i></p>


<p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
  proposed resolution.]</i></p>




<p><b>Rationale:</b></p>
<p>Informally: introduce a Swappable concept, and specify that the
  value types of the iterators passed to certain standard algorithms
  (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
  to that concept.  The Swappable concept will make it clear that
  these algorithms use unqualified lookup for the calls
  to <tt>swap</tt>.  Also, in 26.6.3.3 [valarray.transcend] paragraph 1,
  state that the valarray transcendentals use unqualified lookup.</p>





<hr>
<h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3>
<p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p>
<p><b>Discussion:</b></p>
<p>25.2.2 reads:</p>
<blockquote>
  <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
  <br>
  Requires:    Type T is Assignable (_lib.container.requirements_).<br>
  Effects:    Exchanges values stored in two locations.</p>
</blockquote>
<p>The only reasonable** generic implementation of swap requires construction of a 
   new temporary copy of one of its arguments:</p>
<blockquote>
<pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
  {
      T tmp(a);
      a = b;
      b = tmp;
  }</pre>
</blockquote>
<p>But a type which is only Assignable cannot be swapped by this implementation.</p>
<p>**Yes, there's also an unreasonable implementation which would require T to be 
   DefaultConstructible instead of CopyConstructible. I don't think this is worthy 
   of consideration:</p>
<blockquote>
<pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
{
    T tmp;
    tmp = a;
    a = b;
    b = tmp;
}</pre>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>Change 25.2.2 paragraph 1 from:</p>
<blockquote>
<p>  Requires: Type T is Assignable (23.1).</p>
</blockquote>
<p>to:</p>
<blockquote>
<p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
</blockquote>





<hr>
<h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</h3>
<p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The sections 22.4.1.2 [locale.ctype.byname], 22.4.1.5 [locale.codecvt.byname],
sref ref="22.2.1.6", 22.4.3.2 [locale.numpunct.byname], 22.4.4.2 [locale.collate.byname], 22.4.5.4 [locale.time.put.byname], 22.4.6.4 [locale.moneypunct.byname], and 22.4.7.2 [locale.messages.byname] overspecify the
definitions of the "..._byname" classes by listing a bunch
of virtual functions. At the same time, no semantics of these
functions are defined. Real implementations do not define these
functions because the functional part of the facets is actually
implemented in the corresponding base classes and the constructor of
the "..._byname" version just provides suitable date used by
these implementations. For example, the 'numpunct' methods just return
values from a struct. The base class uses a statically initialized
struct while the derived version reads the contents of this struct
from a table.  However, no virtual function is defined in
'numpunct_byname'.</p>

<p>For most classes this does not impose a problem but specifically
for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
is required because otherwise the semantics would change due to the
virtual functions defined in the general version for 'ctype_byname':
In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
this class is specialized or not under the current specification:
Without the specialization, 'do_is()' is virtual while with
specialization it is not virtual.</p>


<p><b>Proposed resolution:</b></p>
<p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
<pre>     namespace std {
       template &lt;class charT&gt;
       class ctype_byname : public ctype&lt;charT&gt; {
       public:
         typedef ctype&lt;charT&gt;::mask mask;
         explicit ctype_byname(const char*, size_t refs = 0);
       protected:
        ~ctype_byname();             //  virtual
       };
     }</pre>
<p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
<pre>    namespace std {
      template &lt;class internT, class externT, class stateT&gt;
      class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
      public:
       explicit codecvt_byname(const char*, size_t refs = 0);
      protected:
      ~codecvt_byname();             //  virtual
       };
     }
</pre>
<p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
<pre>     namespace std {
       template &lt;class charT&gt;
       class numpunct_byname : public numpunct&lt;charT&gt; {
     //  this class is specialized for  char  and  wchar_t.
       public:
         typedef charT                char_type;
         typedef basic_string&lt;charT&gt;  string_type;
         explicit numpunct_byname(const char*, size_t refs = 0);
       protected:
        ~numpunct_byname();          //  virtual
       };
     }</pre>
<p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
<pre>     namespace std {
       template &lt;class charT&gt;
       class collate_byname : public collate&lt;charT&gt; {
       public:
         typedef basic_string&lt;charT&gt; string_type;
         explicit collate_byname(const char*, size_t refs = 0);
       protected:
        ~collate_byname();           //  virtual
       };
     }</pre>
<p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
<pre>     namespace std {
       template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
       class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
       public:
         typedef time_base::dateorder dateorder;
         typedef InputIterator        iter_type</pre>
<pre>         explicit time_get_byname(const char*, size_t refs = 0);
       protected:
        ~time_get_byname();          //  virtual
       };
     }</pre>
<p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
<pre>     namespace std {
       template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
       class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
       {
       public:
         typedef charT          char_type;
         typedef OutputIterator iter_type;</pre>
<pre>         explicit time_put_byname(const char*, size_t refs = 0);
       protected:
        ~time_put_byname();          //  virtual
       };
     }"</pre>
<p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
<pre>     namespace std {
       template &lt;class charT, bool Intl = false&gt;
       class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
       public:
         typedef money_base::pattern pattern;
         typedef basic_string&lt;charT&gt; string_type;</pre>
<pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
       protected:
        ~moneypunct_byname();        //  virtual
       };
     }</pre>
<p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
<pre>     namespace std {
       template &lt;class charT&gt;
       class messages_byname : public messages&lt;charT&gt; {
       public:
         typedef messages_base::catalog catalog;
         typedef basic_string&lt;charT&gt;    string_type;</pre>
<pre>         explicit messages_byname(const char*, size_t refs = 0);
       protected:
        ~messages_byname();          //  virtual
       };
     }</pre>
<p>Remove section 22.4.1.4 [locale.codecvt] completely (because in
this case only those members are defined to be virtual which are
defined to be virtual in 'ctype&lt;cT&gt;'.)</p>

<p><i>[Post-Tokyo: Dietmar K�hl submitted this issue at the request of
the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p>


<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
three last virtual functions from <tt>messages_byname</tt>.]</i></p>







<hr>
<h3><a name="229"></a>229. Unqualified references of other library entities</h3>
<p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2000-04-19 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Throughout the library chapters, the descriptions of library entities refer
to other library entities without necessarily qualifying the names.</p>

<p>For example, section 25.2.2 "Swap" describes the effect of
swap_ranges in terms of the unqualified name "swap". This section
could reasonably be interpreted to mean that the library must be implemented so
as to do a lookup of the unqualified name "swap", allowing users to
override any ::std::swap function when Koenig lookup applies.</p>

<p>Although it would have been best to use explicit qualification with
"::std::" throughout, too many lines in the standard would have to be
adjusted to make that change in a Technical Corrigendum.</p>

<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
<tt>size_t</tt>, is a special case of this.
</p>


<p><b>Proposed resolution:</b></p>
<p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
<blockquote>
  <p>Whenever a name x defined in the standard library is mentioned, the name x
  is assumed to be fully qualified as ::std::x, unless explicitly described
  otherwise. For example, if the Effects section for library function F is
  described as calling library function G, the function ::std::G is meant.</p>
</blockquote>

<p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
the LWG to solve a problem in the standard itself similar to the
problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>.  Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be
coordinated with the resolution of this issue.]</i></p>


<p><i>[post-Toronto: Howard is undecided about whether it is
appropriate for all standard library function names referred to in
other standard library functions to be explicitly qualified by
<tt>std</tt>: it is common advice that users should define global
functions that operate on their class in the same namespace as the 
class, and this requires argument-dependent lookup if those functions
are intended to be called by library code.  Several LWG members are
concerned that valarray appears to require argument-dependent lookup,
but that the wording may not be clear enough to fall under
"unless explicitly described otherwise".]</i></p>


<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
225, 226, and 229.  Their conclusion was that the issues should be
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
EWG portion (Dave will write a proposal). The LWG and EWG had
(separate) discussions of this plan the next day.  This paper resolves
issues 225 and 226.  In light of that resolution, the proposed
resolution for the current issue makes sense.]</i></p>







<hr>
<h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-04-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where
Assignable was specified without also specifying
CopyConstructible. The LWG asked that the standard be searched to
determine if the same defect existed elsewhere.</p>

<p>There are a number of places (see proposed resolution below) where
Assignable is specified without also specifying
CopyConstructible. There are also several cases where both are
specified. For example, 26.5.1 [rand.req].</p>


<p><b>Proposed resolution:</b></p>
<p>In  23.2 [container.requirements] table 65 for value_type:
change "T is Assignable" to "T is CopyConstructible and
Assignable"
</p>

<p>In 23.2.4 [associative.reqmts] table 69 X::key_type; change
"Key is Assignable" to "Key is
CopyConstructible and Assignable"<br>
</p>

<p>In 24.2.4 [output.iterators] paragraph 1, change:
</p>
<blockquote>
<p> A class or a built-in type X satisfies the requirements of an
output iterator if X is an Assignable type (23.1) and also the
following expressions are valid, as shown in Table 73:
</p>
</blockquote>
<p>to:
</p>
<blockquote>
<p> A class or a built-in type X satisfies the requirements of an
output iterator if X is a CopyConstructible (20.1.3) and Assignable
type (23.1) and also the following expressions are valid, as shown in
Table 73:
</p>
</blockquote>

<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
the LWG.  He asks that the 25.3.5 [alg.replace] and 25.3.6 [alg.fill] changes be studied carefully, as it is not clear that
CopyConstructible is really a requirement and may be
overspecification.]</i></p>


<p><i>[Portions of the resolution for issue 230 have been superceded by
the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>




<p><b>Rationale:</b></p>
<p>The original proposed resolution also included changes to input
iterator, fill, and replace.  The LWG believes that those changes are
not necessary.  The LWG considered some blanket statement, where an
Assignable type was also required to be Copy Constructible, but
decided against this because fill and replace really don't require the
Copy Constructible property.</p>




<hr>
<h3><a name="231"></a>231. Precision in iostream?</h3>
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> James Kanze, Stephen Clamage <b>Opened:</b> 2000-04-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>What is the following program supposed to output?</p>
<pre>#include &lt;iostream&gt;

    int
    main()
    {
        std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
        std::cout.precision( 0 ) ;
        std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
        return 0 ;
    }</pre>
<p>From my C experience, I would expect "1e+00"; this is what 
<tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs 
"1.000000e+00".</p>

<p>The only indication I can find in the standard is 22.2.2.2.2/11,
where it says "For conversion from a floating-point type, if
(flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
str.precision() is specified in the conversion specification."
This is an obvious error, however, fixed is not a mask for a field,
but a value that a multi-bit field may take -- the results of and'ing
fmtflags with ios::fixed are not defined, at least not if
ios::scientific has been set. G++'s behavior corresponds to what might
happen if you do use (flags &amp; fixed) != 0 with a typical
implementation (floatfield == 3 &lt;&lt; something, fixed == 1
&lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>

<p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
(flags &amp; floatfield) == fixed; the first gives something more or
less like the effect of precision in a printf floating point
conversion. Only more or less, of course. In order to implement printf
formatting correctly, you must know whether the precision was
explicitly set or not. Say by initializing it to -1, instead of 6, and
stating that for floating point conversions, if precision &lt; -1, 6
will be used, for fixed point, if precision &lt; -1, 1 will be used,
etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
0, 1 should be = used. But it probably isn't necessary to emulate all
of the anomalies of printf:-).</p>


<p><b>Proposed resolution:</b></p>
<p>
Replace 22.4.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following 
sentence:
</p>
<blockquote><p>
For conversion from a floating-point type,
<tt><i>str</i>.precision()</tt> is specified in the conversion
specification.
</p></blockquote>


<p><b>Rationale:</b></p>
<p>The floatfield determines whether numbers are formatted as if
with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
if <tt>scientific</tt> it's %e, and if both bits are set, or 
neither, it's %g.</p>
<p>Turning to the C standard, a precision of 0 is meaningful
for %f and %e.  For %g, precision 0 is taken to be the same as 
precision 1.</p>
<p>The proposed resolution has the effect that if neither
<tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
specifying a precision of 0, which will be internally
turned into 1.  There's no need to call it out as a special
case.</p>
<p>The output of the above program will be "1e+00".</p>

<p><i>[Post-Cura�ao: Howard provided improved wording covering the case
where precision is 0 and mode is %g.]</i></p>







<hr>
<h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
<p><b>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-04-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
specializations of standard templates to those that "depend on a
user-defined name of external linkage."</p>
<p>This term, however, is not adequately defined, making it possible to
construct a specialization that is, I believe, technically legal according to
17.4.3.1/1, but that specializes a standard template for a built-in type such as
'int'.</p>
<p>The following code demonstrates the problem:</p>
<blockquote>
  <pre>#include &lt;algorithm&gt;</pre>
  <pre>template&lt;class T&gt; struct X
{
 typedef T type;
};</pre>
  <pre>namespace std
{
 template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
}</pre>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>Change "user-defined name" to "user-defined
type".</p>


<p><b>Rationale:</b></p>
<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
Programming Language</i>.  It disallows the example in the issue,
since the underlying type itself is not user-defined.  The only
possible problem I can see is for non-type templates, but there's no
possible way for a user to come up with a specialization for bitset,
for example, that might not have already been specialized by the
implementor?</p>

<p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>.]</i></p>


<p><i>[post-Toronto: Judy provided the above proposed resolution and
rationale.]</i></p>






<hr>
<h3><a name="233"></a>233. Insertion hints in associative containers</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-04-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#192">192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#246">246</a></p>
<p><b>Discussion:</b></p>
<p>
If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
into the multimap, then <tt>mm.insert(p, x)</tt> inserts
<tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
to where it should go.  Table 69 claims that the execution time is
amortized constant if the insert winds up taking place adjacent to
<tt>p</tt>, but does not say when, if ever, this is guaranteed to
happen.  All it says it that <tt>p</tt> is a hint as to where to
insert.
</p>
<p>
The question is whether there is any guarantee about the relationship
between <tt>p</tt> and the insertion point, and, if so, what it
is.
</p>
<p>
I believe the present state is that there is no guarantee: The user
can supply <tt>p</tt>, and the implementation is allowed to
disregard it entirely.
</p>

<p><b>Additional comments from Nathan:</b><br>

The vote [in Redmond] was on whether to elaborately specify the use of
the hint, or to require behavior only if the value could be inserted
adjacent to the hint.  I would like to ensure that we have a chance to
vote for a deterministic treatment: "before, if possible, otherwise
after, otherwise anywhere appropriate", as an alternative to the
proposed "before or after, if possible, otherwise [...]".
</p>

<p><i>[Toronto: there was general agreement that this is a real defect:
when inserting an element x into a multiset that already contains
several copies of x, there is no way to know whether the hint will be
used.  The proposed resolution was that the new element should always
be inserted as close to the hint as possible.  So, for example, if
there is a subsequence of equivalent values, then providing a.begin()
as the hint means that the new element should be inserted before the
subsequence even if a.begin() is far away.  JC van Winkel supplied
precise wording for this proposed resolution, and also for an
alternative resolution in which hints are only used when they are
adjacent to the insertion point.]</i></p>


<p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
in which an insertion hint would be used even when it is far from the
insertion point.  This was contingent on seeing a example
implementation showing that it is possible to implement this
requirement without loss of efficiency.  John Potter provided such a
example implementation.]</i></p>


<p><i>[Redmond: The LWG was reluctant to adopt the proposal that
emerged from Copenhagen: it seemed excessively complicated, and went
beyond fixing the defect that we identified in Toronto.  PJP provided
the new wording described in this issue.  Nathan agrees that we
shouldn't adopt the more detailed semantics, and notes: "we know that
you can do it efficiently enough with a red-black tree, but there are
other (perhaps better) balanced tree techniques that might differ
enough to make the detailed semantics hard to satisfy."]</i></p>


<p><i>[Cura�ao: Nathan should give us the alternative wording he
suggests so the LWG can decide between the two options.]</i></p>


<p><i>[Lillehammer: The LWG previously rejected the more detailed
  semantics, because it seemed more loike a new feature than like
  defect fixing.  We're now more sympathetic to it, but we (especially
  Bill) are still worried about performance.  N1780 describes a naive
  algorithm, but it's not clear whether there is a non-naive
  implementation. Is it possible to implement this as efficently as
  the current version of insert?]</i></p>


<p><i>[Post Lillehammer:
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">N1780</a>
updated in post meeting mailing with
feedback from Lillehammer with more information regarding performance.
]</i></p>


<p><i>[
Batavia:
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
accepted with minor wording changes in the proposed wording (reflected in the
proposed resolution below).  Concerns about the performance of the algorithm
were satisfactorily met by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a> already handles the stability of equal ranges
and so that part of the resolution from
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
is no longer needed (or reflected in the proposed wording below).
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Change the indicated rows of the "Associative container requirements" Table in
23.2.4 [associative.reqmts] to:
</p>

<p></p><center>
<table border="1">
<caption>Associative container requirements</caption>
<tbody><tr><th>expression</th> <th>return type</th>
<th>assertion/note<br>pre/post-condition</th>
<th>complexity</th></tr>
<tr><td><tt>a_eq.insert(t)</tt></td>
<td><tt>iterator</tt></td>
<td>
inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
element. <ins>If a range containing elements equivalent to <tt>t</tt> exists in
<tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</ins>
</td>
<td>
logarithmic
</td></tr>
<tr><td><tt>a.insert(p,t)</tt></td>
<td><tt>iterator</tt></td>
<td>
inserts <tt>t</tt> if and only if there is no element with key equivalent to the
key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in containers
with equivalent keys. always returns the iterator pointing to the element with key
equivalent to the key of <tt>t</tt>. <del>iterator <tt>p</tt> is a hint pointing to where
the insert should start to search.</del> <ins><tt>t</tt> is inserted as close as possible
to the position just prior to <tt>p</tt>.</ins>
</td>
<td>
logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <del>after</del>
 <ins>before</ins> <tt>p</tt>.
</td></tr>
</tbody></table>
</center><p></p>






<hr>
<h3><a name="234"></a>234. Typos in allocator definition</h3>
<p><b>Section:</b> 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
<tt>destruct()</tt> are described as returns but the functions actually
return <tt>void</tt>.</p>


<p><b>Proposed resolution:</b></p>
<p>Substitute "Returns" by "Effect".</p>




<hr>
<h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3>
<p><b>Section:</b> 24.5.1.1 [reverse.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The declaration of <tt>reverse_iterator</tt> lists a default
constructor.  However, no specification is given what this constructor
should do.</p>


<p><b>Proposed resolution:</b></p>
  <p>In section 24.5.1.3.1 [reverse.iter.cons] add the following
  paragraph:</p>
      <blockquote>
      <p><tt>reverse_iterator()</tt></p>

      <p>Default initializes <tt>current</tt>. Iterator operations
      applied to the resulting iterator have defined behavior if and
      only if the corresponding operations are defined on a default
      constructed iterator of type <tt>Iterator</tt>.</p>
      </blockquote>
  <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
  resolution.]</i></p>






<hr>
<h3><a name="237"></a>237. Undefined expression in complexity specification</h3>
<p><b>Section:</b> 23.3.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The complexity specification in paragraph 6 says that the complexity
is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
defined on iterators this term is in general undefined because it
would have to be <tt>last - first</tt>.</p>


<p><b>Proposed resolution:</b></p>
  <p>Change paragraph 6 from</p>
     <blockquote><p>Linear in <i>first - last</i>.</p></blockquote>
  <p>to become</p>
     <blockquote><p>Linear in <i>distance(first, last)</i>.</p></blockquote>




<hr>
<h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3>
<p><b>Section:</b> 27.8.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-05-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.cons">issues</a> in [stringbuf.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
that far but consider this code:</p>

<pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
  std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
</pre>

<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
the output sequence nor the input sequence is initialized and
paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
returns the input or the output sequence. None of them is initialized,
ie. both are empty, in which case the return from <tt>str()</tt> is
defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>

<p>However, probably only test cases in some testsuites will detect this
"problem"...</p>


<p><b>Proposed resolution:</b></p>
<p>Remove 27.7.1.1 paragraph 4.</p>


<p><b>Rationale:</b></p>
<p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
we fixed it, it would say just the same thing as text that's already
in the standard.</p>




<hr>
<h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3>
<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The complexity of unique and unique_copy are inconsistent with each
other and inconsistent with the implementations.&nbsp; The standard
specifies:</p>

<p>for unique():</p>

<blockquote><p>-3- Complexity: If the range (last - first) is not empty, exactly
(last - first) - 1 applications of the corresponding predicate, otherwise
no applications of the predicate.</p></blockquote>

<p>for unique_copy():</p>

<blockquote><p>-7- Complexity: Exactly last - first applications of the corresponding
predicate.</p></blockquote>

<p>
The implementations do it the other way round: unique() applies the
predicate last-first times and unique_copy() applies it last-first-1
times.</p>

<p>As both algorithms use the predicate for pair-wise comparison of
sequence elements I don't see a justification for unique_copy()
applying the predicate last-first times, especially since it is not
specified to which pair in the sequence the predicate is applied
twice.</p>


<p><b>Proposed resolution:</b></p>
<p>Change both complexity sections in 25.3.9 [alg.unique] to:</p>

<blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1
applications of the corresponding predicate.</p></blockquote>






<hr>
<h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
<p><b>Section:</b> 25.2.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.adjacent.find">issues</a> in [alg.adjacent.find].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The complexity section of adjacent_find is defective:</p>

<blockquote>
<pre>template &lt;class ForwardIterator&gt;
ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
                              BinaryPredicate pred);
</pre>

<p>-1- Returns: The first iterator i such that both i and i + 1 are in
the range [first, last) for which the following corresponding
conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
last if no such iterator is found.</p>

<p>-2- Complexity: Exactly find(first, last, value) - first applications
of the corresponding predicate.
</p>
</blockquote>

<p>In the Complexity section, it is not defined what "value"
is supposed to mean. My best guess is that "value" means an
object for which one of the conditions pred(*i,value) or
pred(value,*i) is true, where i is the iterator defined in the Returns
section. However, the value type of the input sequence need not be
equality-comparable and for this reason the term find(first, last,
value) - first is meaningless.</p>

<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
find_if(first, last, bind1st(pred,*i)) - first might come closer to
the intended specification.  Binders can only be applied to function
objects that have the function call operator declared const, which is
not required of predicates because they can have non-const data
members. For this reason, a specification using a binder could only be
an "as-if" specification.</p>


<p><b>Proposed resolution:</b></p>
<p>Change the complexity section in 25.2.8 [alg.adjacent.find] to:</p>
<blockquote><p>
For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
return value.
</p></blockquote>

<p><i>[Copenhagen: the original resolution specified an upper
bound.  The LWG preferred an exact count.]</i></p>







<hr>
<h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3>
<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>Some popular implementations of unique_copy() create temporary
copies of values in the input sequence, at least if the input iterator
is a pointer.  Such an implementation is built on the assumption that
the value type is CopyConstructible and Assignable.</p>

<p>It is common practice in the standard that algorithms explicitly
specify any additional requirements that they impose on any of the
types used by the algorithm. An example of an algorithm that creates
temporary copies and correctly specifies the additional requirements
is accumulate(), 26.5.1 [rand.req].</p>

<p>Since the specifications of unique() and unique_copy() do not
require CopyConstructible and Assignable of the InputIterator's value
type the above mentioned implementations are not standard-compliant. I
cannot judge whether this is a defect in the standard or a defect in
the implementations.</p>


<p><b>Proposed resolution:</b></p>
<p>In 25.2.8 change:</p>

<blockquote><p>
-4- Requires: The ranges [first, last) and [result, result+(last-first))
shall not overlap.
</p></blockquote>

<p>to:</p>

<blockquote>
  <p>-4- Requires: The ranges [first, last) and [result,
  result+(last-first)) shall not overlap. The expression *result =
  *first must be valid. If neither InputIterator nor OutputIterator
  meets the requirements of forward iterator then the value type of
  InputIterator must be copy constructible. Otherwise copy
  constructible is not required. </p>
</blockquote>

<p><i>[Redmond: the original proposed resolution didn't impose an
explicit requirement that the iterator's value type must be copy
constructible, on the grounds that an input iterator's value type must
always be copy constructible.  Not everyone in the LWG thought that
this requirement was clear from table 72.  It has been suggested that
it might be possible to implement <tt>unique_copy</tt> without
requiring assignability, although current implementations do impose
that requirement.  Howard provided new wording.]</i></p>


<p><i>[
Cura�ao: The LWG changed the PR editorially to specify
"neither...nor...meet..." as clearer than
"both...and...do not meet...". Change believed to be so
minor as not to require re-review.
]</i></p>








<hr>
<h3><a name="242"></a>242. Side effects of function objects</h3>
<p><b>Section:</b> 25.3.4 [alg.transform], 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The algorithms transform(), accumulate(), inner_product(),
partial_sum(), and adjacent_difference() require that the function
object supplied to them shall not have any side effects.</p>

<p>The standard defines a side effect in 1.9 [intro.execution] as:</p>
<blockquote><p>-7- Accessing an object designated by a volatile lvalue (basic.lval),
modifying an object, calling a library I/O function, or calling a function
that does any of those operations are all side effects, which are changes
in the state of the execution environment.</p></blockquote>

<p>As a consequence, the function call operator of a function object supplied
to any of the algorithms listed above cannot modify data members, cannot
invoke any function that has a side effect, and cannot even create and
modify temporary objects.&nbsp; It is difficult to imagine a function object
that is still useful under these severe limitations. For instance, any
non-trivial transformator supplied to transform() might involve creation
and modification of temporaries, which is prohibited according to the current
wording of the standard.</p>

<p>On the other hand, popular implementations of these algorithms exhibit
uniform and predictable behavior when invoked with a side-effect-producing
function objects. It looks like the strong requirement is not needed for
efficient implementation of these algorithms.</p>

<p>The requirement of&nbsp; side-effect-free function objects could be
replaced by a more relaxed basic requirement (which would hold for all
function objects supplied to any algorithm in the standard library):</p>
<blockquote><p>A function objects supplied to an algorithm shall not invalidate
any iterator or sequence that is used by the algorithm. Invalidation of
the sequence includes destruction of the sorting order if the algorithm
relies on the sorting order (see section 25.3 - Sorting and related operations
[lib.alg.sorting]).</p></blockquote>

<p>I can't judge whether it is intended that the function objects supplied
to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
shall not modify sequence elements through dereferenced iterators.</p>

<p>It is debatable whether this issue is a defect or a change request.
Since the consequences for user-supplied function objects are drastic and
limit the usefulness of the algorithms significantly I would consider it
a defect.</p>


<p><b>Proposed resolution:</b></p>

<p><i>Things to notice about these changes:</i></p>

<ol>
<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
     are intentional. we want to prevent side-effects from
     invalidating the end iterators.</i></li>

<li> <i>That has the unintentional side-effect of prohibiting
     modification of the end element as a side-effect. This could
     conceivably be significant in some cases.</i></li>

<li> <i>The wording also prevents side-effects from modifying elements
     of the output sequence. I can't imagine why anyone would want
     to do this, but it is arguably a restriction that implementors
     don't need to place on users.</i></li>

<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
     and simple, but would require more verbiage.</i></li>
</ol>

<p>Change 25.2.3/2 from:</p>

<blockquote><p>
   -2- Requires: op and binary_op shall not have any side effects.
</p></blockquote>

<p>to:</p>

<blockquote><p>
  -2- Requires: in the ranges [first1, last1], [first2, first2 +
  (last1 - first1)] and [result, result + (last1- first1)], op and
  binary_op shall neither modify elements nor invalidate iterators or
  subranges.
  [Footnote: The use of fully closed ranges is intentional --end footnote]
</p></blockquote>


<p>Change 25.2.3/2 from:</p>

<blockquote><p>
   -2- Requires: op and binary_op shall not have any side effects. 
</p></blockquote>

<p>to:</p>

<blockquote><p>
  -2- Requires: op and binary_op shall not invalidate iterators or
   subranges, or modify elements in the ranges [first1, last1],
   [first2, first2 + (last1 - first1)], and [result, result + (last1
   - first1)].
  [Footnote: The use of fully closed ranges is intentional --end footnote]
</p></blockquote>


<p>Change 26.4.1/2 from:</p>

<blockquote><p>
  -2- Requires: T must meet the requirements of CopyConstructible
   (lib.copyconstructible) and Assignable (lib.container.requirements)
   types. binary_op shall not cause side effects.
</p></blockquote>

<p>to:</p>

<blockquote><p>
  -2- Requires: T must meet the requirements of CopyConstructible
   (lib.copyconstructible) and Assignable
   (lib.container.requirements) types. In the range [first, last],
   binary_op shall neither modify elements nor invalidate iterators
   or subranges.
  [Footnote: The use of a fully closed range is intentional --end footnote]
</p></blockquote>

<p>Change 26.4.2/2 from:</p>

<blockquote><p>
  -2- Requires: T must meet the requirements of CopyConstructible
   (lib.copyconstructible) and Assignable (lib.container.requirements)
   types. binary_op1 and binary_op2 shall not cause side effects.
</p></blockquote>

<p>to:</p>

<blockquote><p>
  -2- Requires: T must meet the requirements of CopyConstructible
   (lib.copyconstructible) and Assignable (lib.container.requirements)
   types. In the ranges [first, last] and [first2, first2 + (last -
   first)], binary_op1 and binary_op2 shall neither modify elements
   nor invalidate iterators or subranges.
  [Footnote: The use of fully closed ranges is intentional --end footnote]
</p></blockquote>


<p>Change 26.4.3/4 from:</p>

<blockquote><p>
  -4- Requires: binary_op is expected not to have any side effects.
</p></blockquote>

<p>to:</p>

<blockquote><p>
  -4- Requires: In the ranges [first, last] and [result, result +
   (last - first)], binary_op shall neither modify elements nor
   invalidate iterators or subranges.
  [Footnote: The use of fully closed ranges is intentional --end footnote]
</p></blockquote>

<p>Change 26.4.4/2 from:</p>

<blockquote><p>
  -2- Requires: binary_op shall not have any side effects.
</p></blockquote>

<p>to:</p>

<blockquote><p>
  -2- Requires: In the ranges [first, last] and [result, result +
   (last - first)], binary_op shall neither modify elements nor
   invalidate iterators or subranges.
  [Footnote: The use of fully closed ranges is intentional --end footnote]
</p></blockquote>

<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>


<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
added footnotes pointing out that the use of closed ranges was
intentional.]</i></p>







<hr>
<h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
are unclear with respect to the behavior and side-effects of the named
functions in case of an error.</p>

<p>27.6.1.3, p1 states that "... If the sentry object returns
true, when converted to a value of type bool, the function endeavors
to obtain the requested input..." It is not clear from this (or
the rest of the paragraph) what precisely the behavior should be when
the sentry ctor exits by throwing an exception or when the sentry
object returns false.  In particular, what is the number of characters
extracted that gcount() returns supposed to be?</p>

<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
"...  In any case, it then stores a null character (using
charT()) into the next successive location of the array." Is not
clear whether this sentence applies if either of the conditions above
holds (i.e., when sentry fails).</p>


<p><b>Proposed resolution:</b></p>
<p>Add to 27.6.1.3, p1 after the sentence</p>

<blockquote><p>
"... If the sentry object returns true, when converted to a value of
type bool, the function endeavors to obtain the requested input."
</p></blockquote>

<p>the following</p>


<blockquote><p>
"Otherwise, if the sentry constructor exits by throwing an exception or
if the sentry object returns false, when converted to a value of type
bool, the function returns without attempting to obtain any input. In
either case the number of extracted characters is set to 0; unformatted
input functions taking a character array of non-zero size as an argument
shall also store a null character (using charT()) in the first location
of the array."
</p></blockquote>


<p><b>Rationale:</b></p>
<p>Although the general philosophy of the input functions is that the
argument should not be modified upon failure, <tt>getline</tt>
historically added a terminating null unconditionally.  Most
implementations still do that.  Earlier versions of the draft standard
had language that made this an unambiguous requirement; those words
were moved to a place where their context made them less clear.  See
Jerry Schwarz's message c++std-lib-7618.</p>




<hr>
<h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
<p><b>Section:</b> 23.4.1.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-06-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 2 of 23.4.1.4 [vector.modifiers] describes the complexity
of <tt>vector::insert</tt>:</p>

   <blockquote><p>
   Complexity: If first and last are forward iterators, bidirectional
   iterators, or random access iterators, the complexity is linear in
   the number of elements in the range [first, last) plus the distance
   to the end of the vector. If they are input iterators, the complexity
   is proportional to the number of elements in the range [first, last)
   times the distance to the end of the vector.
   </p></blockquote>

<p>First, this fails to address the non-iterator forms of
<tt>insert</tt>.</p>

<p>Second, the complexity for input iterators misses an edge case --
it requires that an arbitrary number of elements can be added at
the end of a <tt>vector</tt> in constant time.</p>

<p>I looked to see if <tt>deque</tt> had a similar problem, and was
surprised to find that <tt>deque</tt> places no requirement on the
complexity of inserting multiple elements (23.3.2.3 [deque.modifiers],
paragraph 3):</p>

   <blockquote><p>
   Complexity: In the worst case, inserting a single element into a
   deque takes time linear in the minimum of the distance from the
   insertion point to the beginning of the deque and the distance
   from the insertion point to the end of the deque. Inserting a
   single element either at the beginning or end of a deque always
   takes constant time and causes a single call to the copy constructor
   of T.
   </p></blockquote>


<p><b>Proposed resolution:</b></p>

<p>Change Paragraph 2 of 23.4.1.4 [vector.modifiers] to</p>
   <blockquote><p>
   Complexity: The complexity is linear in the number of elements 
   inserted plus the distance to the end of the vector.
   </p></blockquote>

   <p><i>[For input iterators, one may achieve this complexity by first
   inserting at the end of the <tt>vector</tt>, and then using
   <tt>rotate</tt>.]</i></p>


<p>Change 23.3.2.3 [deque.modifiers], paragraph 3, to:</p>

   <blockquote><p>
   Complexity: The complexity is linear in the number of elements 
   inserted plus the shorter of the distances to the beginning and
   end of the deque.  Inserting a single element at either the
   beginning or the end of a deque causes a single call to the copy
   constructor of T.
   </p></blockquote>



<p><b>Rationale:</b></p>
<p>This is a real defect, and proposed resolution fixes it: some
  complexities aren't specified that should be.  This proposed
  resolution does constrain deque implementations (it rules out the
  most naive possible implementations), but the LWG doesn't see a
  reason to permit that implementation.</p>





<hr>
<h3><a name="248"></a>248. time_get fails to set eofbit</h3>
<p><b>Section:</b> 22.4.5 [category.time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-06-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>There is no requirement that any of time_get member functions set
ios::eofbit when they reach the end iterator while parsing their input.
Since members of both the num_get and money_get facets are required to
do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
should follow the same requirement for consistency.</p>


<p><b>Proposed resolution:</b></p>
<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>

<blockquote><p>
If the end iterator is reached during parsing by any of the get()
member functions, the member sets ios_base::eofbit in err.
</p></blockquote>


<p><b>Rationale:</b></p>
<p>Two alternative resolutions were proposed.  The LWG chose this one
because it was more consistent with the way eof is described for other
input facets.</p>




<hr>
<h3><a name="250"></a>250. splicing invalidates iterators</h3>
<p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Brian Parker  <b>Opened:</b> 2000-07-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 23.3.4.4 [list.ops] states that
</p>
<pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
</pre>
<p>
<i>invalidates</i> all iterators and references to list <tt>x</tt>.
</p>

<p>
This is unnecessary and defeats an important feature of splice. In
fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
after <tt>splice</tt>.
</p>


<p><b>Proposed resolution:</b></p>

<p>Add a footnote to 23.3.4.4 [list.ops], paragraph 1:</p>
<blockquote><p>
[<i>Footnote:</i> As specified in  [default.con.req], paragraphs
4-5, the semantics described in this clause applies only to the case
where allocators compare equal.  --end footnote]
</p></blockquote>

<p>In 23.3.4.4 [list.ops], replace paragraph 4 with:</p>
<blockquote><p>
Effects: Inserts the contents of x before position and x becomes 
empty.  Pointers and references to the moved elements of x now refer to 
those same elements but as members of *this.  Iterators referring to the 
moved elements will continue to refer to their elements, but they now 
behave as iterators into *this, not into x.
</p></blockquote>

<p>In 23.3.4.4 [list.ops], replace paragraph 7 with:</p>
<blockquote><p>
Effects: Inserts an element pointed to by i from list x before 
position and removes the element from x. The result is unchanged if 
position == i or position == ++i.  Pointers and references to *i continue 
to refer to this same element but as a member of *this.  Iterators to *i 
(including i itself) continue to refer to the same element, but now 
behave as iterators into *this, not into x.
</p></blockquote>

<p>In 23.3.4.4 [list.ops], replace paragraph 12 with:</p>
<blockquote><p>
Requires: [first, last) is a valid range in x. The result is 
undefined if position is an iterator in the range [first, last).  
Pointers and references to the moved elements of x now refer to those 
same elements but as members of *this.  Iterators referring to the moved 
elements will continue to refer to their elements, but they now behave as 
iterators into *this, not into x.
</p></blockquote>

<p><i>[pre-Copenhagen: Howard provided wording.]</i></p>



<p><b>Rationale:</b></p>
<p>The original proposed resolution said that iterators and references
would remain "valid".  The new proposed resolution clarifies what that
means.  Note that this only applies to the case of equal allocators.
From  [default.con.req] paragraph 4, the behavior of list when
allocators compare nonequal is outside the scope of the standard.</p>




<hr>
<h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3>
<p><b>Section:</b> 27.8.1 [stringbuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis for the template class <tt>basic_stringbuf</tt>
doesn't list a typedef for the template parameter
<tt>Allocator</tt>. This makes it impossible to determine the type of
the allocator at compile time. It's also inconsistent with all other
template classes in the library that do provide a typedef for the
<tt>Allocator</tt> parameter.</p>


<p><b>Proposed resolution:</b></p>
<p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and 
basic_stringstream (27.7.4) the typedef:</p>
<pre>  typedef Allocator allocator_type;
</pre>




<hr>
<h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</h3>
<p><b>Section:</b> 27.8 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
the cast altogether.</p>

<p>C-style casts have not been deprecated, so the first part of this
issue is stylistic rather than a matter of correctness.</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.7.2.2, p1 replace </p>
<pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>

<p>with</p>
<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>


<p>In 27.7.3.2, p1 replace</p>
<pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>

<p>with</p>
<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>

<p>In 27.7.6, p1, replace</p>
<pre>  -1- Returns: &amp;sb</pre>

<p>with</p>
<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>

<p>In D.7.2.2, p1 replace</p>
<pre>  -2- Returns: &amp;sb. </pre>

<p>with</p>
<pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>




<hr>
<h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
<p><b>Section:</b> 26.6.2.1 [valarray.cons], 26.6.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2000-07-31 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>This discussion is adapted from message c++std-lib-7056 posted
November 11, 1999.  I don't think that anyone can reasonably claim
that the problem described below is NAD.</p>

<p>These valarray constructors can never be called:</p>

<pre>   template &lt;class T&gt;
         valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
   template &lt;class T&gt;
         valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
   template &lt;class T&gt;
         valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
   template &lt;class T&gt;
         valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
</pre>

<p>Similarly, these valarray assignment operators cannot be
called:</p>

<pre>     template &lt;class T&gt;
     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
     template &lt;class T&gt;
     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
     template &lt;class T&gt;
     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
     template &lt;class T&gt;
     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
</pre>

<p>Please consider the following example:</p>

<pre>   #include &lt;valarray&gt;
   using namespace std;

   int main()
   {
       valarray&lt;double&gt; va1(12);
       valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
   }
</pre>


<p>Since the valarray va1 is non-const, the result of the sub-expression
va1[slice(1,4,3)] at line 1 is an rvalue of type const
std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
construct va2.  The constructor that is used to construct va2 is
declared like this:</p>

<pre>     template &lt;class T&gt;
     valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
</pre>

<p>Notice the constructor's const reference parameter.  When the
constructor is called, a slice_array must be bound to this reference.
The rules for binding an rvalue to a const reference are in 8.5.3,
paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
indicates that a second slice_array rvalue is constructed (in this
case copy-constructed) from the first one; it is this second rvalue
that is bound to the reference parameter.  Paragraph 5 also requires
that the constructor that is used for this purpose be callable,
regardless of whether the second rvalue is elided.  The
copy-constructor in this case is not callable, however, because it is
private.  Therefore, the compiler should report an error.</p>

<p>Since slice_arrays are always rvalues, the valarray constructor that has a
parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
same reasoning applies to the three other constructors and the four
assignment operators that are listed at the beginning of this post.
Furthermore, since these functions cannot be called, the valarray helper
classes are almost entirely useless.</p>


<p><b>Proposed resolution:</b></p>
<p>slice_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
     public in the slice_array class template definition in 26.6.5 [template.slice.array] </li>
<li> remove paragraph 3 of 26.6.5 [template.slice.array]</li>
<li> remove the copy constructor declaration from  [cons.slice.arr]</li>
<li> change paragraph 1 of  [cons.slice.arr] to read "This constructor is declared
    to be private.  This constructor need not be defined."</li>
<li> remove the first sentence of paragraph 1 of 26.6.5.1 [slice.arr.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
    26.6.5.1 [slice.arr.assign] to "These assignment operators have"</li>
</ul>

<p>gslice_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
    public in the gslice_array class template definition in 26.6.7 [template.gslice.array] </li>
<li> remove the note in paragraph 3 of 26.6.7 [template.gslice.array]</li>
<li> remove the copy constructor declaration from  [gslice.array.cons]</li>
<li> change paragraph 1 of  [gslice.array.cons] to read "This constructor is declared
    to be private.  This constructor need not be defined."</li>
<li> remove the first sentence of paragraph 1 of 26.6.7.1 [gslice.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
    26.6.7.1 [gslice.array.assign] to "These assignment operators have"</li>
</ul>

<p>mask_array:</p>
<ul>
<li> Make the copy constructor and copy-assignment operator declarations
    public in the mask_array class template definition in 26.6.8 [template.mask.array] </li>
<li> remove the note in paragraph 2 of 26.6.8 [template.mask.array]</li>
<li> remove the copy constructor declaration from  [mask.array.cons]</li>
<li> change paragraph 1 of  [mask.array.cons] to read "This constructor is declared
    to be private.  This constructor need not be defined."</li>
<li> remove the first sentence of paragraph 1 of 26.6.8.1 [mask.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
    26.6.8.1 [mask.array.assign] to "These assignment operators have"</li>
</ul>

<p>indirect_array:</p>
<ul>
<li>Make the copy constructor and copy-assignment operator declarations
    public in the indirect_array class definition in 26.6.9 [template.indirect.array]</li>
<li> remove the note in paragraph 2 of 26.6.9 [template.indirect.array]</li>
<li> remove the copy constructor declaration from  [indirect.array.cons]</li>
<li> change the descriptive text in  [indirect.array.cons] to read "This constructor is
    declared to be private.  This constructor need not be defined."</li>
<li> remove the first sentence of paragraph 1 of 26.6.9.1 [indirect.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
    26.6.9.1 [indirect.array.assign] to "These assignment operators have"</li>
</ul>
<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
copy constructor and copy assignment operators public, instead of
removing them.]</i></p>



<p><b>Rationale:</b></p>
<p>Keeping the valarray constructors private is untenable.  Merely
making valarray a friend of the helper classes isn't good enough,
because access to the copy constructor is checked in the user's
environment.</p>

<p>Making the assignment operator public is not strictly necessary to
solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
believed we should make the assignment operators public, in addition
to the copy constructors, for reasons of symmetry and user
expectation.</p>





<hr>
<h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3>
<p><b>Section:</b> 19.2 [std.exceptions], 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-08-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Many of the standard exception types which implementations are
required to throw are constructed with a const std::string&amp;
parameter. For example:
</p>

<pre>     19.1.5  Class out_of_range                          [lib.out.of.range]
     namespace std {
       class out_of_range : public logic_error {
       public:
         explicit out_of_range(const string&amp; what_arg);
       };
     }

   1 The class out_of_range defines the type of objects  thrown  as  excep-
     tions to report an argument value not in its expected range.

     out_of_range(const string&amp; what_arg);

     Effects:
       Constructs an object of class out_of_range.
     Postcondition:
       strcmp(what(), what_arg.c_str()) == 0.
</pre>

<p>
There are at least two problems with this:
</p>
<ol>
<li>A program which is low on memory may end up throwing
std::bad_alloc instead of out_of_range because memory runs out while
constructing the exception object.</li>
<li>An obvious implementation which stores a std::string data member
may end up invoking terminate() during exception unwinding because the
exception object allocates memory (or rather fails to) as it is being
copied.</li>
</ol>

<p>
There may be no cure for (1) other than changing the interface to
out_of_range, though one could reasonably argue that (1) is not a
defect. Personally I don't care that much if out-of-memory is reported
when I only have 20 bytes left, in the case when out_of_range would
have been reported. People who use exception-specifications might care
a lot, though.
</p>

<p>
There is a cure for (2), but it isn't completely obvious. I think a
note for implementors should be made in the standard. Avoiding
possible termination in this case shouldn't be left up to chance.  The
cure is to use a reference-counted "string" implementation
in the exception object. I am not necessarily referring to a
std::string here; any simple reference-counting scheme for a NTBS
would do.
</p>

<p><b>Further discussion, in email:</b></p>

<p>
...I'm not so concerned about (1). After all, a library implementation
can add const char* constructors as an extension, and users don't
<i>need</i> to avail themselves of the standard exceptions, though this is
a lame position to be forced into.  FWIW, std::exception and
std::bad_alloc don't require a temporary basic_string.
</p>

<p>
...I don't think the fixed-size buffer is a solution to the problem,
strictly speaking, because you can't satisfy the postcondition
<br>
    <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
<br>
For all values of what_arg (i.e. very long values). That means that
the only truly conforming solution requires a dynamic allocation.
</p>

<p><b>Further discussion, from Redmond:</b></p>

<p>The most important progress we made at the Redmond meeting was
realizing that there are two separable issues here: the const
string&amp; constructor, and the copy constructor.  If a user writes
something like <tt>throw std::out_of_range("foo")</tt>, the const
string&amp; constructor is invoked before anything gets thrown.  The
copy constructor is potentially invoked during stack unwinding.</p>

<p>The copy constructor is a more serious problem, becuase failure
during stack unwinding invokes <tt>terminate</tt>.  The copy
constructor must be nothrow. <i>Cura�ao: Howard thinks this
requirement may already be present.</i></p>

<p>The fundamental problem is that it's difficult to get the nothrow
requirement to work well with the requirement that the exception
objects store a string of unbounded size, particularly if you also try
to make the const string&amp; constructor nothrow.  Options discussed
include:</p>

<ul>
<li>Limit the size of a string that exception objects are required to
throw: change the postconditions of 19.2.2 [domain.error] paragraph 3
and 19.2.6 [runtime.error] paragraph 3 to something like this:
"strncmp(what(), what_arg._str(), N) == 0, where N is an
implementation defined constant no smaller than 256".</li>
<li>Allow the const string&amp; constructor to throw, but not the
copy constructor.  It's the implementor's responsibility to get it
right.  (An implementor might use a simple refcount class.)</li>
<li>Compromise between the two: an implementation is not allowed to
throw if the string's length is less than some N, but, if it doesn't
throw, the string must compare equal to the argument.</li>
<li>Add a new constructor that takes a const char*</li>
</ul>

<p>(Not all of these options are mutually exclusive.)</p>



<p><b>Proposed resolution:</b></p>

<p>
Change 19.2.1 [logic.error]
</p>

<blockquote>
<pre>namespace std {
  class logic_error : public exception {
  public:
    explicit logic_error(const string&amp; <i>what_arg</i>);
    <ins>explicit logic_error(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>logic_error(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>logic_error</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 19.2.2 [domain.error]
</p>

<blockquote>
<pre>namespace std {
  class domain_error : public logic_error {
  public:
    explicit domain_error(const string&amp; <i>what_arg</i>);
    <ins>explicit domain_error(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>domain_error(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>domain_error</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>

</blockquote>
</blockquote>

<p>
Change 19.2.3 [invalid.argument]
</p>

<blockquote>
<pre>namespace std {
  class invalid_argument : public logic_error {
  public:
    explicit invalid_argument(const string&amp; <i>what_arg</i>);
    <ins>explicit invalid_argument(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>invalid_argument(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>invalid_argument</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 19.2.4 [length.error]
</p>

<blockquote>
<pre>namespace std {
  class length_error : public logic_error {
  public:
    explicit length_error(const string&amp; <i>what_arg</i>);
    <ins>explicit length_error(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>length_error(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>length_error</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 19.2.5 [out.of.range]
</p>

<blockquote>
<pre>namespace std {
  class out_of_range : public logic_error {
  public:
    explicit out_of_range(const string&amp; <i>what_arg</i>);
    <ins>explicit out_of_range(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>out_of_range(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>out_of_range</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 19.2.6 [runtime.error]
</p>

<blockquote>
<pre>namespace std {
  class runtime_error : public exception {
  public:
    explicit runtime_error(const string&amp; <i>what_arg</i>);
    <ins>explicit runtime_error(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>runtime_error(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>runtime_error</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 19.2.7 [range.error]
</p>

<blockquote>
<pre>namespace std {
  class range_error : public runtime_error {
  public:
    explicit range_error(const string&amp; <i>what_arg</i>);
    <ins>explicit range_error(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>range_error(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>range_error</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 19.2.8 [overflow.error]
</p>

<blockquote>
<pre>namespace std {
  class overflow_error : public runtime_error {
  public:
    explicit overflow_error(const string&amp; <i>what_arg</i>);
    <ins>explicit overflow_error(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>overflow_error(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>overflow_error</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 19.2.9 [underflow.error]
</p>

<blockquote>
<pre>namespace std {
  class underflow_error : public runtime_error {
  public:
    explicit underflow_error(const string&amp; <i>what_arg</i>);
    <ins>explicit underflow_error(const char* <i>what_arg</i>);</ins>
  };
}
</pre>
<p>...</p>
<p>
<ins><tt>underflow_error(const char* <i>what_arg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>underflow_error</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 27.5.2.1.1 [ios::failure]
</p>

<blockquote>
<pre>namespace std {
  class ios_base::failure : public exception {
  public:
    explicit failure(const string&amp; <i>msg</i>);
    <ins>explicit failure(const char* <i>msg</i>);</ins>
    virtual const char* what() const throw();
};
}
</pre>
<p>...</p>
<p>
<ins><tt>failure(const char* <i>msg</i>);</tt></ins>
</p>
<blockquote>
<p><ins>
-4- <i>Effects:</i> Constructs an object of class <tt>failure</tt>.
</ins></p>
<p><ins>
-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>msg</i>) == 0</tt>.
</ins></p>
</blockquote>

</blockquote>



<p><b>Rationale:</b></p>

<p>Throwing a bad_alloc while trying to construct a message for another
exception-derived class is not necessarily a bad thing.  And the
bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>

<p><b>Future:</b></p>

<p>All involved would like to see const char* constructors added, but
this should probably be done for C++0X as opposed to a DR.</p>

<p>I believe the no throw specs currently decorating these functions
could be improved by some kind of static no throw spec checking
mechanism (in a future C++ language).  As they stand, the copy
constructors might fail via a call to unexpected.  I think what is
intended here is that the copy constructors can't fail.</p>

<p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
  Post-Redmond: James Kanze noticed that the copy constructors of
  exception-derived classes do not have nothrow clauses.  Those
  classes have no copy constructors declared, meaning the
  compiler-generated implicit copy constructors are used, and those
  compiler-generated constructors might in principle throw anything.]</i></p>


<p><i>[
Batavia:  Merged copy constructor and assignment operator spec into <tt>exception</tt>
and added <tt>ios::failure</tt> into the proposed resolution.
]</i></p>


<p><i>[
Oxford:  The proposed resolution simply addresses the issue of constructing
the exception objects with <tt>const char*</tt> and string literals without
the need to explicit include or construct a <tt>std::string</tt>.
]</i></p>







<hr>
<h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3>
<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
27.4.4.2, p17 says
</p>

<blockquote><p>
-17- Before copying any parts of rhs, calls each registered callback
pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
exceptions() have been replaced, calls each callback pair that was
copied from rhs as (*fn)(copy_event,*this,index). 
</p></blockquote>

<p>
The name copy_event isn't defined anywhere. The intended name was
copyfmt_event.
</p>


<p><b>Proposed resolution:</b></p>
<p>Replace copy_event with copyfmt_event in the named paragraph.</p>




<hr>
<h3><a name="258"></a>258. Missing allocator requirement</h3>
<p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-08-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
From lib-7752:
</p>

<p>
I've been assuming (and probably everyone else has been assuming) that
allocator instances have a particular property, and I don't think that
property can be deduced from anything in Table 32.
</p>

<p>
I think we have to assume that allocator type conversion is a
homomorphism.  That is, if x1 and x2 are of type X, where
X::value_type is T, and if type Y is X::template
rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
</p>

<p>
Further discussion: Howard Hinnant writes, in lib-7757:
</p>

<p>
I think I can prove that this is not provable by Table 32.  And I agree 
it needs to be true except for the "and only if".  If x1 != x2, I see no 
reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't 
think of a practical instance where this would happen, or be valuable.  
But I also don't see a need to add that extra restriction.  I think we 
only need:
</p>

<blockquote><p>
     if (x1 == x2) then Y(x1) == Y(x2)
</p></blockquote>

<p>
If we decide that == on allocators is transitive, then I think I can 
prove the above.  But I don't think == is necessarily transitive on 
allocators.  That is:
</p>

<p>
Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
</p>

<p>Example:</p>

<blockquote>
<p>
x1 can deallocate pointers from:  x1, x2, x3    <br>
x2 can deallocate pointers from:  x1, x2, x4    <br>
x3 can deallocate pointers from:  x1, x3        <br>
x4 can deallocate pointers from:  x2, x4 
</p>

<p>
x1 == x2, and x2 == x4, but x1 != x4
</p>
</blockquote>
<p><i>[Toronto: LWG members offered multiple opinions.  One
opinion is that it should not be required that <tt>x1 == x2</tt>
implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
required that <tt>X(x1) == x1</tt>.  Another opinion is that 
the second line from the bottom in table 32 already implies the
desired property.  This issue should be considered in light of
other issues related to allocator instances.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Accept proposed wording from
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 3.
</p>


<p><i>[Lillehammer: Same conclusion as before: this should be
  considered as part of an allocator redesign, not solved on its own.]</i></p>


<p><i>[
Batavia:  An allocator redesign is not forthcoming and thus we fixed this one issue.
]</i></p>


<p><i>[
Toronto:  Reopened at the request of the project editor (Pete) because the proposed
wording did not fit within the indicated table.  The intent of the resolution remains
unchanged.  Pablo to work with Pete on improved wording.
]</i></p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
was subsequently split out into a separate paper N2436 for the purposes of voting.
The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3>
<p><b>Section:</b> 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Chris Newton  <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
</p>

<p>
The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
seems to violate const correctness.
</p>

<p>
The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
returns <tt>data()[pos]</tt>." The types don't work.  The
return value of <tt>data()</tt> is <tt>const charT*</tt>, but
<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In section 21.3.4, paragraph 1, change
"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
<i>pos</i>)</tt>".
</p>




<hr>
<h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3>
<p><b>Section:</b> 24.6.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
it as returning the iterator by value. 24.5.1.2, p5 shows the same
operator as returning the iterator by reference. That's incorrect
given the Effects clause below (since a temporary is returned). The
`&amp;' is probably just a typo.</p>


<p><b>Proposed resolution:</b></p>
<p>Change the declaration in 24.5.1.2, p5 from</p>
 <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
 </pre>
<p>to</p>
 <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
 </pre>
<p>(that is, remove the `&amp;').</p>




<hr>
<h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3>
<p><b>Section:</b> 24.6.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
24.5.1, p3 lists the synopsis for
</p>

<pre>   template &lt;class T, class charT, class traits, class Distance&gt;
        bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
                        const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
</pre>

<p>
but there is no description of what the operator does (i.e., no Effects
or Returns clause) in 24.5.1.2.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add paragraph 7 to the end of section 24.5.1.2 with the following text:
</p>

<pre>   template &lt;class T, class charT, class traits, class Distance&gt;
        bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
                        const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
</pre>

<p>-7- Returns: !(x == y).</p>




<hr>
<h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3>
<p><b>Section:</b> 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-09-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitmask.types">issues</a> in [bitmask.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The ~ operation should be applied after the cast to int_type.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
</p>

<pre>   bitmask operator~ ( bitmask X )
     { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
</pre>

<p>
to:
</p>

<pre>   bitmask operator~ ( bitmask X )
     { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
</pre>




<hr>
<h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Kevlin Henney <b>Opened:</b> 2000-09-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The note in paragraph 6 suggests that the invalidation rules for
references, pointers, and iterators in paragraph 5 permit a reference-
counted implementation (actually, according to paragraph 6, they permit
a "reference counted implementation", but this is a minor editorial fix).
</p>

<p>
However, the last sub-bullet is so worded as to make a reference-counted
implementation unviable. In the following example none of the
conditions for iterator invalidation are satisfied:
</p>

<pre>    // first example: "*******************" should be printed twice
    string original = "some arbitrary text", copy = original;
    const string &amp; alias = original;

    string::const_iterator i = alias.begin(), e = alias.end();
    for(string::iterator j = original.begin(); j != original.end(); ++j)
        *j = '*';
    while(i != e)
        cout &lt;&lt; *i++;
    cout &lt;&lt; endl;
    cout &lt;&lt; original &lt;&lt; endl;
</pre>

<p>
Similarly, in the following example:
</p>

<pre>    // second example: "some arbitrary text" should be printed out
    string original = "some arbitrary text", copy = original;
    const string &amp; alias = original;

    string::const_iterator i = alias.begin();
    original.begin();
    while(i != alias.end())
        cout &lt;&lt; *i++;
</pre>

<p>
I have tested this on three string implementations, two of which were
reference counted. The reference-counted implementations gave
"surprising behavior" because they invalidated iterators on
the first call to non-const begin since construction. The current
wording does not permit such invalidation because it does not take
into account the first call since construction, only the first call
since various member and non-member function calls.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the following sentence in 21.3 paragraph 5 from
</p>

<blockquote><p>
    Subsequent to any of the above uses except the forms of insert() and
    erase() which return iterators, the first call to non-const member
    functions operator[](), at(), begin(), rbegin(), end(), or rend().
</p></blockquote>

<p>to</p>

<blockquote><p>
    Following construction or any of the above uses, except the forms of
    insert() and erase() that return iterators, the first call to non-
    const member functions operator[](), at(), begin(), rbegin(), end(),
    or rend().
</p></blockquote>




<hr>
<h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> John Potter <b>Opened:</b> 2000-09-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p>
<p><b>Discussion:</b></p>
<p>
Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
integers in the same range.
</p>

<p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>


<p><b>Proposed resolution:</b></p>
<p>
In Table 69, in section 23.1.2, change the complexity clause for
insertion of a range from "N log(size() + N) (N is the distance
from i to j) in general; linear if [i, j) is sorted according to
value_comp()" to "N log(size() + N), where N is the distance
from i to j".
</p>

<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
parens in the revised wording.]</i></p>




<p><b>Rationale:</b></p>
<p>
Testing for valid insertions could be less efficient than simply
inserting the elements when the range is not both sorted and between
two adjacent existing elements; this could be a QOI issue.
</p>

<p> 
The LWG considered two other options: (a) specifying that the
complexity was linear if [i, j) is sorted according to value_comp()
and between two adjacent existing elements; or (b) changing to
Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
number of elements which do not insert immediately after the previous
element from [i, j) including the first).  The LWG felt that, since
we can't guarantee linear time complexity whenever the range to be
inserted is sorted, it's more trouble than it's worth to say that it's
linear in some special cases.
</p>




<hr>
<h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I don't see any requirements on the types of the elements of the
std::pair container in 20.2.2. From the descriptions of the member
functions it appears that they must at least satisfy the requirements of
20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
the case of the [in]equality operators also the requirements of 20.1.1
[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
</p>

<p>
I believe that the the CopyConstructible requirement is unnecessary in
the case of 20.2.2, p2.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change the Effects clause in 20.2.2, p2 from</p>

<blockquote><p>
-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
first(T1()), second(T2()) {} </tt>
</p></blockquote>

<p>to</p>

<blockquote><p>
-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
first(), second() {} </tt>
</p></blockquote>


<p><b>Rationale:</b></p>
<p>The existing specification of pair's constructor appears to be a
historical artifact: there was concern that pair's members be properly
zero-initialized when they are built-in types.  At one time there was
uncertainty about whether they would be zero-initialized if the
default constructor was written the obvious way.  This has been
clarified by core issue 178, and there is no longer any doubt that
the straightforward implementation is correct.</p>




<hr>
<h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3>
<p><b>Section:</b> 18.8.2 [bad.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The synopsis for std::bad_exception lists the function ~bad_exception()
but there is no description of what the function does (the Effects
clause is missing).
</p>


<p><b>Proposed resolution:</b></p>
<p>
Remove the destructor from the class synopses of 
<tt>bad_alloc</tt> (18.6.2.1 [bad.alloc]),
<tt>bad_cast</tt> (18.7.2 [bad.cast]),
<tt>bad_typeid</tt> (18.7.3 [bad.typeid]),
and <tt>bad_exception</tt> (18.8.2 [bad.exception]).
</p>


<p><b>Rationale:</b></p>
<p>
This is a general problem with the exception classes in clause 18. 
The proposed resolution is to remove the destructors from the class
synopses, rather than to document the destructors' behavior, because
removing them is more consistent with how exception classes are
described in clause 19.
</p>




<hr>
<h3><a name="268"></a>268. Typo in locale synopsis</h3>
<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
the semicolons after the declarations of the default ctor
locale::locale() and the copy ctor locale::locale(const locale&amp;)
are missing.</p>


<p><b>Proposed resolution:</b></p>
<p>Add the missing semicolons, i.e., change</p>

<pre>    //  construct/copy/destroy:
        locale() throw()
        locale(const locale&amp; other) throw()
</pre>

<p>in the synopsis in 22.1.1 to</p>

<pre>    //  construct/copy/destroy:
        locale() throw();
        locale(const locale&amp; other) throw();
</pre>




<hr>
<h3><a name="270"></a>270. Binary search requirements overly strict</h3>
<p><b>Section:</b> 25.4.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-10-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p>
<p><b>Discussion:</b></p>
<p>
Each of the four binary search algorithms (lower_bound, upper_bound,
equal_range, binary_search) has a form that allows the user to pass a
comparison function object.  According to 25.3, paragraph 2, that
comparison function object has to be a strict weak ordering.
</p>

<p>
This requirement is slightly too strict.  Suppose we are searching
through a sequence containing objects of type X, where X is some
large record with an integer key.  We might reasonably want to look
up a record by key, in which case we would want to write something
like this:
</p>
<pre>    struct key_comp {
      bool operator()(const X&amp; x, int n) const {
        return x.key() &lt; n;
      }
    }

    std::lower_bound(first, last, 47, key_comp());
</pre>

<p>
key_comp is not a strict weak ordering, but there is no reason to
prohibit its use in lower_bound.
</p>

<p>
There's no difficulty in implementing lower_bound so that it allows
the use of something like key_comp.  (It will probably work unless an
implementor takes special pains to forbid it.)  What's difficult is
formulating language in the standard to specify what kind of
comparison function is acceptable.  We need a notion that's slightly
more general than that of a strict weak ordering, one that can encompass
a comparison function that involves different types.  Expressing that
notion may be complicated.
</p>

<p><i>Additional questions raised at the Toronto meeting:</i></p>
<ul>
<li> Do we really want to specify what ordering the implementor must
     use when calling the function object?  The standard gives 
     specific expressions when describing these algorithms, but it also
     says that other expressions (with different argument order) are
     equivalent.</li>
<li> If we are specifying ordering, note that the standard uses both
     orderings when describing <tt>equal_range</tt>.</li>
<li> Are we talking about requiring these algorithms to work properly
     when passed a binary function object whose two argument types
     are not the same, or are we talking about requirements when
     they are passed a binary function object with several overloaded
     versions of <tt>operator()</tt>?</li>
<li> The definition of a strict weak ordering does not appear to give
     any guidance on issues of overloading; it only discusses expressions,
     and all of the values in these expressions are of the same type.
     Some clarification would seem to be in order.</li>
</ul>

<p><i>Additional discussion from Copenhagen:</i></p>
<ul>
<li>It was generally agreed that there is a real defect here: if
the predicate is merely required to be a Strict Weak Ordering, then
it's possible to pass in a function object with an overloaded
operator(), where the version that's actually called does something
completely inappropriate.  (Such as returning a random value.)</li>

<li>An alternative formulation was presented in a paper distributed by
David Abrahams at the meeting, "Binary Search with Heterogeneous
Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
predicate as a Strict Weak Ordering acting on a sorted sequence, view
the predicate/value pair as something that partitions a sequence.
This is almost equivalent to saying that we should view binary search
as if we are given a unary predicate and a sequence, such that f(*p)
is true for all p below a specific point and false for all p above it.
The proposed resolution is based on that alternative formulation.</li>
</ul>


<p><b>Proposed resolution:</b></p>

<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>

<blockquote><p>
  3 For all algorithms that take Compare, there is a version that uses
  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
  *j != false. For the algorithms to work correctly, comp has to
  induce a strict weak ordering on the values.
</p></blockquote>

<p>to:</p>

<blockquote><p>
  3 For all algorithms that take Compare, there is a version that uses
  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
  &lt; *j != false. For algorithms other than those described in
  lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
  a strict weak ordering on the values.
</p></blockquote>

<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>

<blockquote><p>
  -6- A sequence [start, finish) is partitioned with respect to an
  expression f(e) if there exists an integer n such that
  for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
  and only if i &lt; n.
</p></blockquote>

<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>

<blockquote><p>
  -1- All of the algorithms in this section are versions of binary
   search and assume that the sequence being searched is in order
   according to the implied or explicit comparison function. They work
   on non-random access iterators minimizing the number of
   comparisons, which will be logarithmic for all types of
   iterators. They are especially appropriate for random access
   iterators, because these algorithms do a logarithmic number of
   steps through the data structure. For non-random access iterators
   they execute a linear number of steps.
</p></blockquote>

<p>to:</p>

<blockquote><p>
   -1- All of the algorithms in this section are versions of binary
    search and assume that the sequence being searched is partitioned
    with respect to an expression formed by binding the search key to
    an argument of the implied or explicit comparison function. They
    work on non-random access iterators minimizing the number of
    comparisons, which will be logarithmic for all types of
    iterators. They are especially appropriate for random access
    iterators, because these algorithms do a logarithmic number of
    steps through the data structure. For non-random access iterators
    they execute a linear number of steps.
</p></blockquote>

<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>

<blockquote><p>
   -1- Requires: Type T is LessThanComparable
    (lib.lessthancomparable). 
</p></blockquote>

<p>to:</p>

<blockquote><p>
   -1- Requires: The elements e of [first, last) are partitioned with
   respect to the expression e &lt; value or comp(e, value)
</p></blockquote>


<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>

<blockquote><p>
   -2- Effects: Finds the first position into which value can be
    inserted without violating the ordering. 
</p></blockquote>

<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>

<blockquote><p>
  -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
</p></blockquote>

<p>to:</p>

<blockquote><p>
   -1- Requires: The elements e of [first, last) are partitioned with
   respect to the expression !(value &lt; e) or !comp(value, e)
</p></blockquote>

<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>

<blockquote><p>
   -2- Effects: Finds the furthermost position into which value can be
    inserted without violating the ordering.
</p></blockquote>

<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>

<blockquote><p>
   -1- Requires: Type T is LessThanComparable
    (lib.lessthancomparable).
</p></blockquote>

<p>to:</p>

<blockquote><p>
   -1- Requires: The elements e of [first, last) are partitioned with
   respect to the expressions e &lt; value and !(value &lt; e) or
   comp(e, value) and !comp(value, e).  Also, for all elements e of
   [first, last), e &lt; value implies !(value &lt; e) or comp(e,
   value) implies !comp(value, e)
</p></blockquote>

<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>

<blockquote><p>
   -2- Effects: Finds the largest subrange [i, j) such that the value
    can be inserted at any iterator k in it without violating the
    ordering. k satisfies the corresponding conditions: !(*k &lt; value)
    &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
    false.
</p></blockquote>

<p>to:</p>

<pre>   -2- Returns: 
         make_pair(lower_bound(first, last, value),
                   upper_bound(first, last, value))
       or
         make_pair(lower_bound(first, last, value, comp),
                   upper_bound(first, last, value, comp))
</pre>

<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>

<blockquote><p>
   -1- Requires: Type T is LessThanComparable
    (lib.lessthancomparable).
</p></blockquote>

<p>to:</p>

<blockquote><p>
   -1- Requires: The elements e of [first, last) are partitioned with
   respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
   value) and !comp(value, e). Also, for all elements e of [first,
   last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
   !comp(value, e)
</p></blockquote>

<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>


<p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
changed the "other than those described in" wording.) Also, the LWG
decided to accept the "optional" part.]</i></p>




<p><b>Rationale:</b></p>
<p>The proposed resolution reinterprets binary search. Instead of
thinking about searching for a value in a sorted range, we view that
as an important special case of a more general algorithm: searching
for the partition point in a partitioned range.</p>

<p>We also add a guarantee that the old wording did not: we ensure
that the upper bound is no earlier than the lower bound, that
the pair returned by equal_range is a valid range, and that the first
part of that pair is the lower bound.</p>





<hr>
<h3><a name="271"></a>271. basic_iostream missing typedefs</h3>
<p><b>Section:</b> 27.7.1.5 [iostreamclass] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Class template basic_iostream has no typedefs.  The typedefs it
inherits from its base classes can't be used, since (for example)
basic_iostream&lt;T&gt;::traits_type is ambiguous.
</p>


<p><b>Proposed resolution:</b></p>

<p>Add the following to basic_iostream's class synopsis in 
27.7.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>

<pre>  // types:
  typedef charT                     char_type;
  typedef typename traits::int_type int_type;
  typedef typename traits::pos_type pos_type;
  typedef typename traits::off_type off_type;
  typedef traits                    traits_type;
</pre>




<hr>
<h3><a name="272"></a>272. Missing parentheses around subexpression</h3>
<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p>
<p><b>Discussion:</b></p>
<p>
27.4.4.3, p4 says about the postcondition of the function: If
rdbuf()!=0 then state == rdstate(); otherwise
rdstate()==state|ios_base::badbit.
</p>

<p>
The expression on the right-hand-side of the operator==() needs to be
parenthesized in order for the whole expression to ever evaluate to
anything but non-zero.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add parentheses like so: rdstate()==(state|ios_base::badbit).
</p>




<hr>
<h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</h3>
<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
That's incorrect since the names are members of a dependent base
class (14.6.2 [temp.dep]) and thus not visible.</p>


<p><b>Proposed resolution:</b></p>
<p>Qualify the names with the name of the class of which they are
members, i.e., ios_base.</p>




<hr>
<h3><a name="274"></a>274. a missing/impossible allocator requirement</h3>
<p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
be overloaded on reference and const_reference, which is ill-formed for
all T = const U. In other words, this won't work:
</p>

<p>
template class std::allocator&lt;const int&gt;;
</p>

<p>
The obvious solution is to disallow specializations of allocators on
const types. However, while containers' elements are required to be
assignable (which rules out specializations on const T's), I think that
allocators might perhaps be potentially useful for const values in other
contexts. So if allocators are to allow const types a partial
specialization of std::allocator&lt;const T&gt; would probably have to be
provided.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>

    <blockquote><p>
    any type
    </p></blockquote>

<p>to</p>
    <blockquote><p>
    any non-const, non-reference type
    </p></blockquote>

<p><i>[Redmond: previous proposed resolution was "any non-const,
non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>




<p><b>Rationale:</b></p>
<p>
Two resolutions were originally proposed: one that partially
specialized std::allocator for const types, and one that said an
allocator's value type may not be const.  The LWG chose the second.
The first wouldn't be appropriate, because allocators are intended for
use by containers, and const value types don't work in containers.
Encouraging the use of allocators with const value types would only
lead to unsafe code.
</p>
<p>
The original text for proposed resolution 2 was modified so that it
also forbids volatile types and reference types.
</p>

<p><i>[Cura�ao: LWG double checked and believes volatile is correctly
excluded from the PR.]</i></p>







<hr>
<h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3>
<p><b>Section:</b> 22.4.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
There are eight overloads, all of which are identical except for the
last parameter.  The overloads are: 
</p>
<ul>
<li> long&amp; </li>
<li> unsigned short&amp; </li>
<li> unsigned int&amp; </li>
<li> unsigned long&amp; </li>
<li> short&amp; </li>
<li> double&amp; </li>
<li> long double&amp; </li>
<li> void*&amp; </li>
</ul>

<p>
There is a similar list, in 22.2.2.1.2, of overloads for
num_get&lt;&gt;::do_get().  In this list, the last parameter has
the types: 
</p>
<ul>
<li> long&amp; </li>
<li> unsigned short&amp; </li>
<li> unsigned int&amp; </li>
<li> unsigned long&amp; </li>
<li> float&amp; </li>
<li> double&amp; </li>
<li> long double&amp; </li>
<li> void*&amp; </li>
</ul>

<p>
These two lists are not identical.  They should be, since
<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
the arguments it was given.
</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.2.1.1 [facet.num.get.members], change</p>
<pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
                ios_base::iostate&amp; err, short&amp; val) const;
</pre>
<p>to</p>
<pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
                ios_base::iostate&amp; err, float&amp; val) const;
</pre>




<hr>
<h3><a name="276"></a>276. Assignable requirement for container value type overly strict</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-11-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.1/3 states that the objects stored in a container must be
Assignable.  23.6.1 [map], paragraph 2,
states that map satisfies all requirements for a container, while in
the same time defining value_type as pair&lt;const Key, T&gt; - a type
that is not Assignable.
</p>

<p>
It should be noted that there exists a valid and non-contradictory
interpretation of the current text. The wording in 23.1/3 avoids 
mentioning value_type, referring instead to "objects stored in a
container." One might argue that map does not store objects of
type map::value_type, but of map::mapped_type instead, and that the
Assignable requirement applies to map::mapped_type, not
map::value_type.
</p>

<p>
However, this makes map a special case (other containers store objects of
type value_type) and the Assignable requirement is needlessly restrictive in
general.
</p>

<p>
For example, the proposed resolution of active library issue 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
means that no set operations can exploit the fact that the stored
objects are Assignable.
</p>

<p>
This is related to, but slightly broader than, closed issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>23.1/3: Strike the trailing part of the sentence:</p>
    <blockquote><p>
    , and the additional requirements of Assignable types from 23.1/3
    </p></blockquote>
<p>so that it reads:</p>
    <blockquote><p>
    -3- The type of objects stored in these components must meet the 
    requirements of CopyConstructible types (lib.copyconstructible).
    </p></blockquote>

<p>23.1/4: Modify to make clear that this requirement is not for all 
containers.  Change to:</p>

<blockquote><p>
-4- Table 64 defines the Assignable requirement.  Some containers 
require this property of the types to be stored in the container.  T is 
the type used to instantiate the container. t is a value of T, and u is 
a value of (possibly const) T.
</p></blockquote>

<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
CopyConstructible".</p>

<p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>

<blockquote><p>
-2- A deque satisfies all of the requirements of a container and of a 
reversible container (given in tables in lib.container.requirements) and 
of a sequence, including the optional sequence requirements 
(lib.sequence.reqmts).  In addition to the requirements on the stored 
object described in 23.1[lib.container.requirements], the stored object 
must also meet the requirements of Assignable.  Descriptions are 
provided here only for operations on deque that are not described in one 
of these tables or for operations where there is additional semantic 
information.
</p></blockquote>

<p>23.2.2/2:  Add Assignable requirement to specific methods of list.  
Change to:</p>

<blockquote>
<p>-2- A list satisfies all of the requirements of a container and of a 
reversible container (given in two tables in lib.container.requirements) 
and of a sequence, including most of the the optional sequence 
requirements (lib.sequence.reqmts). The exceptions are the operator[] 
and at member functions, which are not provided. 

[Footnote: These member functions are only provided by containers whose 
iterators are random access iterators. --- end foonote]
</p>

<p>list does not require the stored type T to be Assignable unless the 
following methods are instantiated:

[Footnote: Implementors are permitted but not required to take advantage 
of T's Assignable properties for these methods. -- end foonote]
</p>
<pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
     template &lt;class InputIterator&gt;
       void assign(InputIterator first, InputIterator last);
     void assign(size_type n, const T&amp; t);
</pre>


<p>Descriptions are provided here only for operations on list that are not 
described in one of these tables or for operations where there is 
additional semantic information.</p>
</blockquote>

<p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>

<blockquote><p>
-2- A vector satisfies all of the requirements of a container and of a 
reversible container (given in two tables in lib.container.requirements) 
and of a sequence, including most of the optional sequence requirements 
(lib.sequence.reqmts). The exceptions are the push_front and pop_front 
member functions, which are not provided.  In addition to the 
requirements on the stored object described in 
23.1[lib.container.requirements], the stored object must also meet the 
requirements of Assignable.  Descriptions are provided here only for 
operations on vector that are not described in one of these tables or 
for operations where there is additional semantic information.
</p></blockquote>


<p><b>Rationale:</b></p>
<p>list, set, multiset, map, multimap are able to store non-Assignables.
However, there is some concern about <tt>list&lt;T&gt;</tt>:
although in general there's no reason for T to be Assignable, some
implementations of the member functions <tt>operator=</tt> and
<tt>assign</tt> do rely on that requirement.  The LWG does not want
to forbid such implementations.</p>

<p>Note that the type stored in a standard container must still satisfy
the requirements of the container's allocator; this rules out, for
example, such types as "const int".  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
for more details.
</p>

<p>In principle we could also relax the "Assignable" requirement for
individual <tt>vector</tt> member functions, such as
<tt>push_back</tt>.  However, the LWG did not see great value in such
selective relaxation.  Doing so would remove implementors' freedom to
implement <tt>vector::push_back</tt> in terms of
<tt>vector::insert</tt>.</p>





<hr>
<h3><a name="278"></a>278. What does iterator validity mean?</h3>
<p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 23.3.4.4 [list.ops] states that
</p>
<pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
</pre>
<p>
<i>invalidates</i> all iterators and references to list <tt>x</tt>.
</p>

<p>
But what does the C++ Standard mean by "invalidate"?  You
can still dereference the iterator to a spliced list element, but
you'd better not use it to delimit a range within the original
list. For the latter operation, it has definitely lost some of its
validity.
</p>

<p>
If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
then we'd better clarify that a "valid" iterator need no
longer designate an element within the same container as it once did.
We then have to clarify what we mean by invalidating a past-the-end
iterator, as when a vector or string grows by reallocation. Clearly,
such an iterator has a different kind of validity. Perhaps we should
introduce separate terms for the two kinds of "validity."
</p>


<p><b>Proposed resolution:</b></p>
<p>Add the following text to the end of section X [iterator.concepts],
after paragraph 5:</p>
<blockquote><p>
An <i>invalid</i> iterator is an iterator that may be
singular. [Footnote: This definition applies to pointers, since
pointers are iterators. The effect of dereferencing an iterator that
has been invalidated is undefined.]
</p></blockquote>

<p><i>[post-Copenhagen: Matt provided wording.]</i></p>


<p><i>[Redmond: General agreement with the intent, some objections to
the wording.  Dave provided new wording.]</i></p>



<p><b>Rationale:</b></p>
<p>This resolution simply defines a term that the Standard uses but
  never defines, "invalid", in terms of a term that is defined,
  "singular".</p>

<p>Why do we say "may be singular", instead of "is singular"?  That's
  becuase a valid iterator is one that is known to be nonsingular.
  Invalidating an iterator means changing it in such a way that it's
  no longer known to be nonsingular.  An example: inserting an
  element into the middle of a vector is correctly said to invalidate
  all iterators pointing into the vector.  That doesn't necessarily
  mean they all become singular.</p>





<hr>
<h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3>
<p><b>Section:</b> 24.5.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This came from an email from Steve Cleary to Fergus in reference to
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
this in Toronto and believed it should be a separate issue.  There was
also some reservations about whether this was a worthwhile problem to
fix.
</p>

<p>
Steve said: "Fixing reverse_iterator. std::reverse_iterator can
(and should) be changed to preserve these additional
requirements." He also said in email that it can be done without
breaking user's code: "If you take a look at my suggested
solution, reverse_iterator doesn't have to take two parameters; there
is no danger of breaking existing code, except someone taking the
address of one of the reverse_iterator global operator functions, and
I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
case they have, you can leave the old global functions in as well --
they won't interfere with the two-template-argument functions.  With
that, I don't see how <i>any</i> user code could break."
</p>


<p><b>Proposed resolution:</b></p>
<p>
<b>Section:</b> 24.5.1.1 [reverse.iterator]
add/change the following declarations:</p>
<pre>  A) Add a templated assignment operator, after the same manner
        as the templated copy constructor, i.e.:

  template &lt; class U &gt;
  reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);

  B) Make all global functions (except the operator+) have
  two template parameters instead of one, that is, for
  operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:

       template &lt; class Iterator &gt;
       typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
                 const reverse_iterator&lt; Iterator &gt;&amp; x,
                 const reverse_iterator&lt; Iterator &gt;&amp; y);

  with:

      template &lt; class Iterator1, class Iterator2 &gt;
      typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
                 const reverse_iterator &lt; Iterator1 &gt; &amp; x,
                 const reverse_iterator &lt; Iterator2 &gt; &amp; y);
</pre>
<p>
Also make the addition/changes for these signatures in 
24.5.1.3 [reverse.iter.ops].
</p>

<p><i>[
Copenhagen: The LWG is concerned that the proposed resolution 
introduces new overloads.  Experience shows that introducing
overloads is always risky, and that it would be inappropriate to
make this change without implementation experience.  It may be
desirable to provide this feature in a different way.
]</i></p>


<p><i>[
Lillehammer: We now have implementation experience, and agree that
this solution is safe and correct.
]</i></p>







<hr>
<h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
<p><b>Discussion:</b></p>
<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
requirements of <tt>LessThanComparable</tt> ( [lessthancomparable])
and <tt>CopyConstructible</tt> (20.2.1 [utility.arg.requirements]).
Since the functions take and return their arguments and result by
const reference, I believe the <tt>CopyConstructible</tt> requirement
is unnecessary.
</p>


<p><b>Proposed resolution:</b></p>
<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
25.3.7, p1 with</p>
<p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt> 
( [lessthancomparable]).
</p>
<p>and replace 25.3.7, p4 with</p>
<p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt> 
( [lessthancomparable]).
</p>




<hr>
<h3><a name="282"></a>282. What types does numpunct grouping refer to?</h3>
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2000-12-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Paragraph 16 mistakenly singles out integral types for inserting 
thousands_sep() characters.  This conflicts with the syntax for floating 
point numbers described under 22.2.3.1/2.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change paragraph 16 from:</p>

<blockquote><p>
For integral types, punct.thousands_sep() characters are inserted into 
the sequence as determined by the value returned by punct.do_grouping() 
using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
</p></blockquote>

<p>To:</p>

<blockquote><p>
For arithmetic types, punct.thousands_sep() characters are inserted into 
the sequence as determined by the value returned by punct.do_grouping() 
using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
</p></blockquote>

<p><i>[
Copenhagen: Opinions were divided about whether this is actually an
inconsistency, but at best it seems to have been unintentional.  This
is only an issue for floating-point output: The standard is
unambiguous that implementations must parse thousands_sep characters
when performing floating-point.  The standard is also unambiguous that
this requirement does not apply to the "C" locale.
]</i></p>


<p><i>[
A survey of existing practice is needed; it is believed that some
implementations do insert thousands_sep characters for floating-point
output and others fail to insert thousands_sep characters for 
floating-point input even though this is unambiguously required by the
standard.
]</i></p>


<p><i>[Post-Cura�ao: the above proposed resolution is the consensus of
Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>






<hr>
<h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3>
<p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p>
<p><b>Discussion:</b></p>
<p>
(revision of the further discussion)
There are a number of problems with the requires clauses for the
algorithms in 25.1 and 25.2. The requires clause of each algorithm
should describe the necessary and sufficient requirements on the inputs
to the algorithm such that the algorithm compiles and runs properly.
Many of the requires clauses fail to do this. Here is a summary of the kinds
of mistakes:
</p>

<ol>
<li>
Use of EqualityComparable, which only puts requirements on a single
type, when in fact an equality operator is required between two
different types, typically either T and the iterator's value type
or between the value types of two different iterators.
</li>
<li>
Use of Assignable for T when in fact what was needed is Assignable
for the value_type of the iterator, and convertability from T to the
value_type of the iterator. Or for output iterators, the requirement
should be that T is writable to the iterator (output iterators do
not have value types).
</li>
</ol>

<p>
Here is the list of algorithms that contain mistakes:
</p>

<ul>
<li>25.1.2 std::find</li>
<li>25.1.6 std::count</li>
<li>25.1.8 std::equal</li>
<li>25.1.9 std::search, std::search_n</li>
<li>25.2.4 std::replace, std::replace_copy</li>
<li>25.2.5 std::fill</li>
<li>25.2.7 std::remove, std::remove_copy</li>
</ul>

<p>
Also, in the requirements for EqualityComparable, the requirement that
the operator be defined for const objects is lacking.
</p>



<p><b>Proposed resolution:</b></p>

<p>20.1.1 Change p1 from</p>

<p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
values of type <tt>T</tt>.
</p>

<p>to</p>

<p>
In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
values of type <tt>const T</tt>.
</p>

<p>25 Between p8 and p9</p>

<p>Add the following sentence:</p>

<p>When the description of an algorithm gives an expression such as
<tt>*first == value</tt> for a condition, it is required that the expression
evaluate to either true or false in boolean contexts.</p>

<p>25.1.2 Change p1 by deleting the requires clause.</p>

<p>25.1.6 Change p1 by deleting the requires clause.</p>

<p>25.1.9</p>

<p>Change p4 from</p>

<p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
(20.1.1), type Size is convertible to integral type (4.7.12.3).
</p>

<p>to</p>

<p>-4- Requires: The type <tt>Size</tt> is convertible to integral
type (4.7.12.3).</p>

<p>25.2.4 Change p1 from</p>

<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p>

<p>to</p>

<p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>

<p>and change p4 from</p>

<p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
(20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
(last - first))</tt> shall not overlap.</p>

<p>to</p>

<p>-4- Requires: The results of the expressions <tt>*first</tt> and
<tt>new_value</tt> must be writable to the result output iterator. The
ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
first))</tt> shall not overlap.</p>


<p>25.2.5 Change p1 from</p>

<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>

<p>to</p>

<p>-1- Requires: The expression <tt>value</tt> must be is writable to
the output iterator. The type <tt>Size</tt> is convertible to an
integral type (4.7.12.3).</p>

<p>25.2.7 Change p1 from</p>

<p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>

<p>to</p>

<p>
-1- Requires: The value type of the iterator must be
<tt>Assignable</tt> (23.1).
</p>



<p><b>Rationale:</b></p>
<p>
The general idea of the proposed solution is to remove the faulty
requires clauses and let the returns and effects clauses speak for
themselves. That is, the returns clauses contain expressions that must
be valid, and therefore already imply the correct requirements. In
addition, a sentence is added at the beginning of chapter 25 saying
that expressions given as conditions must evaluate to true or false in
a boolean context. An alternative would be to say that the type of
these condition expressions must be literally bool, but that would be
imposing a greater restriction that what the standard currently says
(which is convertible to bool).
</p>





<hr>
<h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
<p><b>Section:</b> 20.8.6 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The example in 20.8.6 [comparisons], p6 shows how to use the C
library function <tt>strcmp()</tt> with the function pointer adapter
<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
functions have <tt>extern "C"</tt> or <tt>extern
"C++"</tt> linkage [17.6.2.3 [using.linkage]], and since
function pointers with different the language linkage specifications
(7.5 [dcl.link]) are incompatible, whether this example is
well-formed is unspecified.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 20.8.6 [comparisons] paragraph 6 from:</p>
<blockquote>
  <p>[<i>Example:</i></p>
  <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
  </pre>
  <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
</blockquote>


<p>to:</p>
<blockquote>
  <p>[<i>Example:</i></p>
  <pre>    int compare(const char*, const char*);
    replace_if(v.begin(), v.end(),
               not1(bind2nd(ptr_fun(compare), "abc")), "def");
  </pre>
  <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
</blockquote>

<p>Also, remove footnote 215 in that same paragraph.</p>

<p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
issue deals in part with C and C++ linkage, it was believed to be too
confusing for the strings in the example to be "C" and "C++".
]</i></p>


<p><i>[Redmond: More minor changes.  Got rid of the footnote (which
seems to make a sweeping normative requirement, even though footnotes
aren't normative), and changed the sentence after the footnote so that
it corresponds to the new code fragment.]</i></p>






<hr>
<h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3>
<p><b>Section:</b> 27.9.1.7 [ifstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-31 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.9.1.7 [ifstream.cons], p2, 27.9.1.11 [ofstream.cons], p2, and
27.9.1.15 [fstream.cons], p2 say about the effects of each constructor:
</p>

<p>... If that function returns a null pointer, calls
<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
</p>

<p>The parenthetical note doesn't apply since the ctors cannot throw an
exception due to the requirement in 27.5.4.1 [basic.ios.cons], p3 
that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Strike the parenthetical note from the Effects clause in each of the
paragraphs mentioned above.
</p>




<hr>
<h3><a name="286"></a>286. &lt;cstdlib&gt; requirements missing size_t typedef</h3>
<p><b>Section:</b> 25.5 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The &lt;cstdlib&gt; header file contains prototypes for bsearch and
qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
require the typedef size_t. Yet size_t is not listed in the
&lt;cstdlib&gt; synopsis table 78 in section 25.4.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the type size_t to Table 78 (section 25.4) and add
the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
</p>


<p><b>Rationale:</b></p>
<p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>





<hr>
<h3><a name="288"></a>288. &lt;cerrno&gt; requirements missing macro EILSEQ</h3>
<p><b>Section:</b> 19.4 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
of macros defined in &lt;errno.h&gt; is adjusted to include a new
macro, EILSEQ"
</p>

<p>
ISO/IEC 14882:1998(E) section 19.3 does not refer
to the above amendment.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
</p>





<hr>
<h3><a name="291"></a>291. Underspecification of set algorithms</h3>
<p><b>Section:</b> 25.4.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-01-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard library contains four algorithms that compute set
operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
<tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
of these algorithms takes two sorted ranges as inputs, and writes the
output of the appropriate set operation to an output range.  The elements
in the output range are sorted.
</p>

<p>
The ordinary mathematical definitions are generalized so that they
apply to ranges containing multiple copies of a given element.  Two
elements are considered to be "the same" if, according to an
ordering relation provided by the user, neither one is less than the
other.  So, for example, if one input range contains five copies of an
element and another contains three, the output range of <tt>set_union</tt>
will contain five copies, the output range of
<tt>set_intersection</tt> will contain three, the output range of
<tt>set_difference</tt> will contain two, and the output range of
<tt>set_symmetric_difference</tt> will contain two.
</p>

<p>
Because two elements can be "the same" for the purposes
of these set algorithms, without being identical in other respects
(consider, for example, strings under case-insensitive comparison),
this raises a number of unanswered questions:
</p>

<ul>
<li>If we're copying an element that's present in both of the
input ranges, which one do we copy it from?</li>
<li>If there are <i>n</i> copies of an element in the relevant
input range, and the output range will contain fewer copies (say
<i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
<i>m</i>, or something else?</li>
<li>Are these operations stable?  That is, does a run of equivalent
elements appear in the output range in the same order as as it
appeared in the input range(s)?</li>
</ul>

<p>
The standard should either answer these questions, or explicitly
say that the answers are unspecified.  I prefer the former option,
since, as far as I know, all existing implementations behave the
same way.
</p>



<p><b>Proposed resolution:</b></p>

<p>Add the following to the end of 25.4.5.2 [set.union] paragraph 5:</p>
<blockquote><p>
If [first1, last1) contains <i>m</i> elements that are equivalent to
each other and [first2, last2) contains <i>n</i> elements that are
equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
will be copied to the output range: all <i>m</i> of these elements
from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
[first2, last2), in that order.
</p></blockquote>

<p>Add the following to the end of 25.4.5.3 [set.intersection] paragraph 5:</p>
<blockquote><p>
If [first1, last1) contains <i>m</i> elements that are equivalent to each
other and [first2, last2) contains <i>n</i> elements that are
equivalent to them, the first min(<i>m</i>, <i>n</i>) of those 
elements from [first1, last1) are copied to the output range.
</p></blockquote>

<p>Add a new paragraph, <b>Notes</b>, after 25.4.5.4 [set.difference]
paragraph 4:</p>
<blockquote><p>
If [first1, last1) contains <i>m</i> elements that are equivalent to each
other and [first2, last2) contains <i>n</i> elements that are
equivalent to them, the last max(<i>m-n</i>, 0) elements from 
[first1, last1) are copied to the output range.
</p></blockquote>

<p>Add a new paragraph, <b>Notes</b>, after 25.4.5.5 [set.symmetric.difference]
paragraph 4:</p>
<blockquote><p>
If [first1, last1) contains <i>m</i> elements that are equivalent to
each other and [first2, last2) contains <i>n</i> elements that are
equivalent to them, then |<i>m - n</i>| of those elements will be
copied to the output range: the last <i>m - n</i> of these elements
from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
</p></blockquote>

<p><i>[Santa Cruz: it's believed that this language is clearer than
  what's in the Standard.  However, it's also believed that the
  Standard may already make these guarantees (although not quite in
  these words).  Bill and Howard will check and see whether they think
  that some or all of these changes may be redundant.  If so, we may
  close this issue as NAD.]</i></p>




<p><b>Rationale:</b></p>
<p>For simple cases, these descriptions are equivalent to what's
  already in the Standard.  For more complicated cases, they describe
  the behavior of existing implementations.</p>





<hr>
<h3><a name="292"></a>292. effects of a.copyfmt (a)</h3>
<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The Effects clause of the member function <tt>copyfmt()</tt> in
27.4.4.2, p15 doesn't consider the case where the left-hand side
argument is identical to the argument on the right-hand side, that is
<tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
is no need to copy any of the data members or call any callbacks
registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
points out in message c++std-lib-8149 it appears to be incorrect to
allow the object to fire <tt>erase_event</tt> followed by
<tt>copyfmt_event</tt> since the callback handling the latter event
may inadvertently attempt to access memory freed by the former.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change the Effects clause in 27.4.4.2, p15 from</p>

<blockquote><p>
<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
the corresponding member objects of <tt>rhs</tt>, except that...
</p></blockquote>

<p>to</p>

<blockquote><p>
<b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
assigns to the member objects of <tt>*this</tt> the corresponding member
objects of <tt>rhs</tt>, except that...
</p></blockquote>




<hr>
<h3><a name="294"></a>294. User defined macros and standard headers</h3>
<p><b>Section:</b> 17.6.3.3.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> James Kanze <b>Opened:</b> 2001-01-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#macro.names">issues</a> in [macro.names].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Paragraph 2 of 17.6.3.3.1 [macro.names] reads: "A
translation unit that includes a header shall not contain any macros
that define names declared in that header." As I read this, it
would mean that the following program is legal:</p>

<pre>  #define npos 3.14
  #include &lt;sstream&gt;
</pre>

<p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
in &lt;string&gt;, and it is hard to imagine an implementation in
which &lt;sstream&gt; didn't include &lt;string&gt;.</p>

<p>I think that this phrase was probably formulated before it was
decided that a standard header may freely include other standard
headers.  The phrase would be perfectly appropriate for C, for
example.  In light of 17.6.4.2 [res.on.headers] paragraph 1, however,
it isn't stringent enough.</p>


<p><b>Proposed resolution:</b></p>
<p>For 17.6.3.3.1 [macro.names], replace the current wording, which reads:</p>
<blockquote>
     <p>Each name defined as a macro in a header is reserved to the
     implementation for any use if the translation unit includes
     the header.168)</p>

     <p>A translation unit that includes a header shall not contain any
     macros that define names declared or defined in that header. Nor shall
     such a translation unit define macros for names lexically
     identical to keywords.</p>

     <p>168) It is not permissible to remove a library macro definition by
     using the #undef directive.</p>
</blockquote>

<p>with the wording:</p>

<blockquote>
     <p>A translation unit that includes a standard library header shall not
     #define or #undef names declared in any standard library header.</p>

     <p>A translation unit shall not #define or #undef names lexically
     identical to keywords.</p>
</blockquote>

<p><i>[Lillehammer: Beman provided new wording]</i></p>






<hr>
<h3><a name="295"></a>295. Is abs defined in &lt;cmath&gt;?</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2001-01-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added 
signatures present in &lt;cmath&gt;, does say that several overloads
of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
of functions "(abs(), div(), rand(), srand())" from 26.6 [numarray],
paragraph 1.
</p>

<p><i>[Copenhagen: Modified proposed resolution so that it also gets
rid of that vestigial list of functions in paragraph 1.]</i></p>




<p><b>Rationale:</b></p>
<p>All this DR does is fix a typo; it's uncontroversial.  A 
separate question is whether we're doing the right thing in 
putting some overloads in &lt;cmath&gt; that we aren't also 
putting in &lt;cstdlib&gt;.  That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>





<hr>
<h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>The synopsis of the header <tt>&lt;utility&gt;</tt> in 20.3 [utility]
lists the complete set of equality and relational operators for <tt>pair</tt>
but the section describing the template and the operators only describes
<tt>operator==()</tt> and <tt>operator&lt;()</tt>, and it fails to mention
any requirements on the template arguments. The remaining operators are
not mentioned at all.
</p>

<p><i>[
2009-09-27 Alisdair reopens.
]</i></p>


<blockquote>
<p>
The issue is a lack of wording specifying the semantics of <tt>std::pair</tt>
relational operators.  The rationale is that this is covered by
catch-all wording in the relops component, and that as relops directly
precedes <tt>pair</tt> in the document this is an easy connection to make.
</p>

<p>
Reading the current working paper I make two observations:
</p>

<ol type="i">
<li>
relops no longer immediately precedes <tt>pair</tt> in the order of
specification.  However, even if it did, there is a lot of <tt>pair</tt>
specification itself between the (apparently) unrelated relops and the
relational operators for <tt>pair</tt>.  (The catch-all still requires
<tt>operator==</tt> and <tt>operator&lt;</tt> to be specified
explicitly)
</li>

<li>
No other library component relies on the catch-all clause. The following
all explicitly document all six relational operators, usually in a
manner that could have deferred to the relops clause.
</li>
</ol>

<blockquote><pre>tuple
unique_ptr
duration
time_point
basic_string
queue
stack
move_iterator
reverse_iterator 
regex submatch
thread::id
</pre></blockquote>

<p>
The container components provide their own (equivalent) definition in
23.2.1 [container.requirements.general] Table 90 -- Container
requirements and do so do not defer to relops.
</p>

<p>
<tt>Shared_ptr</tt> explicitly documents <tt>operator!=</tt> and does
not supply the other 3 missing operators
(<tt>&gt;</tt>,<tt>&gt;=</tt>,<tt>&lt;=</tt>) so does not meet the
reqirements of the relops clause.
</p>

<p>
<tt>Weak_ptr</tt> only supports <tt>operator&lt;</tt> so would not be
covered by relops.
</p>

<p>
At the very least I would request a note pointing to the relops clause
we rely on to provide this definition.  If this route is taken, I would
recommend reducing many of the above listed clauses to a similar note
rather than providing redundant specification.
</p>

<p>
My preference would be to supply the 4 missing specifications consistent
with the rest of the library.
</p>

</blockquote>

<p><i>[
2009-10-11 Daniel opens <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1233">1233</a> which deals with the same issue as
it pertains to <tt>unique_ptr</tt>.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
After p20 20.3.5 [pairs] add:
</p>

<blockquote><pre>template &lt;class T1, class T2&gt;
bool operator!=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
</pre>

<blockquote>
<i>Returns:</i> <tt>!(x==y)</tt>
</blockquote>

<pre>template &lt;class T1, class T2&gt;
bool operator&gt; (const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
</pre>

<blockquote>
<i>Returns:</i> <tt>y &lt; x</tt>
</blockquote>

<pre>template &lt;class T1, class T2&gt;
bool operator&gt;=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
</pre>

<blockquote>
<i>Returns:</i> <tt>!(x &lt; y)</tt>
</blockquote>

<pre>template &lt;class T1, class T2&gt;
bool operator&lt;=(const pair&lt;T1,T2&gt;&amp; x, const pair&lt;T1,T2&gt;&amp; y);
</pre>

<blockquote>
<i>Returns:</i> <tt>!(y &lt; x)</tt>
</blockquote>
</blockquote>


<p><b>Rationale:</b></p>
<p>20.3.1 [operators] paragraph 10 already specifies the semantics.
That paragraph says that, if declarations of operator!=, operator&gt;,
operator&lt;=, and operator&gt;= appear without definitions, they are
defined as specified in 20.3.1 [operators].  There should be no user
confusion, since that paragraph happens to immediately precede the
specification of <tt>pair</tt>.</p>





<hr>
<h3><a name="297"></a>297. const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3>
<p><b>Section:</b> 20.8.7 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
<tt>const_mem_fun1_t</tt>
in 20.5.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
<tt>binary_function&lt;T*,
A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
<tt>first_argument_type</tt>
members, respectively, are both defined to be <tt>T*</tt> (non-const).
However, their function call member operator takes a <tt>const T*</tt>
argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
T*</tt> instead, so that one can easily refer to it in generic code. The
example below derived from existing code fails to compile due to the
discrepancy:
</p>

<p><tt>template &lt;class T&gt;</tt>
<br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
<br><tt>{</tt>
<br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
T::argument_type)
const =&nbsp;&nbsp; // #2</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
<br><tt>}</tt>
</p>

<p><tt>struct X { /* ... */ };</tt></p>

<p><tt>int main ()</tt>
<br><tt>{</tt>
<br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
<br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
&gt;(&amp;x);&nbsp;&nbsp;
// #3</tt>
<br><tt>}</tt>
</p>

<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
<br>#2 the type of the pointer is incompatible with the type of the member
function
<br>#3 the address of a constant being passed to a function taking a non-const
<tt>X*</tt>
</p>


<p><b>Proposed resolution:</b></p>
<p>Replace the top portion of the definition of the class template
const_mem_fun_t in 20.5.8, p8
</p>
<p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
unary_function&lt;T*, S&gt; {</tt>
</p>
<p>with</p>
<p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
unary_function&lt;<b>const</b> T*, S&gt; {</tt>
</p>
<p>Also replace the top portion of the definition of the class template
const_mem_fun1_t in 20.5.8, p9</p>
<p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
binary_function&lt;T*, A, S&gt; {</tt>
</p>
<p>with</p>
<p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
</p>


<p><b>Rationale:</b></p>
<p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
and the argument type itself, are not the same.</p>





<hr>
<h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3>
<p><b>Section:</b> 18.6.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> John A. Pedretti <b>Opened:</b> 2001-01-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
namely that for non-null value of <i>ptr</i>, the operator reclaims storage
allocated by the earlier call to the default <tt>operator new[]</tt> - is not
correct in all cases. Since the specified <tt>operator new[]</tt> default
behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
replaced, along with <tt>operator delete</tt>, by the user, to implement their
own memory management, the specified default behavior of<tt> operator
delete[]</tt> must be to call <tt>operator delete</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 18.5.1.2, p12 from</p>
<blockquote><p>
<b>-12-</b> <b>Default behavior:</b></p>
<ul>
<li>
For a null value of <i><tt>ptr</tt></i> , does nothing.
</li>
<li>
Any other value of <i><tt>ptr</tt></i> shall be a value returned
earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
[Footnote: The value must not have been invalidated by an intervening
call to <tt>operator delete[](void*)</tt> (17.6.3.9 [res.on.arguments]).
--- end footnote]
For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
allocated by the earlier call to the default <tt>operator new[]</tt>.
</li>
</ul>
</blockquote>

<p>to</p>

<blockquote><p>
<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
delete(</tt><i>ptr</i>)
or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
</p></blockquote>
<p>and expunge paragraph 13.</p>




<hr>
<h3><a name="300"></a>300. list::merge() specification incomplete</h3>
<p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> John Pedretti <b>Opened:</b> 2001-01-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The "Effects" clause for list::merge() (23.3.4.4 [list.ops], p23)
appears to be incomplete: it doesn't cover the case where the argument
list is identical to *this (i.e., this == &amp;x). The requirement in the
note in p24 (below) is that x be empty after the merge which is surely
unintended in this case.
</p>


<p><b>Proposed resolution:</b></p>
<p>In 23.3.4.4 [list.ops], replace paragraps 23-25 with:</p>
<blockquote>
<p>
23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
is a range in which the elements will be sorted in non-decreasing
order according to the ordering defined by comp; that is, for every
iterator i in the range other than the first, the condition comp(*i,
*(i - 1)) will be false.
</p>

<p>
24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
two original ranges, the elements from the original range [begin(),
end()) always precede the elements from the original range [x.begin(),
x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
after the merge.
</p>

<p>
25 Complexity: At most size() + x.size() - 1 applications of comp if
(&amp;x !  = this); otherwise, no applications of comp are performed.  If
an exception is thrown other than by a comparison there are no
effects.
</p>

</blockquote>

<p><i>[Copenhagen: The original proposed resolution did not fix all of
the problems in 23.3.4.4 [list.ops], p22-25.  Three different
paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
Changing p23, without changing the other two, appears to introduce
contradictions.  Additionally, "merges the argument list into the
list" is excessively vague.]</i></p>


<p><i>[Post-Cura�ao: Robert Klarer provided new wording.]</i></p>







<hr>
<h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</h3>
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The effects clause for the basic_string template ctor in 21.3.1, p15
leaves out the third argument of type Allocator. I believe this to be
a mistake.
</p>


<p><b>Proposed resolution:</b></p>
<p>Replace</p>

<blockquote>
    <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
    type, equivalent to</p>

    <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
    static_cast&lt;value_type&gt;(end))</tt></p></blockquote>
</blockquote>

<p>with</p>

<blockquote>
    <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
    type, equivalent to</p>

    <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
    static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></p></blockquote>
</blockquote>




<hr>
<h3><a name="303"></a>303. Bitset input operator underspecified</h3>
<p><b>Section:</b> 20.5.4 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-02-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
"Extracts up to <i>N</i> (single-byte) characters from
<i>is</i>.", where <i>is</i> is a stream of type
<tt>basic_istream&lt;charT, traits&gt;</tt>.
</p>

<p>
The standard does not say what it means to extract single byte
characters from a stream whose character type, <tt>charT</tt>, is in
general not a single-byte character type.  Existing implementations
differ.
</p>

<p>
A reasonable solution will probably involve <tt>widen()</tt> and/or
<tt>narrow()</tt>, since they are the supplied mechanism for
converting a single character between <tt>char</tt> and 
arbitrary <tt>charT</tt>.
</p>

<p>Narrowing the input characters is not the same as widening the
literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
locales in which more than one wide character maps to the narrow
character <tt>'0'</tt>.  Narrowing means that alternate
representations may be used for bitset input, widening means that
they may not be.</p>

<p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
(22.2.2.1.2/8) compares input characters to widened version of narrow
character literals.</p>

<p>From Pete Becker, in c++std-lib-8224:</p>
<blockquote>
<p>
Different writing systems can have different representations for the
digits that represent 0 and 1. For example, in the Unicode representation
of the Devanagari script (used in many of the Indic languages) the digit 0
is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
0x0031 for for the Latin representations of '0' and '1', as well as code
points for the same numeric values in several other scripts (Tamil has no
character for 0, but does have the digits 1-9), and any of these values
would also be narrowed to '0' and '1'.
</p>

<p>...</p>

<p>
It's fairly common to intermix both native and Latin
representations of numbers in a document. So I think the rule has to be
that if a wide character represents a digit whose value is 0 then the bit
should be cleared; if it represents a digit whose value is 1 then the bit
should be set; otherwise throw an exception. So in a Devanagari locale,
both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
would set it. Widen can't do that. It would pick one of those two values,
and exclude the other one.
</p>

</blockquote>

<p>From Jens Maurer, in c++std-lib-8233:</p>

<blockquote>
<p>
Whatever we decide, I would find it most surprising if
bitset conversion worked differently from int conversion
with regard to alternate local representations of
numbers.
</p>

<p>Thus, I think the options are:</p>
<ul>
 <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
require the use of narrow().</li>

 <li> Have a defect issue for bitset() which describes clearly
that widen() is to be used.</li>
</ul>
</blockquote>



<p><b>Proposed resolution:</b></p>

    <p>Replace the first two sentences of paragraph 5 with:</p>

    <blockquote><p>
    Extracts up to <i>N</i> characters from <i>is</i>. Stores these
    characters in a temporary object <i>str</i> of type
    <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
    expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
    </p></blockquote>

    <p>Replace the third bullet item in paragraph 5 with:</p>
    <ul><li>
    the next input character is neither <tt><i>is</i>.widen(0)</tt>
    nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
    is not extracted).
    </li></ul>



<p><b>Rationale:</b></p>
<p>Input for <tt>bitset</tt> should work the same way as numeric
input.  Using <tt>widen</tt> does mean that alternative digit
representations will not be recognized, but this was a known 
consequence of the design choice.</p>





<hr>
<h3><a name="305"></a>305. Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3>
<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-01-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>22.2.1.5/3 introduces codecvt in part with:</p>

<blockquote><p>
  codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
  character sets for tiny and wide characters. Instantiations on
  mbstate_t perform conversion between encodings known to the library
  implementor.
</p></blockquote>

<p>But 22.2.1.5.2/10 describes do_length in part with:</p>

<blockquote><p>
  ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and 
  (from_end-from).
</p></blockquote>

<p>
The semantics of do_in and do_length are linked.  What one does must
be consistent with what the other does.  22.2.1.5/3 leads me to
believe that the vendor is allowed to choose the algorithm that
codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
return.  And thus indirectly specifies the algorithm that
codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
that this is not what was intended and is a defect.
</p>

<p>Discussion from the -lib reflector:

<br>This proposal would have the effect of making the semantics of
all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
do we want to mandate specific behavior for the base class virtuals
and leave the implementation specified behavior for the codecvt_byname
derived class?  The tradeoff is that former allows implementors to
write a base class that actually does something useful, while the
latter gives users a way to get known and specified---albeit
useless---behavior, and is consistent with the way the standard
handles other facets.  It is not clear what the original intention
was.</p>

<p>
Nathan has suggest a compromise: a character that is a widened version
of the characters in the basic execution character set must be
converted to a one-byte sequence, but there is no such requirement
for characters that are not part of the basic execution character set.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 22.2.1.5.2/5 from:
</p>
<p>
The instantiations required in Table 51 (lib.locale.category), namely
codecvt&lt;wchar_t,char,mbstate_t&gt; and
codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
than (to_limit-to) destination elements. It always leaves the to_next
pointer pointing one beyond the last element successfully stored.
</p>
<p>
to:
</p>
<p>
Stores no more than (to_limit-to) destination elements, and leaves the
to_next pointer pointing one beyond the last element successfully
stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
</p>

<p>Change 22.2.1.5.2/10 from:</p>

<blockquote><p>
-10- Returns: (from_next-from) where from_next is the largest value in
the range [from,from_end] such that the sequence of values in the
range [from,from_next) represents max or fewer valid complete
characters of type internT. The instantiations required in Table 51
(21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
(from_end-from).
</p></blockquote>

<p>to:</p>

<blockquote><p>
-10- Returns: (from_next-from) where from_next is the largest value in 
the range [from,from_end] such that the sequence of values in the range 
[from,from_next) represents max or fewer valid complete characters of 
type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns 
the lesser of max and (from_end-from). 
</p></blockquote>

<p><i>[Redmond: Nathan suggested an alternative resolution: same as
above, but require that, in the default encoding, a character from the
basic execution character set would map to a single external
character.  The straw poll was 8-1 in favor of the proposed
resolution.]</i></p>




<p><b>Rationale:</b></p>
<p>The default encoding should be whatever users of a given platform
would expect to be the most natural.  This varies from platform to
platform.  In many cases there is a preexisting C library, and users
would expect the default encoding to be whatever C uses in the default
"C" locale.  We could impose a guarantee like the one Nathan suggested
(a character from the basic execution character set must map to a
single external character), but this would rule out important
encodings that are in common use: it would rule out JIS, for
example, and it would rule out a fixed-width encoding of UCS-4.</p>

<p><i>[Cura�ao: fixed rationale typo at the request of Ichiro Koshida;
"shift-JIS" changed to "JIS".]</i></p>







<hr>
<h3><a name="306"></a>306. offsetof macro and non-POD types</h3>
<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-02-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p> 
<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>

<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
accepts a restricted set of <i>type</i> arguments in this
International Standard. <i>type</i> shall be a POD structure or a POD
union (clause 9). The result of applying the offsetof macro to a field
that is a static data member or a function member is
undefined."</p>

<p>For the POD requirement, it doesn't say "no diagnostic
required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required.
It's not clear whether this requirement was intended.  While it's
possible to provide such a diagnostic, the extra complication doesn't
seem to add any value.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
structure or a POD union the results are undefined."</p>

<p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
agreed that requiring a diagnostic was inadvertent, but some LWG
members thought that diagnostics should be required whenever
possible.]</i></p>






<hr>
<h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
<p><b>Section:</b> 23.3.4 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-03-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>From reflector message c++std-lib-8330.  See also lib-8317.</p>

<p>
The standard is currently inconsistent in 23.3.4.2 [list.capacity]
paragraph 1 and 23.3.4.3 [list.modifiers] paragraph 1.
23.2.3.3/1, for example, says:
</p>

<blockquote><p>
-1- Any sequence supporting operations back(), push_back() and pop_back() 
can be used to instantiate stack. In particular, vector (lib.vector), list 
(lib.list) and deque (lib.deque) can be used. 
</p></blockquote>

<p>But this is false: vector&lt;bool&gt; can not be used, because the
container adaptors return a T&amp; rather than using the underlying
container's reference type.</p>

<p>This is a contradiction that can be fixed by:</p>

<ol>
<li>Modifying these paragraphs to say that vector&lt;bool&gt;
    is an exception.</li>
<li>Removing the vector&lt;bool&gt; specialization.</li>
<li>Changing the return types of stack and priority_queue to use 
    reference typedef's.</li>
</ol>

<p>
I propose 3.  This does not preclude option 2 if we choose to do it
later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>); the issues are independent.  Option
3 offers a small step towards support for proxied containers.  This
small step fixes a current contradiction, is easy for vendors to
implement, is already implemented in at least one popular lib, and
does not break any code.
</p>



<p><b>Proposed resolution:</b></p>
<p>Summary: Add reference and const_reference typedefs to queue,
priority_queue and stack.  Change return types of "value_type&amp;" to
"reference".  Change return types of "const value_type&amp;" to
"const_reference".  Details:</p>

<p>Change 23.2.3.1/1 from:</p>

<pre>  namespace std {
    template &lt;class T, class Container = deque&lt;T&gt; &gt;
    class queue {
    public:
      typedef typename Container::value_type            value_type;
      typedef typename Container::size_type             size_type;
      typedef          Container                        container_type;
    protected:
      Container c;

    public:
      explicit queue(const Container&amp; = Container());

      bool      empty() const             { return c.empty(); }
      size_type size()  const             { return c.size(); }
      value_type&amp;       front()           { return c.front(); }
      const value_type&amp; front() const     { return c.front(); }
      value_type&amp;       back()            { return c.back(); }
      const value_type&amp; back() const      { return c.back(); }
      void push(const value_type&amp; x)      { c.push_back(x); }
      void pop()                          { c.pop_front(); }
    };
</pre>

<p>to:</p>

<pre>  namespace std {
    template &lt;class T, class Container = deque&lt;T&gt; &gt;
    class queue {
    public:
      typedef typename Container::value_type            value_type;
      typedef typename Container::reference             reference;
      typedef typename Container::const_reference       const_reference;
      typedef typename Container::value_type            value_type;
      typedef typename Container::size_type             size_type;
      typedef          Container                        container_type;
    protected:
      Container c;

    public:
      explicit queue(const Container&amp; = Container());

      bool      empty() const             { return c.empty(); }
      size_type size()  const             { return c.size(); }
      reference         front()           { return c.front(); }
      const_reference   front() const     { return c.front(); }
      reference         back()            { return c.back(); }
      const_reference   back() const      { return c.back(); }
      void push(const value_type&amp; x)      { c.push_back(x); }
      void pop()                          { c.pop_front(); }
    };
</pre>

<p>Change 23.2.3.2/1 from:</p>

<pre>  namespace std {
    template &lt;class T, class Container = vector&lt;T&gt;,
              class Compare = less&lt;typename Container::value_type&gt; &gt;
    class priority_queue {
    public:
      typedef typename Container::value_type            value_type;
      typedef typename Container::size_type             size_type;
      typedef          Container                        container_type;
    protected:
      Container c;
      Compare comp;

    public:
      explicit priority_queue(const Compare&amp; x = Compare(),
                              const Container&amp; = Container());
      template &lt;class InputIterator&gt;
        priority_queue(InputIterator first, InputIterator last,
                       const Compare&amp; x = Compare(),
                       const Container&amp; = Container());

      bool      empty() const       { return c.empty(); }
      size_type size()  const       { return c.size(); }
      const value_type&amp; top() const { return c.front(); }
      void push(const value_type&amp; x);
      void pop();
    };
                                  //  no equality is provided
  }
</pre>

<p>to:</p>

<pre>  namespace std {
    template &lt;class T, class Container = vector&lt;T&gt;,
              class Compare = less&lt;typename Container::value_type&gt; &gt;
    class priority_queue {
    public:
      typedef typename Container::value_type            value_type;
      typedef typename Container::reference             reference;
      typedef typename Container::const_reference       const_reference;
      typedef typename Container::size_type             size_type;
      typedef          Container                        container_type;
    protected:
      Container c;
      Compare comp;

    public:
      explicit priority_queue(const Compare&amp; x = Compare(),
                              const Container&amp; = Container());
      template &lt;class InputIterator&gt;
        priority_queue(InputIterator first, InputIterator last,
                       const Compare&amp; x = Compare(),
                       const Container&amp; = Container());

      bool      empty() const       { return c.empty(); }
      size_type size()  const       { return c.size(); }
      const_reference   top() const { return c.front(); }
      void push(const value_type&amp; x);
      void pop();
    };
                                  //  no equality is provided
  }
</pre>

<p>And change 23.2.3.3/1 from:</p>

<pre>  namespace std {
    template &lt;class T, class Container = deque&lt;T&gt; &gt;
    class stack {
    public:
      typedef typename Container::value_type            value_type;
      typedef typename Container::size_type             size_type;
      typedef          Container                        container_type;
    protected:
      Container c;

    public:
      explicit stack(const Container&amp; = Container());

      bool      empty() const             { return c.empty(); }
      size_type size()  const             { return c.size(); }
      value_type&amp;       top()             { return c.back(); }
      const value_type&amp; top() const       { return c.back(); }
      void push(const value_type&amp; x)      { c.push_back(x); }
      void pop()                          { c.pop_back(); }
    };

    template &lt;class T, class Container&gt;
      bool operator==(const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator!=(const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
  }
</pre>

<p>to:</p>

<pre>  namespace std {
    template &lt;class T, class Container = deque&lt;T&gt; &gt;
    class stack {
    public:
      typedef typename Container::value_type            value_type;
      typedef typename Container::reference             reference;
      typedef typename Container::const_reference       const_reference;
      typedef typename Container::size_type             size_type;
      typedef          Container                        container_type;
    protected:
      Container c;

    public:
      explicit stack(const Container&amp; = Container());

      bool      empty() const             { return c.empty(); }
      size_type size()  const             { return c.size(); }
      reference         top()             { return c.back(); }
      const_reference   top() const       { return c.back(); }
      void push(const value_type&amp; x)      { c.push_back(x); }
      void pop()                          { c.pop_back(); }
    };

    template &lt;class T, class Container&gt;
      bool operator==(const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator!=(const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
    template &lt;class T, class Container&gt;
      bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
                      const stack&lt;T, Container&gt;&amp; y);
  }
</pre>

<p><i>[Copenhagen: This change was discussed before the IS was released
and it was deliberately not adopted.  Nevertheless, the LWG believes
(straw poll: 10-2) that it is a genuine defect.]</i></p>






<hr>
<h3><a name="308"></a>308. Table 82 mentions unrelated headers</h3>
<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
streams (27.8 [string.streams]) and the headers &lt;cstdio&gt; and
&lt;cwchar&gt; for File streams (27.9 [file.streams]). It's not clear
why these headers are mentioned in this context since they do not
define any of the library entities described by the
subclauses. According to 17.6.1.1 [contents], only such headers
are to be listed in the summary.
</p>


<p><b>Proposed resolution:</b></p>
<p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
Table 82.</p>

<p><i>[Copenhagen: changed the proposed resolution slightly.  The
original proposed resolution also said to remove &lt;cstdio&gt; from
Table 82.  However, &lt;cstdio&gt; is mentioned several times within
section 27.9 [file.streams], including 27.9.2 [c.files].]</i></p>






<hr>
<h3><a name="310"></a>310. Is errno a macro?</h3>
<p><b>Section:</b> 17.6.1.2 [headers], 19.4 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-03-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
  <p>
  Exactly how should errno be declared in a conforming C++ header?
  </p>

  <p>
  The C standard says in 7.1.4 that it is unspecified whether errno is a
  macro or an identifier with external linkage.  In some implementations
  it can be either, depending on compile-time options.  (E.g., on
  Solaris in multi-threading mode, errno is a macro that expands to a
  function call, but is an extern int otherwise.  "Unspecified" allows
  such variability.)
  </p>

  <p>The C++ standard:</p>
  <ul>
  <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
  <li>17.4.3.1.3 footnote 166 says errno is reserved as an external 
      name (true), and implies that it is an identifier.</li>
  <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
      on to say that the contents of of C++ &lt;errno.h&gt; are the
      same as in C, begging the question.</li>
  <li>C.2, table 95 lists errno as a macro, without comment.</li>
  </ul>

  <p>I find no other references to errno.</p>

  <p>We should either explicitly say that errno must be a macro, even
  though it need not be a macro in C, or else explicitly leave it
  unspecified.  We also need to say something about namespace std. 
  A user who includes &lt;cerrno&gt; needs to know whether to write
  <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
  else &lt;cerrno&gt; is useless.</p>

  <p>Two acceptable fixes:</p>
  <ul>
    <li><p>errno must be a macro. This is trivially satisfied by adding<br>
        &nbsp;&nbsp;#define errno (::std::errno)<br>
        to the headers if errno is not already a macro. You then always
        write errno without any scope qualification, and it always expands
        to a correct reference. Since it is always a macro, you know to
        avoid using errno as a local identifer.</p></li>
    <li><p>errno is in the global namespace. This fix is inferior, because
        ::errno is not guaranteed to be well-formed.</p></li>
  </ul>

  <p><i>[
    This issue was first raised in 1999, but it slipped through 
    the cracks.
  ]</i></p>



<p><b>Proposed resolution:</b></p>
  <p>Change the Note in section 17.4.1.2p5 from</p>

    <blockquote><p>
    Note: the names defined as macros in C include the following:
    assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
    </p></blockquote>

  <p>to</p>

    <blockquote><p>
    Note: the names defined as macros in C include the following:
    assert, offsetof, setjmp, va_arg, va_end, and va_start.
    </p></blockquote>

  <p>In section 19.3, change paragraph 2 from</p>

    <blockquote><p>
    The contents are the same as the Standard C library header
    &lt;errno.h&gt;.
    </p></blockquote>

  <p>to</p>

    <blockquote><p>
    The contents are the same as the Standard C library header 
    &lt;errno.h&gt;, except that errno shall be defined as a macro.
    </p></blockquote>


<p><b>Rationale:</b></p>
<p>C++ must not leave it up to the implementation to decide whether or
not a name is a macro; it must explicitly specify exactly which names
are required to be macros.  The only one that really works is for it
to be a macro.</p>

<p><i>[Cura�ao: additional rationale added.]</i></p>







<hr>
<h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3>
<p><b>Section:</b> 27.7.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-03-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>In 27.7.2.1 [ostream], the synopsis of class basic_ostream says:</p>

<pre>  // partial specializationss
  template&lt;class traits&gt;
    basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
                                            const char * );
</pre>

<p>Problems:</p>
<ul>
<li>Too many 's's at the end of "specializationss" </li>
<li>This is an overload, not a partial specialization</li>
</ul>



<p><b>Proposed resolution:</b></p>
<p>In the synopsis in 27.7.2.1 [ostream], remove the 
<i>// partial specializationss</i> comment.  Also remove the same 
comment (correctly spelled, but still incorrect) from the synopsis in 
27.7.2.6.4 [ostream.inserters.character].
</p>

<p><i>[
Pre-Redmond: added 27.7.2.6.4 [ostream.inserters.character] because of Martin's
comment in c++std-lib-8939.
]</i></p>







<hr>
<h3><a name="312"></a>312. Table 27 is missing headers</h3>
<p><b>Section:</b> 20 [utilities] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
Memory (lib.memory) but neglects to mention the headers
&lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.7.6 [meta.rel].</p>


<p><b>Proposed resolution:</b></p>
<p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
as &lt;memory&gt;.</p>





<hr>
<h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
<p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-05-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.3.4.4 [list.ops], Para 21 describes the complexity of
list::unique as: "If the range (last - first) is not empty, exactly
(last - first) -1 applications of the corresponding predicate,
otherwise no applications of the predicate)".
</p>

<p>
"(last - first)" is not a range.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the "range" from (last - first) to [first, last).
</p>




<hr>
<h3><a name="316"></a>316. Vague text in Table 69</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Table 69 says this about a_uniq.insert(t):</p>

<blockquote><p>
inserts t if and only if there is no element in the container with key
equivalent to the key of t. The bool component of the returned pair 
indicates whether the insertion takes place and the iterator component of the
pair points to the element with key equivalent to the key of t.
</p></blockquote>

<p>The description should be more specific about exactly how the bool component
indicates whether the insertion takes place.</p>


<p><b>Proposed resolution:</b></p>
<p>Change the text in question to</p>

<blockquote><p>
...The bool component of the returned pair is true if and only if the insertion
takes place...
</p></blockquote>





<hr>
<h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3>
<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The localization section of the standard refers to specializations of
the facet templates as instantiations even though the required facets
are typically specialized rather than explicitly (or implicitly)
instantiated. In the case of ctype&lt;char&gt; and
ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
actually required to be specialized. The terminology should be
corrected to make it clear that the standard doesn't mandate explicit
instantiation (the term specialization encompasses both explicit
instantiations and specializations).
</p>


<p><b>Proposed resolution:</b></p>
<p>
In the following paragraphs, replace all occurrences of the word
instantiation or instantiations with specialization or specializations,
respectively:
</p>

<blockquote><p>
22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, 
22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
Footnote 242.
</p></blockquote>

<p>And change the text in 22.1.1.1.1, p4 from</p>

<blockquote><p>
    An implementation is required to provide those instantiations
    for facet templates identified as members of a category, and
    for those shown in Table 52:
</p></blockquote>

<p>to</p>

<blockquote><p>
    An implementation is required to provide those specializations...
</p></blockquote>

<p><i>[Nathan will review these changes, and will look for places where
explicit specialization is necessary.]</i></p>




<p><b>Rationale:</b></p>
<p>This is a simple matter of outdated language.  The language to
describe templates was clarified during the standardization process,
but the wording in clause 22 was never updated to reflect that
change.</p>







<hr>
<h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3>
<p><b>Section:</b> 22.4.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The definition of the numpunct_byname template contains the following
comment:</p>

<pre>    namespace std {
        template &lt;class charT&gt;
        class numpunct_byname : public numpunct&lt;charT&gt; {
    // this class is specialized for char and wchar_t.
        ...
</pre>

<p>There is no documentation of the specializations and it seems
conceivable that an implementation will not explicitly specialize the
template at all, but simply provide the primary template.</p>


<p><b>Proposed resolution:</b></p>
<p>Remove the comment from the text in 22.2.3.2 and from the proposed
resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>




<hr>
<h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3>
<p><b>Section:</b> 18.6.1.1 [new.delete.single], 18.6.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2001-05-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The standard specifies 17.5.1.4 [structure.specifications] that "Required
behavior" elements describe "the semantics of a function definition
provided by either the implementation or a C++ program."</p>

<p>The standard specifies 17.5.1.4 [structure.specifications] that "Requires"
elements describe "the preconditions for calling the function."</p>

<p>In the sections noted below, the current wording specifies
"Required Behavior" for what are actually preconditions, and thus
should be specified as "Requires".</p>



<p><b>Proposed resolution:</b></p>

<p>In 18.6.1.1 [new.delete.single] Para 12 Change:</p>
<blockquote>
  <p>Required behavior: accept a value of ptr that is null or that was
  returned by an earlier call ...</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>Requires: the value of ptr is null or the value returned by an
  earlier call ...</p>
</blockquote>

<p>In 18.6.1.2 [new.delete.array] Para 11 Change:</p>
<blockquote>
  <p>Required behavior: accept a value of ptr that is null or that was
  returned by an earlier call ...</p>
</blockquote>
<p>to:</p>
<blockquote>
  <p>Requires: the value of ptr is null or the value returned by an
  earlier call ...</p>
</blockquote>





<hr>
<h3><a name="320"></a>320. list::assign overspecified</h3>
<p><b>Section:</b> 23.3.4.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 23.3.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
the "effects" of a call to erase followed by a call to insert.
</p>

<p>
I would like to document that implementers have the freedom to implement 
assign by other methods, as long as the end result is the same and the 
exception guarantee is as good or better than the basic guarantee.
</p>

<p>
The motivation for this is to use T's assignment operator to recycle
existing nodes in the list instead of erasing them and reallocating
them with new values.  It is also worth noting that, with careful
coding, most common cases of assign (everything but assignment with
true input iterators) can elevate the exception safety to strong if
T's assignment has a nothrow guarantee (with no extra memory cost).
Metrowerks does this.  However I do not propose that this subtlety be
standardized.  It is a QoI issue.  </p>

<p>Existing practise:
Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 23.3.4.1 [list.cons]/7 from:</p>

<blockquote>
<p>Effects:</p>

<pre>   erase(begin(), end());
   insert(begin(), first, last);
</pre>
</blockquote>

<p>to:</p>

<blockquote>
<p>Effects: Replaces the contents of the list with the range [first, last).</p>
</blockquote>

<p>In 23.2.3 [sequence.reqmts], in Table 67 (sequence requirements), 
add two new rows:</p>
<pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
                                  Replaces elements in a with a copy
                                  of [i, j).

      a.assign(n,t)     void      pre: t is not a reference into a.
                                  Replaces elements in a with n copies
                                  of t.
</pre>

<p>Change 23.3.4.1 [list.cons]/8 from:</p>

<blockquote>
<p>Effects:</p>
<pre>   erase(begin(), end());
   insert(begin(), n, t);
</pre>
</blockquote>
<p>to:</p>

<blockquote>
<p>Effects: Replaces the contents of the list with n copies of t.</p>
</blockquote>

<p><i>[Redmond: Proposed resolution was changed slightly.  Previous
version made explicit statement about exception safety, which wasn't
consistent with the way exception safety is expressed elsewhere.
Also, the change in the sequence requirements is new.  Without that
change, the proposed resolution would have required that assignment of
a subrange would have to work.  That too would have been
overspecification; it would effectively mandate that assignment use a
temporary.  Howard provided wording.
]</i></p>


<p><i>[Cura�ao: Made editorial improvement in wording; changed
"Replaces elements in a with copies of elements in [i, j)."
with "Replaces the elements of a with a copy of [i, j)."
Changes not deemed serious enough to requre rereview.]</i></p>







<hr>
<h3><a name="321"></a>321. Typo in num_get</h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Kevin Djang <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 22.2.2.1.2 at p7 states that "A length specifier is added to
the conversion function, if needed, as indicated in Table 56."
However, Table 56 uses the term "length modifier", not "length
specifier".
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
to be "A length modifier is added ..."
</p>


<p><b>Rationale:</b></p>
<p>C uses the term "length modifier".  We should be consistent.</p>






<hr>
<h3><a name="322"></a>322. iterator and const_iterator should have the same value type</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It's widely assumed that, if X is a container,
iterator_traits&lt;X::iterator&gt;::value_type and
iterator_traits&lt;X::const_iterator&gt;::value_type should both be
X::value_type.  However, this is nowhere stated.  The language in
Table 65 is not precise about the iterators' value types (it predates
iterator_traits), and could even be interpreted as saying that
iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
X::value_type".
</p>

<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>


<p><b>Proposed resolution:</b></p>
<p>In Table 65 ("Container Requirements"), change the return type for
X::iterator to "iterator type whose value type is T".  Change the
return type for X::const_iterator to "constant iterator type whose
value type is T".</p>


<p><b>Rationale:</b></p>
<p>
This belongs as a container requirement, rather than an iterator
requirement, because the whole notion of iterator/const_iterator
pairs is specific to containers' iterator.
</p>
<p>
It is existing practice that (for example) 
iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
is "int", rather than "const int".  This is consistent with
the way that const pointers are handled: the standard already 
requires that iterator_traits&lt;const int*&gt;::value_type is int.
</p>





<hr>
<h3><a name="324"></a>324. Do output iterators have value types?</h3>
<p><b>Section:</b> 24.2.4 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>Table 73 suggests that output iterators have value types.  It 
requires the expression "*a = t".  Additionally, although Table 73
never lists "a = t" or "X(a) = t" in the "expressions" column, it
contains a note saying that "a = t" and "X(a) = t" have equivalent
(but nowhere specified!) semantics.</p>

<p>According to 24.1/9, t is supposed to be "a value of value type
T":</p>

    <blockquote><p>
    In the following sections, a and b denote values of X, n denotes a
    value of the difference type Distance, u, tmp, and m denote
    identifiers, r denotes a value of X&amp;, t denotes a value of
    value type T.
    </p></blockquote>

<p>Two other parts of the standard that are relevant to whether
output iterators have value types:</p>

<ul>
    <li>24.1/1 says "All iterators i support the expression *i,
    resulting in a value of some class, enumeration, or built-in type
    T, called the value type of the iterator".</li>

    <li>
    24.3.1/1, which says "In the case of an output iterator, the types
    iterator_traits&lt;Iterator&gt;::difference_type
    iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
    </li>
</ul>

<p>The first of these passages suggests that "*i" is supposed to
return a useful value, which contradicts the note in 24.1.2/2 saying
that the only valid use of "*i" for output iterators is in an
expression of the form "*i = t".  The second of these passages appears
to contradict Table 73, because it suggests that "*i"'s return value
should be void.  The second passage is also broken in the case of a an
iterator type, like non-const pointers, that satisfies both the output
iterator requirements and the forward iterator requirements.</p>

<p>What should the standard say about <tt>*i</tt>'s return value when
i is an output iterator, and what should it say about that t is in the
expression "*i = t"?  Finally, should the standard say anything about
output iterators' pointer and reference types?</p>



<p><b>Proposed resolution:</b></p>
<p>24.1 p1, change</p>

<blockquote>
<p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
in a value of some class, enumeration, or built-in type <tt>T</tt>,
called the value type of the iterator.</p>
</blockquote>

<p>to</p>

<blockquote>
<p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
resulting in a value of some class, enumeration, or built-in type
<tt>T</tt>, called the value type of the iterator. All output
iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
value of some type that is in the set of types that are <i>writable</i> to
the particular iterator type of <tt>i</tt>.
</p>
</blockquote>

<p>24.1 p9, add</p>

<blockquote>
<p><tt>o</tt> denotes a value of some type that is writable to the
output iterator.
</p>
</blockquote>

<p>Table 73, change</p>

<blockquote>
<pre>*a = t
</pre>
</blockquote>

<p>to</p>

<blockquote>
<pre>*r = o
</pre>
</blockquote>

<p>and change</p>

<blockquote>
<pre>*r++ = t
</pre>
</blockquote>

<p>to</p>

<blockquote>
<pre>*r++ = o
</pre>
</blockquote>

<p><i>[post-Redmond: Jeremy provided wording]</i></p>




<p><b>Rationale:</b></p>
<p>The LWG considered two options: change all of the language that
seems to imply that output iterators have value types, thus making it
clear that output iterators have no value types, or else define value
types for output iterator consistently.  The LWG chose the former
option, because it seems clear that output iterators were never
intended to have value types.  This was a deliberate design decision,
and any language suggesting otherwise is simply a mistake.</p>

<p>A future revision of the standard may wish to revisit this design
decision.</p>





<hr>
<h3><a name="325"></a>325. Misleading text in moneypunct&lt;&gt;::do_grouping</h3>
<p><b>Section:</b> 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The Returns clause in 22.2.6.3.2, p3 says about
moneypunct&lt;charT&gt;::do_grouping()
</p>

<blockquote><p>
    Returns: A pattern defined identically as the result of
    numpunct&lt;charT&gt;::do_grouping().241)
</p></blockquote>

<p>Footnote 241 then reads</p>

<blockquote><p>
    This is most commonly the value "\003" (not "3").
</p></blockquote>

<p>
The returns clause seems to imply that the two member functions must
return an identical value which in reality may or may not be true,
since the facets are usually implemented in terms of struct std::lconv
and return the value of the grouping and mon_grouping, respectively.
The footnote also implies that the member function of the moneypunct
facet (rather than the overridden virtual functions in moneypunct_byname)
most commonly return "\003", which contradicts the C standard which
specifies the value of "" for the (most common) C locale.
</p>



<p><b>Proposed resolution:</b></p>
<p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>

<blockquote><p>
    Returns: A pattern defined identically as, but not necessarily
    equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
</p></blockquote>

<p>and replace the text in Footnote 241 with the following:</p>

<blockquote><p>
    To specify grouping by 3s the value is "\003", not "3".
</p></blockquote>


<p><b>Rationale:</b></p>
<p>
The fundamental problem is that the description of the locale facet
virtuals serves two purposes: describing the behavior of the base
class, and describing the meaning of and constraints on the behavior
in arbitrary derived classes.  The new wording makes that separation a
little bit clearer.  The footnote (which is nonnormative) is not
supposed to say what the grouping is in the "C" locale or in any other
locale. It is just a reminder that the values are interpreted as small
integers, not ASCII characters.
</p>




<hr>
<h3><a name="327"></a>327. Typo in time_get facet in table 52</h3>
<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Tiki Wan <b>Opened:</b> 2001-07-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p>
<p><b>Discussion:</b></p>
<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
<tt>time_get_byname</tt> are listed incorrectly in table 52,
required instantiations.  In both cases the second template
parameter is given as OutputIterator.  It should instead be
InputIterator, since these are input facets.</p>


<p><b>Proposed resolution:</b></p>
<p>
In table 52, required instantiations, in 
22.3.1.1.1 [locale.category], change</p>
<pre>    time_get&lt;wchar_t, OutputIterator&gt;
    time_get_byname&lt;wchar_t, OutputIterator&gt;
</pre>
<p>to</p>
<pre>    time_get&lt;wchar_t, InputIterator&gt;
    time_get_byname&lt;wchar_t, InputIterator&gt;
</pre>

<p><i>[Redmond: Very minor change in proposed resolution.  Original had
a typo, wchart instead of wchar_t.]</i></p>






<hr>
<h3><a name="328"></a>328. Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3>
<p><b>Section:</b> 22.4.6.2.2 [locale.money.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>The sprintf format string , "%.01f" (that's the digit one), in the
description of the do_put() member functions of the money_put facet in
22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
for values of type long double, and second, the precision of 01
doesn't seem to make sense. What was most likely intended was
"%.0Lf"., that is a precision of zero followed by the L length
modifier.</p>


<p><b>Proposed resolution:</b></p>
<p>Change the format string to "%.0Lf".</p>


<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>




<hr>
<h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
<p><b>Section:</b> 23.4.1.2 [vector.capacity], 23.4.1.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-07-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is an apparent contradiction about which circumstances can cause
a reallocation of a vector in Section 23.4.1.2 [vector.capacity] and
section 23.4.1.4 [vector.modifiers].
</p>

<p>23.4.1.2 [vector.capacity],p5 says:</p>
<blockquote><p>
Notes: Reallocation invalidates all the references, pointers, and iterators
referring to the elements in the sequence. It is guaranteed that no
reallocation takes place during insertions that happen after a call to
reserve() until the time when an insertion would make the size of the vector
greater than the size specified in the most recent call to reserve().
</p></blockquote>

<p>Which implies if I do</p>

<pre>  std::vector&lt;int&gt; vec;
  vec.reserve(23);
  vec.reserve(0);
  vec.insert(vec.end(),1);
</pre>

<p>then the implementation may reallocate the vector for the insert,
as the size specified in the previous call to reserve was zero.</p>

<p>However, the previous paragraphs (23.4.1.2 [vector.capacity], p1-2) state:</p>
<blockquote>
<p>
(capacity) Returns: The total number of elements the vector
can hold without requiring reallocation
</p>
<p>
...After reserve(), capacity() is greater or equal to the
argument of reserve if reallocation happens; and equal to the previous value
of capacity() otherwise...
</p>
</blockquote>

<p>
This implies that vec.capacity() is still 23, and so the insert()
should not require a reallocation, as vec.size() is 0. This is backed
up by 23.4.1.4 [vector.modifiers], p1:
</p>
<blockquote><p>
(insert) Notes: Causes reallocation if the new size is greater than the old
capacity.
</p></blockquote>

<p>
Though this doesn't rule out reallocation if the new size is less
than the old capacity, I think the intent is clear.
</p>



<p><b>Proposed resolution:</b></p>
<p>Change the wording of 23.4.1.2 [vector.capacity] paragraph 5 to:</p>

<blockquote><p>
Notes: Reallocation invalidates all the references, pointers, and
iterators referring to the elements in the sequence. It is guaranteed
that no reallocation takes place during insertions that happen after a
call to reserve() until the time when an insertion would make the size
of the vector greater than the value of capacity().
</p></blockquote>

<p><i>[Redmond: original proposed resolution was modified slightly.  In
the original, the guarantee was that there would be no reallocation
until the size would be greater than the value of capacity() after the
most recent call to reserve().  The LWG did not believe that the
"after the most recent call to reserve()" added any useful
information.]</i></p>




<p><b>Rationale:</b></p>
<p>There was general agreement that, when reserve() is called twice in
succession and the argument to the second invocation is smaller than
the argument to the first, the intent was for the second invocation to
have no effect.  Wording implying that such cases have an effect on
reallocation guarantees was inadvertant.</p>





<hr>
<h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3>
<p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
With the change in 17.6.4.12 [res.on.exception.handling] to state
   "An implementation may strengthen the exception-specification for a 
    non-virtual function by removing listed exceptions."
(issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
and the following declaration of ~failure() in ios_base::failure
</p>
<pre>    namespace std {
       class ios_base::failure : public exception {
       public:
           ...
           virtual ~failure();
           ...
       };
     }
</pre>
<p>the class failure cannot be implemented since in 18.7.1 [type.info] the destructor of class exception has an empty
exception specification:</p>
<pre>    namespace std {
       class exception {
       public:
         ...
         virtual ~exception() throw();
         ...
       };
     }
</pre>


<p><b>Proposed resolution:</b></p>
<p>Remove the declaration of ~failure().</p>


<p><b>Rationale:</b></p>
<p>The proposed resolution is consistent with the way that destructors
of other classes derived from <tt>exception</tt> are handled.</p>







<hr>
<h3><a name="333"></a>333. does endl imply synchronization with the device?</h3>
<p><b>Section:</b> 27.7.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>A footnote in 27.7.2.8 [ostream.manip] states:</p>
<blockquote><p>
    [Footnote: The effect of executing cout &lt;&lt; endl is to insert a 
     newline character in the output sequence controlled by cout, then 
     synchronize it with any external file with which it might be 
     associated. --- end foonote]
</p></blockquote>

<p>
Does the term "file" here refer to the external device?
This leads to some implementation ambiguity on systems with fully 
buffered files where a newline does not cause a flush to the device.
</p>

<p>
Choosing to sync with the device leads to significant performance
penalties for each call to endl, while not sync-ing leads to
errors under special circumstances.
</p>

<p>
I could not find any other statement that explicitly defined
the behavior one way or the other.
</p>


<p><b>Proposed resolution:</b></p>
<p>Remove footnote 300 from section 27.7.2.8 [ostream.manip].</p>


<p><b>Rationale:</b></p>
<p>We already have normative text saying what <tt>endl</tt> does: it
inserts a newline character and calls <tt>flush</tt>.  This footnote
is at best redundant, at worst (as this issue says) misleading,
because it appears to make promises about what <tt>flush</tt>
does.</p>







<hr>
<h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3>
<p><b>Section:</b> 23.6.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andrea Griffini <b>Opened:</b> 2001-09-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current standard describes map::operator[] using a
code example. That code example is however quite
inefficient because it requires several useless copies
of both the passed key_type value and of default
constructed mapped_type instances.
My opinion is that was not meant by the comitee to
require all those temporary copies. 
</p>

<p>Currently map::operator[] behaviour is specified as: </p>
<pre>  Returns:
    (*((insert(make_pair(x, T()))).first)).second.
</pre>
  
<p>
This specification however uses make_pair that is a
template function of which parameters in this case
will be deduced being of type const key_type&amp; and
const T&amp;. This will create a pair&lt;key_type,T&gt; that
isn't the correct type expected by map::insert so
another copy will be required using the template
conversion constructor available in pair to build
the required pair&lt;const key_type,T&gt; instance.
</p>

<p>If we consider calling of key_type copy constructor
and mapped_type default constructor and copy
constructor as observable behaviour (as I think we
should) then the standard is in this place requiring
two copies of a key_type element plus a default
construction and two copy construction of a mapped_type
(supposing the addressed element is already present
in the map; otherwise at least another copy
construction for each type). 
</p>

<p>A simple (half) solution would be replacing the description with:</p>
<pre>  Returns:
    (*((insert(value_type(x, T()))).first)).second.
</pre>

<p>This will remove the wrong typed pair construction that
requires one extra copy of both key and value.</p>

<p>However still the using of map::insert requires temporary
objects while the operation, from a logical point of view,
doesn't require any. </p>

<p>I think that a better solution would be leaving free an
implementer to use a different approach than map::insert
that, because of its interface, forces default constructed
temporaries and copies in this case.
The best solution in my opinion would be just requiring
map::operator[] to return a reference to the mapped_type
part of the contained element creating a default element
with the specified key if no such an element is already
present in the container. Also a logarithmic complexity
requirement should be specified for the operation.
</p>

<p>
This would allow library implementers to write alternative
implementations not using map::insert and reaching optimal
performance in both cases of the addressed element being
present or absent from the map (no temporaries at all and
just the creation of a new pair inside the container if
the element isn't present).
Some implementer has already taken this option but I think
that the current wording of the standard rules that as
non-conforming. 
</p>



<p><b>Proposed resolution:</b></p>

<p>
Replace 23.6.1.2 [map.access] paragraph 1 with
</p>
<blockquote>
<p>
-1- Effects:  If there is no key equivalent to x in the map, inserts 
value_type(x, T()) into the map.
</p>
<p>
-2- Returns: A reference to the mapped_type corresponding to x in *this.
</p>
<p>
-3- Complexity: logarithmic.
</p>
</blockquote>

<p><i>[This is the second option mentioned above.  Howard provided
wording.  We may also wish to have a blanket statement somewhere in
clause 17 saying that we do not intend the semantics of sample code
fragments to be interpreted as specifing exactly how many copies are
made.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a> for a similar problem.]</i></p>




<p><b>Rationale:</b></p>
<p>
This is the second solution described above; as noted, it is
consistent with existing practice.
</p>

<p>Note that we now need to specify the complexity explicitly, because
we are no longer defining <tt>operator[]</tt> in terms of
<tt>insert</tt>.</p>





<hr>
<h3><a name="335"></a>335. minor issue with char_traits, table 37</h3>
<p><b>Section:</b> 21.2.1 [char.traits.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-09-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
as:
</p>
<pre>  X::assign(c,d)   assigns c = d.
</pre>

<p>And para 1 says:</p>

<blockquote><p>
 [...] c and d denote values of type CharT [...]
</p></blockquote>

<p>
Naturally, if c and d are <i>values</i>, then the assignment is
(effectively) meaningless. It's clearly intended that (in the case of
assign, at least), 'c' is intended to be a reference type.
</p>

<p>I did a quick survey of the four implementations I happened to have
lying around, and sure enough they all have signatures:</p>
<pre>    assign( charT&amp;, const charT&amp; );
</pre>

<p>(or the equivalent). It's also described this way in Nico's book.
(Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
</p>


<p><b>Proposed resolution:</b></p>
<p>Add the following to 21.1.1 para 1:</p>
<blockquote><p>
 r denotes an lvalue of CharT
</p></blockquote>

<p>and change the description of assign in the table to:</p>
<pre>  X::assign(r,d)   assigns r = d
</pre>





<hr>
<h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>From c++std-edit-873:</p>

<p>17.6.1.2 [headers], Table 11.  In this table, the header
&lt;strstream&gt; is missing.</p>

<p>This shows a general problem: The whole clause 17 refers quite
often to clauses 18 through 27, but D.7 is also a part of the standard
library (though a deprecated one).</p>



<p><b>Proposed resolution:</b></p>

<p>To 17.6.1.2 [headers] Table 11, C++ Library Headers, add
"&lt;strstream&gt;".</p>

<p>In the following places, change "clauses 17 through 27" to "clauses
17 through 27 and Annex D":</p>

<ul>
<li>1.2 [intro.refs] Normative references/1/footnote 1</li>
<li>1.3 [intro.defs] Definitions/1</li>
<li>7 [dcl.dcl] Library introduction/9</li>
<li>17.5 [description] Method of description (Informative)/1</li>
<li>17.5.2.1.4 [character.seq] Character sequences/1/bullet 2</li>
<li>17.5.2.2 [functions.within.classes] Functions within classes/1</li>
<li>17.5.2.3 [objects.within.classes] Private members/1/(2 places)</li>
<li>17.6 [requirements] Library-wide requirements/1</li>
<li>17.6.1.2 [headers] Headers/4</li>
<li>17.6.3.6 [replacement.functions] Replacement functions/1</li>
<li>17.6.4.4 [global.functions] Global or non-member functions/2</li>
<li>17.6.4.10 [protection.within.classes] Protection within classes/1</li>
</ul>







<hr>
<h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3>
<p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>From c++std-edit-876:</p>

<p>
In section 25.3.5 [alg.replace] before p4: The name of the first
parameter of template replace_copy_if should be "InputIterator"
instead of "Iterator".  According to 17.5.2.1 [type.descriptions] p1 the
parameter name conveys real normative meaning.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>





<hr>
<h3><a name="338"></a>338.  is whitespace allowed between `-' and a digit?</h3>
<p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
From Stage 2 processing in 22.4.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
original text or the text corrected by the proposed resolution of
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
within a number, but 22.4.3.1 [locale.numpunct], p2, which gives the
format for integer and floating point values, says that whitespace is
optional between a plusminus and a sign.
</p>

<p>
The text needs to be clarified to either consistently allow or
disallow whitespace between a plusminus and a sign. It might be
worthwhile to consider the fact that the C library stdio facility does
not permit whitespace embedded in numbers and neither does the C or
C++ core language (the syntax of integer-literals is given in 2.14.2 [lex.icon], that of floating-point-literals in 2.14.4 [lex.fcon] of the C++ standard).
</p>


<p><b>Proposed resolution:</b></p>
<p>Change the first part of 22.4.3.1 [locale.numpunct] paragraph 2 from:</p>
<blockquote>
<p>
The syntax for number formats is as follows, where <tt>digit</tt>
represents the radix set specified by the <tt>fmtflags</tt> argument
value, <tt>whitespace</tt> is as determined by the facet
<tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
<tt>decimal-point</tt> are the results of corresponding
<tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
format:
</p>
<pre>  integer   ::= [sign] units
  sign      ::= plusminus [whitespace]
  plusminus ::= '+' | '-'
  units     ::= digits [thousands-sep units]
  digits    ::= digit [digits]
</pre>
</blockquote>
<p>to:</p>
<blockquote>
<p>
The syntax for number formats is as follows, where <tt>digit</tt>
represents the radix set specified by the <tt>fmtflags</tt> argument
value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
Integer values have the format:
</p>
<pre>  integer   ::= [sign] units
  sign      ::= plusminus
  plusminus ::= '+' | '-'
  units     ::= digits [thousands-sep units]
  digits    ::= digit [digits]
</pre>
</blockquote>


<p><b>Rationale:</b></p>
<p>It's not clear whether the format described in 22.4.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
standard says how, or whether, it's used.  However, there's no reason
for it to differ gratuitously from the very specific description of
numeric processing in 22.4.2.1.2 [facet.num.get.virtuals].  The proposed
resolution removes all mention of "whitespace" from that format.</p>





<hr>
<h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3>
<p><b>Section:</b> 22.4.1 [category.ctype], 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The ctype_category::mask type is declared to be an enum in 22.4.1 [category.ctype] with p1 then stating that it is a bitmask type, most
likely referring to the definition of bitmask type in 17.5.2.1.3 [bitmask.types], p1. However, the said definition only applies to
clause 27, making the reference in 22.2.1 somewhat dubious.
</p>


<p><b>Proposed resolution:</b></p>
<p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
    <blockquote><p>
    Several types defined in clause 27 are bitmask types. Each bitmask type
    can be implemented as an enumerated type that overloads certain operators,
    as an integer type, or as a bitset (20.5 [template.bitset]).
    </p></blockquote>
<p>to read</p>
    <blockquote><p>
    Several types defined in clauses lib.language.support through 
    lib.input.output and Annex D are bitmask types. Each bitmask type can
    be implemented as an enumerated type that overloads certain operators,
    as an integer  type, or as a bitset (lib.template.bitset).
    </p></blockquote>

<p>
Additionally, change the definition in 22.2.1 to adopt the same
convention as in clause 27 by replacing the existing text with the
following (note, in particluar, the cross-reference to 17.3.2.1.2 in
22.2.1, p1):
</p>

<blockquote>
<p>22.2.1 The ctype category [lib.category.ctype]</p>
<pre>namespace std {
    class ctype_base {
    public:
        typedef <b><i>T</i></b> mask;

        // numeric values are for exposition only.
        static const mask space = 1 &lt;&lt; 0;
        static const mask print = 1 &lt;&lt; 1;
        static const mask cntrl = 1 &lt;&lt; 2;
        static const mask upper = 1 &lt;&lt; 3;
        static const mask lower = 1 &lt;&lt; 4;
        static const mask alpha = 1 &lt;&lt; 5;
        static const mask digit = 1 &lt;&lt; 6;
        static const mask punct = 1 &lt;&lt; 7;
        static const mask xdigit = 1 &lt;&lt; 8;
        static const mask alnum = alpha | digit;
        static const mask graph = alnum | punct;
    };
}
</pre>

<p>The type <tt>mask</tt> is a bitmask type (17.5.2.1.3 [bitmask.types]).</p>
</blockquote>

<p><i>[Cura�ao: The LWG notes that T above should be bold-italics to be
consistent with the rest of the standard.]</i></p>









<hr>
<h3><a name="340"></a>340. interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt></h3>
<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It's unclear whether 22.1.1.1.1, p3 says that
<tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
from Table 51 or whether it includes Table 52 as well:
</p>

<blockquote><p>
For any locale <tt>loc</tt> either constructed, or returned by
locale::classic(), and any facet <tt>Facet</tt> that is a member of a
standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
locale member function which takes a <tt>locale::category</tt>
argument operates on the corresponding set of facets.
</p></blockquote>

<p>
It seems that it comes down to which facets are considered to be members of a
standard category. Intuitively, I would classify all the facets in Table 52 as
members of their respective standard categories, but there are an unbounded set
of them...
</p>

<p>
The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
&gt;(loc)</tt> would have to return a reference to a distinct object for each
valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
clearly impossible.
</p>

<p>
On the other hand, if none of the facets in Table 52 is a member of a standard
category then none of the locale member functions that operate on entire
categories of facets will work properly.
</p>

<p>
It seems that what p3 should mention that it's required (permitted?)
to hold only for specializations of <tt>Facet</tt> from Table 52 on
<tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
<tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
{
{i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
}.
</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.3.1.1.1 [locale.category], paragraph 3, change
"that is a member of a standard category" to "shown in Table 51".</p>


<p><b>Rationale:</b></p>
<p>The facets in Table 52 are an unbounded set.  Locales should not be
required to contain an infinite number of facets.</p> 

<p>It's not necessary to talk about which values of InputIterator and
OutputIterator must be supported.  Table 51 already contains a
complete list of the ones we need.</p>






<hr>
<h3><a name="341"></a>341. Vector reallocation and swap</h3>
<p><b>Section:</b> 23.4.1.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-09-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It is a common idiom to reduce the capacity of a vector by swapping it with
an empty one:</p>
<pre>  std::vector&lt;SomeType&gt; vec;
  // fill vec with data
  std::vector&lt;SomeType&gt;().swap(vec);
  // vec is now empty, with minimal capacity
</pre>

<p>However, the wording of 23.4.1.2 [vector.capacity]paragraph 5 prevents
the capacity of a vector being reduced, following a call to
reserve(). This invalidates the idiom, as swap() is thus prevented
from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this.  Consequently, the example above
requires the temporary to be expanded to cater for the contents of
vec, and the contents be copied across. This is a linear-time
operation.</p>

<p>However, the container requirements state that swap must have constant
complexity (23.2 [container.requirements] note to table 65).</p>

<p>This is an important issue, as reallocation affects the validity of
references and iterators.</p>

<p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
references and iterators remain valid after a call to swap, if they refer to
an element before the new end() of the vector into which they originally
pointed, in which case they refer to the element at the same index position.
Iterators and references that referred to an element whose index position
was beyond the new end of the vector are invalidated.</p>

<p>If the note to table 65 is taken as the desired intent, then there are two
possibilities with regard to iterators and references:</p>

<ol>
<li>All Iterators and references into both vectors are invalidated.</li>
<li>Iterators and references into either vector remain valid, and remain
pointing to the same element. Consequently iterators and references that
referred to one vector now refer to the other, and vice-versa.</li>
</ol>


<p><b>Proposed resolution:</b></p>
<p>Add a new paragraph after 23.4.1.2 [vector.capacity] paragraph 5:</p>
<blockquote>
<pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
</pre>
<p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
with that of <tt>x</tt>.</p>
<p><b>Complexity:</b> Constant time.</p>
</blockquote>

<p><i>[This solves the problem reported for this issue.  We may also
have a problem with a circular definition of swap() for other
containers.]</i></p>




<p><b>Rationale:</b></p>
<p>
swap should be constant time.  The clear intent is that it should just
do pointer twiddling, and that it should exchange all properties of
the two vectors, including their reallocation guarantees.
</p>





<hr>
<h3><a name="345"></a>345. type tm in &lt;cwchar&gt;</h3>
<p><b>Section:</b> 21.7 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2001-10-19 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
declares struct tm as an incomplete type. However, table 48 in 21.7 [c.strings] does not mention the type tm as being declared in
&lt;cwchar&gt;. Is this omission intentional or accidental?
</p>


<p><b>Proposed resolution:</b></p>
<p>In section 21.7 [c.strings], add "tm" to table 48.</p>





<hr>
<h3><a name="346"></a>346. Some iterator member functions should be const</h3>
<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 2001-10-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Iterator member functions and operators that do not change the state
of the iterator should be defined as const member functions or as
functions that take iterators either by const reference or by
value. The standard does not explicitly state which functions should
be const.  Since this a fairly common mistake, the following changes
are suggested to make this explicit.</p>

<p>The tables almost indicate constness properly through naming: r
for non-const and a,b for const iterators. The following changes
make this more explicit and also fix a couple problems.</p>


<p><b>Proposed resolution:</b></p>
<p>In X [iterator.concepts] Change the first section of p9 from
"In the following sections, a and b denote values of X..." to
"In the following sections, a and b denote values of type const X...".</p>

<p>In Table 73, change</p>
<pre>    a-&gt;m   U&amp;         ...
</pre>

<p>to</p>

<pre>    a-&gt;m   const U&amp;   ...
    r-&gt;m   U&amp;         ...
</pre>

<p>In Table 73 expression column, change</p>

<pre>    *a = t
</pre>

<p>to</p>

<pre>    *r = t
</pre>

<p><i>[Redmond: The container requirements should be reviewed to see if
the same problem appears there.]</i></p>







<hr>
<h3><a name="347"></a>347. locale::category and bitmask requirements</h3>
<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Opened:</b> 2001-10-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 22.3.1.1.1 [locale.category] paragraph 1, the category members
are described as bitmask elements.  In fact, the bitmask requirements
in 17.5.2.1.3 [bitmask.types] don't seem quite right: <tt>none</tt>
and <tt>all</tt> are bitmask constants, not bitmask elements.</p>

<p>In particular, the requirements for <tt>none</tt> interact poorly
with the requirement that the LC_* constants from the C library must
be recognizable as C++ locale category constants.  LC_* values should
not be mixed with these values to make category values.</p>

<p>We have two options for the proposed resolution.  Informally:
option 1 removes the requirement that LC_* values be recognized as
category arguments.  Option 2 changes the category type so that this
requirement is implementable, by allowing <tt>none</tt> to be some
value such as 0x1000 instead of 0.</p>

<p>Nathan writes: "I believe my proposed resolution [Option 2] merely
re-expresses the status quo more clearly, without introducing any
changes beyond resolving the DR.</p>



<p><b>Proposed resolution:</b></p>
<p>Replace the first two paragraphs of 22.3.1.1 [locale.types] with:</p>
<blockquote>
<pre>    typedef int category;
</pre>

<p>Valid category values include the <tt>locale</tt> member bitmask
elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
represents a single locale category. In addition, <tt>locale</tt> member
bitmask constant <tt>none</tt> is defined as zero and represents no
category. And locale member bitmask constant <tt>all</tt> is defined such that
the expression</p>
<pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
</pre>
<p>
is <tt>true</tt>, and represents the union of all categories.  Further
the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
represent a single category, represents the union of the two
categories.
</p>

<p>
<tt>locale</tt> member functions expecting a <tt>category</tt>
argument require one of the <tt>category</tt> values defined above, or
the union of two or more such values. Such a <tt>category</tt>
argument identifies a set of locale categories. Each locale category,
in turn, identifies a set of locale facets, including at least those
shown in Table 51:
</p>
</blockquote>
<p><i>[Cura�ao: need input from locale experts.]</i></p>




<p><b>Rationale:</b></p>

<p>The LWG considered, and rejected, an alternate proposal (described
  as "Option 2" in the discussion).  The main reason for rejecting it
  was that library implementors were concerened about implementation
  difficult, given that getting a C++ library to work smoothly with a
  separately written C library is already a delicate business.  Some
  library implementers were also concerned about the issue of adding
  extra locale categories.</p>

<blockquote>
<p><b>Option 2:</b> <br>
Replace the first paragraph of 22.3.1.1 [locale.types] with:</p>
<blockquote>
<p>
Valid category values include the enumerated values.  In addition, the
result of applying commutative operators | and &amp; to any two valid 
values is valid, and results in the setwise union and intersection, 
respectively, of the argument categories.  The values <tt>all</tt> and 
<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
<tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are 
true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of 
those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
[Footnote: it is not required that <tt>all</tt> equal the setwise union
of the other enumerated values; implementations may add extra categories.]
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3>
<p><b>Section:</b> 24.6.2 [ostream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>24.5.2 [lib.ostream.iterator] states:</p>
<pre>    [...]

    private:
    // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
    // const char* delim; exposition only
</pre>

<p>Whilst it's clearly marked "exposition only", I suspect 'delim'
should be of type 'const charT*'.</p>


<p><b>Proposed resolution:</b></p>
<p>
In 24.6.2 [ostream.iterator], replace <tt>const char* delim</tt> with
<tt>const charT* delim</tt>.
</p>





<hr>
<h3><a name="352"></a>352. missing fpos requirements</h3>
<p><b>Section:</b> 21.2.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.typedefs">issues</a> in [char.traits.typedefs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<i>(1)</i>
There are no requirements on the <tt>stateT</tt> template parameter of
<tt>fpos</tt> listed in 27.4.3. The interface appears to require that
the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
and I think also DefaultConstructible (to implement the operations in
Table 88).
</p>
<p>
21.1.2, p3, however, only requires that
<tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
CopyConstructible types.
</p>
<p>
<i>(2)</i>
Additionally, the <tt>stateT</tt> template argument has no
corresponding typedef in fpos which might make it difficult to use in
generic code.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Modify 21.1.2, p4 from
</p>
<p>
    Requires: <tt>state_type</tt> shall meet the requirements of
              CopyConstructible types (20.1.3).
</p>
<p>
    Requires: state_type shall meet the requirements of Assignable
              (23.1, p4), CopyConstructible (20.1.3), and
              DefaultConstructible  (20.1.4) types.
</p>



<p><b>Rationale:</b></p>
<p>The LWG feels this is two issues, as indicated above. The first is
a defect---std::basic_fstream is unimplementable without these
additional requirements---and the proposed resolution fixes it.  The
second is questionable; who would use that typedef?  The class
template fpos is used only in a very few places, all of which know the
state type already.  Unless motivation is provided, the second should
be considered NAD.</p>





<hr>
<h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
no template assignment operator. This may lead to inefficient code since
assigning an object of <tt>pair&lt;C, D&gt;</tt> to <tt>pair&lt;A, B&gt;</tt>
where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to
<tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy
ctor to construct an unnamed temporary of type <tt>pair&lt;A, B&gt;</tt>
followed by an ordinary (perhaps implicitly defined) assignment operator,
instead of just a straight assignment.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the following declaration to the definition of <tt>std::pair</tt>:
</p>
<pre>    template&lt;class U, class V&gt;
    pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
</pre>
<p>
And also add a paragraph describing the effects of the function template to the
end of 20.2.2:
</p>
<pre>    template&lt;class U, class V&gt;
    pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
</pre>
<p>
    <b>Effects</b>: <tt>first = p.first;</tt>
                    <tt>second = p.second;</tt>
    <b>Returns</b>: <tt>*this</tt>
</p>

<p><i>[Cura�ao: There is no indication this is was anything other than
a design decision, and thus NAD.&nbsp; May be appropriate for a future
standard.]</i></p>


<p><i>[
Pre Bellevue:  It was recognized that this was taken care of by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>,
and thus moved from NAD Future to <del>NAD Editorial</del><ins>Resolved</ins>.
]</i></p>






<hr>
<h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Hans Aberg <b>Opened:</b> 2001-12-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Discussions in the thread "Associative container lower/upper bound
requirements" on comp.std.c++ suggests that there is a defect in the
C++ standard, Table 69 of section 23.1.2, "Associative containers",
[lib.associative.reqmts].  It currently says:</p>

<blockquote>
<p>
a.find(k): returns an iterator pointing to an element with the key equivalent to
k, or a.end() if such an element is not found.
</p>

<p>
a.lower_bound(k): returns an iterator pointing to the first element with
key not less than k.
</p>

<p>
a.upper_bound(k): returns an iterator pointing to the first element with
key greater than k.
</p>
</blockquote>

<p>
We have "or a.end() if such an element is not found" for
<tt>find</tt>, but not for <tt>upper_bound</tt> or
<tt>lower_bound</tt>.  As the text stands, one would be forced to
insert a new element into the container and return an iterator to that
in case the sought iterator does not exist, which does not seem to be
the intention (and not possible with the "const" versions).
</p>


<p><b>Proposed resolution:</b></p>

<p>Change Table 69 of section 23.2.4 [associative.reqmts] indicated entries
to:</p>

<blockquote>
<p>
a.lower_bound(k): returns an iterator pointing to the first element with
key not less than k, or a.end() if such an element is not found.
</p>

<p>
a.upper_bound(k): returns an iterator pointing to the first element with
key greater than k, or a.end() if such an element is not found.
</p>
</blockquote>

<p><i>[Cura�ao: LWG reviewed PR.]</i></p>








<hr>
<h3><a name="355"></a>355. Operational semantics for a.back()</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Yaroslav Mironov <b>Opened:</b> 2002-01-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>Table 68 "Optional Sequence Operations" in 23.1.1/12
specifies operational semantics for "a.back()" as
"*--a.end()", which may be ill-formed <i>[because calling
operator-- on a temporary (the return) of a built-in type is
ill-formed]</i>, provided a.end() returns a simple pointer rvalue
(this is almost always the case for std::vector::end(), for
example). Thus, the specification is not only incorrect, it
demonstrates a dangerous construct: "--a.end()" may
successfully compile and run as intended, but after changing the type
of the container or the mode of compilation it may produce
compile-time error. </p>



<p><b>Proposed resolution:</b></p>
<p>Change the specification in table 68 "Optional Sequence
Operations" in 23.1.1/12 for "a.back()" from</p>


<blockquote><pre>*--a.end()
</pre></blockquote>

<p>to</p>

<blockquote><pre>  { iterator tmp = a.end(); --tmp; return *tmp; }
</pre></blockquote>

<p>and the specification for "a.pop_back()" from</p>

<blockquote><pre>a.erase(--a.end())
</pre></blockquote>

<p>to</p>

<blockquote><pre>  { iterator tmp = a.end(); --tmp; a.erase(tmp); }
</pre></blockquote>

<p><i>[Cura�ao: LWG changed PR from "{ X::iterator tmp =
a.end(); return *--tmp; }" to "*a.rbegin()", and from
"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
"a.erase(rbegin())".]</i></p>


<p><i>[There is a second possible defect; table 68 "Optional
Sequence Operations" in the "Operational Semantics"
column uses operations present only in the "Reversible
Container" requirements, yet there is no stated dependency
between these separate requirements tables. Ask in Santa Cruz if the
LWG would like a new issue opened.]</i></p>


<p><i>[Santa Cruz: the proposed resolution is even worse than what's in
  the current standard: erase is undefined for reverse iterator.  If
  we're going to make the change, we need to define a temporary and
  use operator--.  Additionally, we don't know how prevalent this is:
  do we need to make this change in more than one place?  Martin has
  volunteered to review the standard and see if this problem occurs
  elsewhere.]</i></p>


<p><i>[Oxford: Matt provided new wording to address the concerns raised
  in Santa Cruz.  It does not appear that this problem appears
  anywhere else in clauses 23 or 24.]</i></p>


<p><i>[Kona: In definition of operational semantics of back(), change
"*tmp" to "return *tmp;"]</i></p>







<hr>
<h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I don't think <tt>thousands_sep</tt> is being treated correctly after
decimal_point has been seen. Since grouping applies only to the
integral part of the number, the first such occurrence should, IMO,
terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
interpreted in the fractional part of a number.)
</p>

<p>
The easiest change I can think of that resolves this issue would be
something like below.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the first sentence of 22.2.2.1.2, p9 from
</p>

<blockquote><p>
    If discard is true then the position of the character is
    remembered, but the character is otherwise ignored. If it is not
    discarded, then a check is made to determine if c is allowed as
    the next character of an input field of the conversion specifier
    returned by stage 1. If so it is accumulated.
</p></blockquote>

<p>to</p>

<blockquote><p>
    If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
    accumulated, then the position of the character is remembered, but
    the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
    already been accumulated, the character is discarded and Stage 2
     terminates. ...
</p></blockquote>



<p><b>Rationale:</b></p>
<p>We believe this reflects the intent of the Standard.  Thousands sep
  characters after the decimal point are not useful in any locale.
  Some formatting conventions do group digits that follow the decimal
  point, but they usually introduce a different grouping character
  instead of reusing the thousand sep character.  If we want to add
  support for such conventions, we need to do so explicitly.</p>






<hr>
<h3><a name="359"></a>359. num_put&lt;&gt;::do_put (..., bool) undocumented</h3>
<p><b>Section:</b> 22.4.2.2.1 [facet.num.put.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>22.2.2.2.1, p1:</p>

    <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
                   bool val) const;
    ...

    1   Returns: do_put (out, str, fill, val).
    </pre>

<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
however, 22.2.2.2.2, p23:</p>

<blockquote>
<pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
               bool val) const;
</pre>


        <p>Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
             out = do_put(out, str, fill, (int)val)
           Otherwise do</p>
<pre>             string_type s =
                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
</pre>
           <p>and then insert the characters of s into out. <i>out</i>.</p>
</blockquote>

<p>
This means that the bool overload of <tt>do_put()</tt> will never be called,
which contradicts the first paragraph. Perhaps the declaration
should read <tt>do_put()</tt>, and not <tt>put()</tt>?
</p>

<p>
Note also that there is no <b>Returns</b> clause for this function, which
should probably be corrected, just as should the second occurrence
of <i>"out."</i> in the text.
</p>

<p>
I think the least invasive change to fix it would be something like
the following:
</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.4.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
  the <tt>bool</tt> overload.</p>

<p>
In 22.4.2.2.2 [facet.num.put.virtuals], p23, make the following changes
</p>

<blockquote><p>
     Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
     of the member function.
</p></blockquote>

<blockquote><p>
    Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
    avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
    do_put (..., bool))</tt>
    like so:
</p></blockquote>

<blockquote><p>
    23   <b>Returns</b>: If <tt>(str.flags() &amp;
         ios_base::boolalpha) == 0</tt> then
         <tt>do_put (out, str, fill, (long)val)</tt>
         Otherwise the function obtains a string <tt>s</tt> as if by</p>
<pre>             string_type s =
                val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
                    : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
</pre>
         <p>and then inserts each character <tt>c</tt> of s into out via
           <tt>*out++ = c</tt>
         and returns <tt>out</tt>.</p>
</blockquote>



<p><b>Rationale:</b></p><p>
This fixes a couple of obvious typos, and also fixes what appears to
be a requirement of gratuitous inefficiency.
</p>




<hr>
<h3><a name="360"></a>360. locale mandates inefficient implementation</h3>
<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
22.1.1, p7 (copied below) allows iostream formatters and extractors
to make assumptions about the values returned from facet members.
However, such assumptions are apparently not guaranteed to hold
in other cases (e.g., when the facet members are being called directly
rather than as a result of iostream calls, or between successive
calls to the same iostream functions with no interevening calls to
<tt>imbue()</tt>, or even when the facet member functions are called
from other member functions of other facets). This restriction
prevents locale from being implemented efficiently.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change the first sentence in 22.1.1, p7 from</p>
<blockquote><p>
    In successive calls to a locale facet member function during
    a call to an iostream inserter or extractor or a streambuf member
    function, the returned result shall be identical. [Note: This
    implies that such results may safely be reused without calling
    the locale facet member function again, and that member functions
    of iostream classes cannot safely call <tt>imbue()</tt>
    themselves, except as specified elsewhere. --end note]
</p></blockquote>

<p>to</p>

<blockquote><p>
    In successive calls to a locale facet member function on a facet
    object installed in the same locale, the returned result shall be
    identical. ...
</p></blockquote>



<p><b>Rationale:</b></p>
<p>This change is reasonable becuase it clarifies the intent of this
  part of the standard.</p>





<hr>
<h3><a name="362"></a>362. bind1st/bind2nd type safety</h3>
<p><b>Section:</b> D.11 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andrew Demkin <b>Opened:</b> 2002-04-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The definition of bind1st() (D.11 [depr.lib.binders]) can result in
the construction of an unsafe binding between incompatible pointer
types. For example, given a function whose first parameter type is
'pointer to T', it's possible without error to bind an argument of
type 'pointer to U' when U does not derive from T:
</p>
<pre>   foo(T*, int);

   struct T {};
   struct U {};

   U u;

   int* p;
   int* q;

   for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
</pre>

<p>
The definition of bind1st() includes a functional-style conversion to
map its argument to the expected argument type of the bound function
(see below):
</p>
<pre>  typename Operation::first_argument_type(x)
</pre>

<p>
A functional-style conversion (D.11 [depr.lib.binders]) is defined to be
semantically equivalent to an explicit cast expression (D.11 [depr.lib.binders]), which may (according to 5.4, paragraph 5) be interpreted
as a reinterpret_cast, thus masking the error.
</p>

<p>The problem and proposed change also apply to D.11 [depr.lib.binders].</p>


<p><b>Proposed resolution:</b></p>
<p>Add this sentence to the end of D.11 [depr.lib.binders]/1:
  "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
  favor of <tt>std::tr1::bind</tt>."</p>

<p>(Notes to editor: (1) when and if tr1::bind is incorporated into
  the standard, "std::tr1::bind" should be changed to "std::bind". (2)
  20.5.6 should probably be moved to Annex D.</p>


<p><b>Rationale:</b></p>
<p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
  superior solution.  It solves this problem and others.</p>





<hr>
<h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3>
<p><b>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Walter Brown and Marc Paterno <b>Opened:</b> 2002-05-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The destructor of ios_base::failure should have an empty throw
specification, because the destructor of its base class, exception, is
declared in this way.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change the destructor to</p>
<pre>  virtual ~failure() throw();
</pre>


<p><b>Rationale:</b></p>
<p>Fixes an obvious glitch.  This is almost editorial.</p>





<hr>
<h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3>
<p><b>Section:</b> 27.6.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
27.6.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
clause for seekoff.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Make this paragraph, the Effects clause for setbuf, consistent in wording
with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
to indicate the purpose of setbuf:
</p>

<p>Original text:</p>

<blockquote><p>
1 Effects: Performs an operation that is defined separately for each
class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
</p></blockquote>

<p>Proposed text:</p>

<blockquote><p>
1 Effects: Influences stream buffering in a way that is defined separately
for each class derived from basic_streambuf in this clause
(27.7.1.3, 27.8.1.4).
</p></blockquote>



<p><b>Rationale:</b></p>
<p>The LWG doesn't believe there is any normative difference between
  the existing wording and what's in the proposed resolution, but the
  change may make the intent clearer.</p>





<hr>
<h3><a name="365"></a>365. Lack of const-qualification in clause 27</h3>
<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Some stream and streambuf member functions are declared non-const,
even thought they appear only to report information rather than to
change an object's logical state.  They should be declared const.  See
document N1360 for details and rationale.
</p>

<p>The list of member functions under discussion: <tt>in_avail</tt>,
<tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>

<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>



<p><b>Proposed resolution:</b></p>
<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
<p>Replace</p>
<pre>  bool is_open();
</pre>
<p>with</p>
<pre>  bool is_open() const;
</pre>


<p><b>Rationale:</b></p>
<p>Of the changes proposed in N1360, the only one that is safe is
changing the filestreams' is_open to const.  The LWG believed that
this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a>), but now thinks otherwise.  The corresponding streambuf
member function, after all,is already const.</p>

<p>The other proposed changes are less safe, because some streambuf
functions that appear merely to report a value do actually perform
mutating operations.  It's not even clear that they should be
considered "logically const", because streambuf has two interfaces, a
public one and a protected one.  These functions may, and often do,
change the state as exposed by the protected interface, even if the
state exposed by the public interface is unchanged.</p>

<p>Note that implementers can make this change in a binary compatible
way by providing both overloads; this would be a conforming extension.</p>






<hr>
<h3><a name="369"></a>369. io stream objects and static ctors</h3>
<p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Ruslan Abdikeev <b>Opened:</b> 2002-07-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is it safe to use standard iostream objects from constructors of
static objects?  Are standard iostream objects constructed and are
their associations established at that time?
</p>

<p>Surpisingly enough, Standard does NOT require that.</p>

<p>
27.3/2 [lib.iostream.objects] guarantees that standard iostream
objects are constructed and their associations are established before
the body of main() begins execution.  It also refers to ios_base::Init
class as the panacea for constructors of static objects.
</p>

<p>
However, there's nothing in 27.3 [lib.iostream.objects],
in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
that would require implementations to allow access to standard
iostream objects from constructors of static objects.
</p>

<p>Details:</p>

<p>Core text refers to some magic object ios_base::Init, which will
be discussed below:</p>

<blockquote><p>
    "The [standard iostream] objects are constructed, and their
    associations are established at some time prior to or during
    first time an object of class basic_ios&lt;charT,traits&gt;::Init
    is constructed, and in any case before the body of main
    begins execution." (27.3/2 [lib.iostream.objects])
</p></blockquote>

<p>
The first <i>non-normative</i> footnote encourages implementations
to initialize standard iostream objects earlier than required.
</p>

<p>However, the second <i>non-normative</i> footnote makes an explicit
and unsupported claim:</p>

<blockquote><p>
  "Constructors and destructors for static objects can access these
  [standard iostream] objects to read input from stdin or write output
  to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
</p></blockquote>

<p>
The only bit of magic is related to that ios_base::Init class.  AFAIK,
the rationale behind ios_base::Init was to bring an instance of this
class to each translation unit which #included &lt;iostream&gt; or
related header.  Such an inclusion would support the claim of footnote
quoted above, because in order to use some standard iostream object it
is necessary to #include &lt;iostream&gt;.
</p>

<p>
However, while Standard explicitly describes ios_base::Init as
an appropriate class for doing the trick, I failed to found a
mention of an _instance_ of ios_base::Init in Standard.
</p>


<p><b>Proposed resolution:</b></p>

<p>Add to 27.4 [iostream.objects], p2, immediately before the last sentence
of the paragraph, the following two sentences:</p>

<blockquote><p>
If a translation unit includes &lt;iostream&gt;, or explicitly
constructs an ios_base::Init object, these stream objects shall
be constructed before dynamic initialization of non-local
objects defined later in that translation unit, and these stream
objects shall be destroyed after the destruction of dynamically
initialized non-local objects defined later in that translation unit.
</p></blockquote>

<p><i>[Lillehammer: Matt provided wording.]</i></p>

<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>



<p><b>Rationale:</b></p>
<p>
The original proposed resolution unconditionally required
implementations to define an ios_base::Init object of some
implementation-defined name in the header &lt;iostream&gt;. That's an
overspecification. First, defining the object may be unnecessary
and even detrimental to performance if an implementation can
guarantee that the 8 standard iostream objects will be initialized
before any other user-defined object in a program. Second, there
is no need to require implementations to document the name of the
object.</p>

<p>
The new proposed resolution gives users guidance on what they need to
do to ensure that stream objects are constructed during startup.</p>





<hr>
<h3><a name="370"></a>370. Minor error in basic_istream::get</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-07-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Defect report for description of basic_istream::get (section 27.7.1.3 [istream.unformatted]), paragraph 15. The description for the get function
with the following signature:</p>

<pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
  sb);
</pre>

<p>is incorrect. It reads</p>

<blockquote><p>
  Effects: Calls get(s,n,widen('\n'))
</p></blockquote>

<p>which I believe should be:</p>

<blockquote><p>
  Effects: Calls get(sb,widen('\n'))
</p></blockquote>


<p><b>Proposed resolution:</b></p>
<p>Change the <b>Effects</b> paragraph to:</p>
<blockquote><p>
  Effects: Calls get(sb,this-&gt;widen('\n'))
</p></blockquote>

<p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen' 
      with 'this-&gt;widen'.]</i></p>




<p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>




<hr>
<h3><a name="371"></a>371. Stability of multiset and multimap member functions</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Frank Compagner <b>Opened:</b> 2002-07-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements for multiset and multimap containers (23.1
[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
the stability of the required (mutating) member functions. It appears
the standard allows these functions to reorder equivalent elements of
the container at will, yet the pervasive red-black tree implementation
appears to provide stable behaviour.
</p>

<p>This is of most concern when considering the behaviour of erase().
A stability requirement would guarantee the correct working of the
following 'idiom' that removes elements based on a certain predicate
function.
</p>

<pre>  multimap&lt;int, int&gt; m;
  multimap&lt;int, int&gt;::iterator i = m.begin();
  while (i != m.end()) {
      if (pred(i))
          m.erase (i++);
      else
          ++i;
  }
</pre>

<p>
Although clause 23.1.2/8 guarantees that i remains a valid iterator
througout this loop, absence of the stability requirement could
potentially result in elements being skipped. This would make
this code incorrect, and, furthermore, means that there is no way
of erasing these elements without iterating first over the entire
container, and second over the elements to be erased. This would
be unfortunate, and have a negative impact on both performance and
code simplicity.
</p>

<p>
If the stability requirement is intended, it should be made explicit
(probably through an extra paragraph in clause 23.1.2).
</p>
<p>
If it turns out stability cannot be guaranteed, i'd argue that a
remark or footnote is called for (also somewhere in clause 23.1.2) to
warn against relying on stable behaviour (as demonstrated by the code
above).  If most implementations will display stable behaviour, any
problems emerging on an implementation without stable behaviour will
be hard to track down by users. This would also make the need for an
erase_if() member function that much greater.
</p>

<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>



<p><b>Proposed resolution:</b></p>

<p>Add the following to the end of 23.2.4 [associative.reqmts] paragraph 4: 
"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
  are <i>stable</i>: they preserve the relative ordering of equivalent
  elements.</p> 

<p><i>[Lillehammer: Matt provided wording]</i></p>

<p><i>[Joe Gottman points out that the provided wording does not address
multimap and multiset.  N1780 also addresses this issue and suggests
wording.]</i></p>


<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>




<p><b>Rationale:</b></p>
<p>The LWG agrees that this guarantee is necessary for common user
  idioms to work, and that all existing implementations provide this
  property.  Note that this resolution guarantees stability for
  multimap and multiset, not for all associative containers in
  general.</p>






<hr>
<h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3>
<p><b>Section:</b> 27.7.1.2.1 [istream.formatted.reqmts], 27.7.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Keith Baker <b>Opened:</b> 2002-07-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts]
(exception()&amp;badbit) != 0 is used in testing for rethrow, yet
exception() is the constructor to class std::exception in 18.7.1 [type.info] that has no return type. Should member function
exceptions() found in 27.5.4 [ios] be used instead?
</p>



<p><b>Proposed resolution:</b></p>
<p>
In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts], change
"(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
</p>


<p><b>Rationale:</b></p>
<p>Fixes an obvious typo.</p>





<hr>
<h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3>
<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Section 27.8.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
14 all contain references to "basic_ios::" which should be
"ios_base::".
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change all references to "basic_ios" in Table 90, Table 91, and
paragraph 14 to "ios_base".
</p>


<p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>




<hr>
<h3><a name="376"></a>376. basic_streambuf semantics</h3>
<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Section 27.8.1.4 [stringbuf.virtuals], Table 90, the implication is that
the four conditions should be mutually exclusive, but they are not.
The first two cases, as written, are subcases of the third.</p>

<p>
As written, it is unclear what should be the result if cases 1 and 2
are both true, but case 3 is false.
</p>



<p><b>Proposed resolution:</b></p>

<p>Rewrite these conditions as:</p>
<blockquote>
<p>
  (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
</p>

<p>
  (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
</p>

<p>
  (which &amp; (ios_base::in|ios_base::out)) == 
(ios_base::in|ios_base::out)
   and way == either ios_base::beg or ios_base::end
</p>

<p>Otherwise</p>
</blockquote>



<p><b>Rationale:</b></p>
<p>It's clear what we wanted to say, we just failed to say it.  This
  fixes it.</p>





<hr>
<h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</h3>
<p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
</p>
<pre>  charT do_widen (char c) const;

  -11- Effects: Applies the simplest reasonable transformation from
       a char value or sequence of char values to the corresponding
       charT value or values. The only characters for which unique
       transformations are required are those in the basic source
       character set (2.2). For any named ctype category with a
       ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
       M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
</pre>
<p>
Shouldn't the last sentence instead read
</p>
<pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
       and valid ctype_base::mask value M
       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
</pre>
<p>
I.e., if the narrow character c is not a member of a class of
characters then neither is the widened form of c. (To paraphrase
footnote 224.)
</p>


<p><b>Proposed resolution:</b></p>
<p>
Replace the last sentence of 22.4.1.1.2 [locale.ctype.virtuals], p11 with the
following text:
</p>
<pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
       and valid ctype_base::mask value M,
       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
</pre>

<p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>




<p><b>Rationale:</b></p>
<p>The LWG believes this is just a typo, and that this is the correct fix.</p>





<hr>
<h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3>
<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Tables 53 and 54 in 22.4.1.5 [locale.codecvt.byname] are both titled "convert
result values," when surely "do_in/do_out result values" must have
been intended for Table 53 and "do_unshift result values" for Table
54.
</p>
<p>
Table 54, row 3 says that the meaning of partial is "more characters
needed to be supplied to complete termination." The function is not
supplied any characters, it is given a buffer which it fills with
characters or, more precisely, destination elements (i.e., an escape
sequence). So partial means that space for more than (to_limit - to)
destination elements was needed to terminate a sequence given the
value of state.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the title of Table 53 to "do_in/do_out result values" and
the title of Table 54 to "do_unshift result values."
</p>
<p>
Change the text in Table 54, row 3 (the <b>partial</b> row), under the
heading Meaning, to "space for more than (to_limit - to) destination
elements was needed to terminate a sequence given the value of state."
</p>




<hr>
<h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3>
<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
All but one codecvt member functions that take a state_type argument
list as one of their preconditions that the state_type argument have
a valid value. However, according to 22.2.1.5.2, p6,
codecvt::do_unshift() is the only codecvt member that is supposed to
return error if the state_type object is invalid.
</p>

<p>
It seems to me that the treatment of state_type by all codecvt member
functions should be the same and the current requirements should be
changed. Since the detection of invalid state_type values may be
difficult in general or computationally expensive in some specific
cases, I propose the following:
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add a new paragraph before 22.2.1.5.2, p5, and after the function
declaration below
</p>
<pre>    result do_unshift(stateT&amp; state,
    externT* to, externT* to_limit, externT*&amp; to_next) const;
</pre>
<p>
as follows:
</p>
<pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
    if at the beginning of a sequence, or else equal to the result of
    converting the preceding characters in the sequence.
</pre>
<p>
and change the text in Table 54, row 4, the <b>error</b> row, under
the heading Meaning, from
</p>
<pre>    state has invalid value
</pre>
<p>
to
</p>
<pre>    an unspecified error has occurred
</pre>


<p><b>Rationale:</b></p>
<p>The intent is that implementations should not be required to detect
invalid state values; such a requirement appears nowhere else.  An
invalid state value is a precondition violation, <i>i.e.</i> undefined
behavior.  Implementations that do choose to detect invalid state
values, or that choose to detect any other kind of error, may return
<b>error</b> as an indication.</p>





<hr>
<h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3>
<p><b>Section:</b> 24.2.6 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Opened:</b> 2002-10-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Following a discussion on the boost list regarding end iterators and
the possibility of performing operator--() on them, it seems to me
that there is a typo in the standard.  This typo has nothing to do
with that discussion.
</p>

<p>
I have checked this newsgroup, as well as attempted a search of the
Active/Defect/Closed Issues List on the site for the words "s is
derefer" so I believe this has not been proposed before.  Furthermore,
the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a> on section
24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a> is not related to this issue.
</p>

<p>
The standard makes the following assertion on bidirectional iterators,
in section 24.1.4 [lib.bidirectional.iterators], Table 75:
</p>

<pre>                         operational  assertion/note
expression  return type   semantics    pre/post-condition

--r          X&amp;                        pre: there exists s such
                                       that r == ++s.
                                       post: s is dereferenceable.
                                       --(++r) == r.
                                       --r == --s implies r == s.
                                       &amp;r == &amp;--r.
</pre>

<p>
(See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
</p>

<p>
In particular, "s is dereferenceable" seems to be in error.  It seems
that the intention was to say "r is dereferenceable".
</p>

<p>
If it were to say "r is dereferenceable" it would
make perfect sense.  Since s must be dereferenceable prior to
operator++, then the natural result of operator-- (to undo operator++)
would be to make r dereferenceable.  Furthermore, without other
assertions, and basing only on precondition and postconditions, we
could not otherwise know this.  So it is also interesting information.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change the guarantee to "postcondition: r is dereferenceable."
</p>


<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>




<hr>
<h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3>
<p><b>Section:</b> 25.4.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Hans Bos <b>Opened:</b> 2002-10-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 25.4.3.3 [equal.range]
states that at most 2 * log(last - first) + 1
comparisons are allowed for equal_range.
</p>

<p>It is not possible to implement equal_range with these constraints.</p>

<p>In a range of one element as in:</p>
<pre>    int x = 1;
    equal_range(&amp;x, &amp;x + 1, 1)
</pre>

<p>it is easy to see that at least 2 comparison operations are needed.</p>

<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>

<p>I have checked a few libraries and they all use the same (nonconforming)
algorithm for equal_range that has a complexity of</p>
<pre>     2* log(distance(first, last)) + 2.
</pre>
<p>I guess this is the algorithm that the standard assumes for equal_range.</p>

<p>
It is easy to see that 2 * log(distance) + 2 comparisons are enough
since equal range can be implemented with lower_bound and upper_bound
(both log(distance) + 1).
</p>

<p>
I think it is better to require something like 2log(distance) + O(1)  (or
even logarithmic as multiset::equal_range).
Then an implementation has more room to optimize for certain cases (e.g.
have log(distance) characteristics when at most match is found in the range
but 2log(distance) + 4 for the worst case).
</p>



<p><b>Proposed resolution:</b></p>
<p>In 25.4.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>

<p>In 25.4.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>

<p>In 25.4.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>

<p><i>[Matt provided wording]</i></p>



<p><b>Rationale:</b></p>
<p>The LWG considered just saying <i>O</i>(log n) for all three, but
  decided that threw away too much valuable information.  The fact
  that lower_bound is twice as fast as equal_range is important.
  However, it's better to allow an arbitrary additive constant than to
  specify an exact count.  An exact count would have to
  involve <tt>floor</tt> or <tt>ceil</tt>.  It would be too easy to
  get this wrong, and don't provide any substantial value for users.</p>




<hr>
<h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3>
<p><b>Section:</b> 24.5.1.3.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 24.5.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator&lt;&gt;::operator[]</tt> 
is specified as having a return type of <tt>reverse_iterator::reference</tt>,
which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
(Where <tt>Iterator</tt> is the underlying iterator type.)</p>

<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
  necessarily have a return type
  of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
  return type is merely required to be convertible
  to <tt>Iterator</tt>'s value type.  The return type specified for
  reverse_iterator's operator[] would thus appear to be impossible.</p>

<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, the type of
  <tt>a[n]</tt> will continue to be required (for random access
  iterators) to be convertible to the value type, and also <tt>a[n] =
  t</tt> will be a valid expression.  Implementations of
  <tt>reverse_iterator</tt> will likely need to return a proxy from
  <tt>operator[]</tt> to meet these requirements. As mentioned in the
  comment from Dave Abrahams, the simplest way to specify that
  <tt>reverse_iterator</tt> meet this requirement to just mandate
  it and leave the return type of <tt>operator[]</tt> unspecified.</p>



<p><b>Proposed resolution:</b></p>

<p>In 24.5.1.2 [reverse.iter.requirements] change:</p>

<blockquote>
<pre>reference operator[](difference_type n) const;
</pre>
</blockquote>

<p>to:</p>

<blockquote>
<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.2.7 [random.access.iterators]
</pre>
</blockquote>




<p><i>[
Comments from Dave Abrahams: IMO we should resolve 386 by just saying
    that the return type of reverse_iterator's operator[] is
    unspecified, allowing the random access iterator requirements to
    impose an appropriate return type.  If we accept 299's proposed
    resolution (and I think we should), the return type will be
    readable and writable, which is about as good as we can do.
]</i></p>






<hr>
<h3><a name="387"></a>387. std::complex over-encapsulated</h3>
<p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The absence of explicit description of std::complex&lt;T&gt; layout
makes it imposible to reuse existing software developed in traditional
languages like Fortran or C with unambigous and commonly accepted
layout assumptions.  There ought to be a way for practitioners to
predict with confidence the layout of std::complex&lt;T&gt; whenever T
is a numerical datatype.  The absence of ways to access individual
parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
severe pessimizations. For example, the only way to change,
independently, the real and imaginary parts is to write something like
</p>

<pre>complex&lt;T&gt; z;
// ...
// set the real part to r
z = complex&lt;T&gt;(r, z.imag());
// ...
// set the imaginary part to i
z = complex&lt;T&gt;(z.real(), i);
</pre>

<p>
At this point, it seems appropriate to recall that a complex number
is, in effect, just a pair of numbers with no particular invariant to
maintain.  Existing practice in numerical computations has it that a
complex number datatype is usually represented by Cartesian
coordinates. Therefore the over-encapsulation put in the specification
of std::complex&lt;&gt; is not justified.
</p>



<p><b>Proposed resolution:</b></p>
<p>Add the following requirements to 26.4 [complex.numbers] as 26.3/4:</p>
<blockquote>
<p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>

<ul>
<li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
is well-formed; and</li>
<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[0]designates the
real part of z; and</li>
<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[1]designates the
imaginary part of z.</li>
</ul>

<p>
Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
and the expression a[i] is well-defined for an integer expression
i then:
</p>

<ul>
<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i] designates the real
part of a[i]; and</li>
<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i+1] designates the
imaginary part of a[i].</li>
</ul>
</blockquote>

<p>
In 26.4.2 [complex] and 26.4.3 [complex.special] add the following member functions
(changing <tt>T</tt> to concrete types as appropriate for the specializations).
</p>

<blockquote><pre>void real(T);
void imag(T);
</pre></blockquote>

<p>
Add to 26.4.4 [complex.members]
</p>

<blockquote>
<pre>T real() const;
</pre>
<blockquote>
<i>Returns:</i> the value of the real component
</blockquote>
<pre>void real(T val);
</pre>
<blockquote>
Assigns val to the real component.
</blockquote>
<pre>T imag() const;
</pre>
<blockquote>
<i>Returns:</i> the value of the imaginary component
</blockquote>
<pre>void imag(T val);
</pre>
<blockquote>
Assigns val to the imaginary component.
</blockquote>
</blockquote>

<p><i>[Kona: The layout guarantee is absolutely necessary for C
  compatibility.  However, there was disagreement about the other part
  of this proposal: retrieving elements of the complex number as
  lvalues.  An alternative: continue to have real() and imag() return
  rvalues, but add set_real() and set_imag().  Straw poll: return
  lvalues - 2, add setter functions - 5.  Related issue: do we want
  reinterpret_cast as the interface for converting a complex to an
  array of two reals, or do we want to provide a more explicit way of
  doing it?  Howard will try to resolve this issue for the next
  meeting.]</i></p>


<p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>


<p><i>[
Bellevue:
]</i></p>


<blockquote>
Second half of proposed wording replaced and moved to Ready.
</blockquote>

<p><i>[
Pre-Sophia Antipolis, Howard adds:
]</i></p>


<blockquote>
Added the members to 26.4.3 [complex.special] and changed from Ready to Review.
</blockquote>

<p><i>[
Post-Sophia Antipolis:
]</i></p>


<blockquote>
Moved from WP back to Ready so that the "and 26.4.3 [complex.special]" in the proposed
resolution can be officially applied.
</blockquote>



<p><b>Rationale:</b></p>
<p>The LWG believes that C99 compatibility would be enough
justification for this change even without other considerations.  All
existing implementations already have the layout proposed here.</p>





<hr>
<h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</h3>
<p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p>
<p><b>Discussion:</b></p>
<p>Consider the following program:</p>
<pre>    #include &lt;iostream&gt;
    #include &lt;ostream&gt;
    #include &lt;vector&gt;
    #include &lt;valarray&gt;
    #include &lt;algorithm&gt;
    #include &lt;iterator&gt;
    template&lt;typename Array&gt;
    void print(const Array&amp; a)
    {
    using namespace std;
    typedef typename Array::value_type T;
    copy(&amp;a[0], &amp;a[0] + a.size(),
    ostream_iterator&lt;T&gt;(std::cout, " "));
    }
    template&lt;typename T, unsigned N&gt;
    unsigned size(T(&amp;)[N]) { return N; }
    int main()
    {
    double array[] = { 0.89, 9.3, 7, 6.23 };
    std::vector&lt;double&gt; v(array, array + size(array));
    std::valarray&lt;double&gt; w(array, size(array));
    print(v); // #1
    std::cout &lt;&lt; std::endl;
    print(w); // #2
    std::cout &lt;&lt; std::endl;
    }
</pre>

<p>While the call numbered #1 succeeds, the call numbered #2 fails
because the const version of the member function
valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
const-reference. That seems to be so for no apparent reason, no
benefit. Not only does that defeats users' expectation but it also
does hinder existing software (written either in C or Fortran)
integration within programs written in C++.  There is no reason why
subscripting an expression of type valarray&lt;T&gt; that is const-qualified
should not return a const T&amp;.</p>


<p><b>Proposed resolution:</b></p>
<p>In the class synopsis in 26.6.2 [template.valarray], and in
26.6.2.3 [valarray.access] just above paragraph 1, change</p>
<pre>  T operator[](size_t const);
</pre>
<p>to</p>
<pre>  const T&amp; operator[](size_t const);
</pre>

<p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
  wehre it belongs.]</i></p>




<p><b>Rationale:</b></p>
<p>Return by value seems to serve no purpose.  Valaray was explicitly
designed to have a specified layout so that it could easily be
integrated with libraries in other languages, and return by value
defeats that purpose.  It is believed that this change will have no
impact on allowable optimizations.</p>





<hr>
<h3><a name="391"></a>391. non-member functions specified as const</h3>
<p><b>Section:</b> 22.3.3.2 [conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> James Kanze <b>Opened:</b> 2002-12-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specifications of toupper and tolower both specify the functions as
const, althought they are not member functions, and are not specified as
const in the header file synopsis in section 22.3 [locales].
</p>


<p><b>Proposed resolution:</b></p>
<p>In 22.3.3.2 [conversions], remove <tt>const</tt> from the function
  declarations of std::toupper and std::tolower</p>


<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>




<hr>
<h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> James Kanze <b>Opened:</b> 2003-01-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 26.8 [c.math], the C++ standard refers to the C standard for the
definition of rand(); in the C standard, it is written that "The
implementation shall behave as if no library function calls the rand
function."
</p>

<p>
In 25.3.12 [alg.random.shuffle], there is no specification as to
how the two parameter version of the function generates its random
value.  I believe that all current implementations in fact call rand()
(in contradiction with the requirement avove); if an implementation does
not call rand(), there is the question of how whatever random generator
it does use is seeded.  Something is missing.
</p>



<p><b>Proposed resolution:</b></p>
<p>
In [lib.c.math], add a paragraph specifying that the C definition of
rand shal be modified to say that "Unless otherwise specified, the
implementation shall behave as if no library function calls the rand
function."
</p>

<p>
In [lib.alg.random.shuffle], add a sentence to the effect that "In
the two argument form of the function, the underlying source of
random numbers is implementation defined. [Note: in particular, an
implementation is permitted to use <tt>rand</tt>.]
</p>


<p><b>Rationale:</b></p>
<p>The original proposed resolution proposed requiring the
  two-argument from of <tt>random_shuffle</tt> to
  use <tt>rand</tt>. We don't want to do that, because some existing
  implementations already use something else: gcc
  uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
  problem if the number of elements in the sequence is greater than
  RAND_MAX.</p> 





<hr>
<h3><a name="396"></a>396. what are characters zero and one</h3>
<p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
    <p>
23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
having the value of 0 or 1 but there is no definition of what
that means for charT other than char and wchar_t. And even for
those two types, the values 0 and 1 are not actually what is
intended -- the values '0' and '1' are. This, along with the
converse problem in the description of to_string() in 23.3.5.2,
p33, looks like a defect remotely related to DR 303.
    </p>
    <p>
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
    </p>
    <pre>23.3.5.1:
  -6-  An element of the constructed string has value zero if the
       corresponding character in str, beginning at position pos,
       is 0. Otherwise, the element has the value one.
    </pre>
    <pre>23.3.5.2:
  -33-  Effects: Constructs a string object of the appropriate
        type and initializes it to a string of length N characters.
        Each character is determined by the value of its
        corresponding bit position in *this. Character position N
        ?- 1 corresponds to bit position zero. Subsequent decreasing
        character positions correspond to increasing bit positions.
        Bit value zero becomes the character 0, bit value one becomes
        the character 1.
    </pre>
    <p>
Also note the typo in 23.3.5.1, p6: the object under construction
is a bitset, not a string.
    </p>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>) previously resolved at this meeting.
</p>
<p>
Disposition: move to ready.
</p>
<p>
We request that Howard submit a separate issue regarding the three to_string overloads.
</p>
</blockquote>

  

<p><b>Proposed resolution:</b></p>
<p>Change the constructor's function declaration immediately before 
20.5.1 [bitset.cons] p3 to:</p>
<pre>    template &lt;class charT, class traits, class Allocator&gt;
    explicit
    bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
           typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
           typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
             basic_string&lt;charT, traits, Allocator&gt;::npos,
           charT zero = charT('0'), charT one = charT('1'))
</pre>
<p>Change the first two sentences of 20.5.1 [bitset.cons] p6 to: "An
element of the constructed string has value 0 if the corresponding
character in <i>str</i>, beginning at position <i>pos</i>,
is <i>zero</i>. Otherwise, the element has the value 1.</p>

<p>Change the text of the second sentence in 23.3.5.1, p5 to read:
    "The function then throws invalid_argument if any of the rlen
    characters in str beginning at position pos is other than <i>zero</i>
    or <i>one</i>. The function uses traits::eq() to compare the character
    values."
</p>

<p>Change the declaration of the <tt>to_string</tt> member function
  immediately before 20.5.2 [bitset.members] p33 to:</p>
<pre>    template &lt;class charT, class traits, class Allocator&gt;
    basic_string&lt;charT, traits, Allocator&gt; 
    to_string(charT zero = charT('0'), charT one = charT('1')) const;
</pre>
<p>Change the last sentence of 20.5.2 [bitset.members] p33 to: "Bit
  value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
  character <tt><i>one</i></tt>.</p>
<p>Change 20.5.4 [bitset.operators] p8 to:</p>
<p><b>Returns</b>:</p> 
<pre>  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
      use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
      use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
</pre>


<p><b>Rationale:</b></p>
<p>There is a real problem here: we need the character values of '0'
  and '1', and we have no way to get them since strings don't have
  imbued locales. In principle the "right" solution would be to
  provide an extra object, either a ctype facet or a full locale,
  which would be used to widen '0' and '1'. However, there was some
  discomfort about using such a heavyweight mechanism.  The proposed
  resolution allows those users who care about this issue to get it
  right.</p>
<p>We fix the inserter to use the new arguments.  Note that we already
  fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>



<p><i>[
post Bellevue:
]</i></p>


<blockquote>
We are happy with the resolution as proposed, and we move this to Ready.
</blockquote>

<p><i>[
Howard adds:
]</i></p>


<blockquote>
The proposed wording neglects the 3 newer to_string overloads.
</blockquote>




<hr>
<h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
<p><b>Section:</b> 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.9.5.1 [allocator.members] allocator members, contains
the following 3 lines:
</p>

<pre>  12 Returns: new((void *) p) T( val)
     void destroy(pointer p);
  13 Returns: ((T*) p)-&gt;~T()
</pre>

<p>
The type cast "(T*) p" in the last line is redundant cause
we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Replace "((T*) p)" with "p".
</p>


<p><b>Rationale:</b></p><p>Just a typo, this is really editorial.</p>




<hr>
<h3><a name="401"></a>401.  incorrect type casts in table 32 in lib.allocator.requirements</h3>
<p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I think that in par2 of  [default.con.req] the last two
lines of table 32 contain two incorrect type casts. The lines are ...
</p>

<pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
  a.destroy(p)       Effect: ((T*)p)?-&gt;~T()
</pre>

<p>
.... with the prerequisits coming from the preceding two paragraphs, especially
from table 31:
</p>

<pre>  alloc&lt;T&gt;             a     ;// an allocator for T
  alloc&lt;T&gt;::pointer    p     ;// random access iterator
                              // (may be different from T*)
  alloc&lt;T&gt;::reference  r = *p;// T&amp;
  T const&amp;             t     ;
</pre>

<p>
For that two type casts ("(void*)p" and "(T*)p") to be well-formed
this would require then conversions to T* and void* for all
alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
requirements for alloc&lt;T&gt;::pointer, additionally to the only
current requirement (being a random access iterator).
</p>


<p><b>Proposed resolution:</b></p>

<p>
Accept proposed wording from
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 1.
</p>

<p>
Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
"p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
</p>

<p><i>[Kona: The LWG thinks this is somewhere on the border between
  Open and NAD.  The intend is clear: <tt>construct</tt> constructs an
  object at the location <i>p</i>.  It's reading too much into the
  description to think that literally calling <tt>new</tt> is
  required.  Tweaking this description is low priority until we can do
  a thorough review of allocators, and, in particular, allocators with
  non-default pointer types.]</i></p>


<p><i>[
Batavia:  Proposed resolution changed to less code and more description.
]</i></p>


<p><i>[
post Oxford:  This would be rendered NAD Editorial by acceptance of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
]</i></p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
was subsequently split out into a separate paper N2436 for the purposes of voting.
The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
issue to Ready status to be voted into the WP at Kona.
]</i></p>







<hr>
<h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
<p><b>Section:</b> 20.2.5 [allocator.requirements], 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This applies to the new expression that is contained in both par12 of
20.9.5.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
I think this new expression is wrong, involving unintended side
effects.
</p>


<p>20.9.5.1 [allocator.members]  contains the following 3 lines:</p>

<pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
     void construct(pointer p, const_reference val);
  12 Returns: new((void *) p) T( val)
</pre>


<p> [default.con.req] in table 32 has the following line:</p>
<pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
</pre>

<p>
.... with the prerequisits coming from the preceding two paragraphs,
especially from table 31:
</p>

<pre>  alloc&lt;T&gt;             a     ;// an allocator for T
  alloc&lt;T&gt;::pointer    p     ;// random access iterator
                              // (may be different from T*)
  alloc&lt;T&gt;::reference  r = *p;// T&amp;
  T const&amp;             t     ;
</pre>

<p>
Cause of using "new" but not "::new", any existing "T::operator new"
function will hide the global placement new function. When there is no
"T::operator new" with adequate signature,
every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
would be adding placement new and delete functions with adequate
signature and semantic to class T, but class T might come from another
party. Maybe even worse is the case when T has placement new and
delete functions with adequate signature but with "unknown" semantic:
I dont like to speculate about it, but whoever implements
any_container&lt;T,any_alloc&gt; and wants to use construct(..)
probably must think about it.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Replace "new" with "::new" in both cases.
</p>







<hr>
<h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3>
<p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2003-03-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>
std::basic_string, 21.4 [basic.string] paragraph 2 says that
basic_string "conforms to the requirements of a Sequence, as specified
in (23.1.1)." The sequence requirements specified in (23.1.1) to not
include any prohibition on swap members throwing exceptions.
</p>

<p>
Section 23.2 [container.requirements] paragraph 10 does limit conditions under
which exceptions may be thrown, but applies only to "all container
types defined in this clause" and so excludes basic_string::swap
because it is defined elsewhere.
</p>

<p>
Eric Niebler points out that 21.4 [basic.string] paragraph 5 explicitly
permits basic_string::swap to invalidates iterators, which is
disallowed by 23.2 [container.requirements] paragraph 10. Thus the standard would
be contradictory if it were read or extended to read as having
basic_string meet 23.2 [container.requirements] paragraph 10 requirements.
</p>

<p>
Yet several LWG members have expressed the belief that the original
intent was that basic_string::swap should not throw exceptions as
specified by 23.2 [container.requirements] paragraph 10, and that the standard is
unclear on this issue. The complexity of basic_string::swap is
specified as "constant time", indicating the intent was to avoid
copying (which could cause a bad_alloc or other exception). An
important use of swap is to ensure that exceptions are not thrown in
exception-safe code.
</p>

<p>
Note: There remains long standing concern over whether or not it is
possible to reasonably meet the 23.2 [container.requirements] paragraph 10 swap
requirements when allocators are unequal. The specification of
basic_string::swap exception requirements is in no way intended to
address, prejudice, or otherwise impact that concern.
</p>







<p><b>Proposed resolution:</b></p>
<p>
In 21.4.6.8 [string::swap], add a throws clause:
</p>

<p>
Throws: Shall not throw exceptions.
</p>





<hr>
<h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
<p><b>Section:</b> 17.6.3.6 [replacement.functions], 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-04-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The eight basic dynamic memory allocation functions (single-object
and array versions of ::operator new and ::operator delete, in the
ordinary and nothrow forms) are replaceable.  A C++ program may
provide an alternative definition for any of them, which will be used
in preference to the implementation's definition.  
</p>

<p>
Three different parts of the standard mention requirements on
replacement functions: 17.6.3.6 [replacement.functions], 18.6.1.1 [new.delete.single]
and 18.6.1.2 [new.delete.array], and 3.7.3 [basic.stc.auto].
</p>

<p>None of these three places say whether a replacement function may
  be declared inline.  18.6.1.1 [new.delete.single] paragraph 2 specifies a
  signature for the replacement function, but that's not enough:
  the <tt>inline</tt> specifier is not part of a function's signature.
  One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
  requires that "an inline function shall be defined in every
  translation unit in which it is used," but this may not be quite
  specific enough either.  We should either explicitly allow or
  explicitly forbid inline replacement memory allocation
  functions.</p>


<p><b>Proposed resolution:</b></p>
<p>
Add a new sentence to the end of 17.6.3.6 [replacement.functions] paragraph 3:
"The program's definitions shall not be specified as <tt>inline</tt>.
No diagnostic is required."
</p>

<p><i>[Kona: added "no diagnostic is required"]</i></p>




<p><b>Rationale:</b></p>
<p>
The fact that <tt>inline</tt> isn't mentioned appears to have been
nothing more than an oversight.  Existing implementations do not
permit inline functions as replacement memory allocation functions.
Providing this functionality would be difficult in some cases, and is
believed to be of limited value.
</p>





<hr>
<h3><a name="405"></a>405. qsort and POD</h3>
<p><b>Section:</b> 25.5 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2003-04-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 25.5 [alg.c.library] describes bsearch and qsort, from the C
standard library. Paragraph 4 does not list any restrictions on qsort,
but it should limit the base parameter to point to POD.  Presumably,
qsort sorts the array by copying bytes, which requires POD.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 25.5 [alg.c.library] paragraph 4, just after the declarations and
before the nonnormative note, add these words: "both of which have the
same behavior as the original declaration.  The behavior is undefined
unless the objects in the array pointed to by <i>base</i> are of POD
type."
</p>

<p><i>[Something along these lines is clearly necessary.  Matt
  provided wording.]</i></p>






<hr>
<h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
<p><b>Section:</b> 23.4.1.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-04-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is a possible defect in the standard: the standard text was
never intended to prevent arbitrary ForwardIterators, whose operations
may throw exceptions, from being passed, and it also wasn't intended
to require a temporary buffer in the case where ForwardIterators were
passed (and I think most implementations don't use one).  As is, the
standard appears to impose requirements that aren't met by any
existing implementation.
</p>


<p><b>Proposed resolution:</b></p>
<p>Replace 23.4.1.4 [vector.modifiers] paragraph 1 with:</p>
<blockquote><p>
  1- Notes: Causes reallocation if the new size is greater than the
  old capacity. If no reallocation happens, all the iterators and
  references before the insertion point remain valid. If an exception
  is thrown other than by the copy constructor or assignment operator
  of T or by any InputIterator operation there are no effects.
</p></blockquote>

<p><i>[We probably need to say something similar for deque.]</i></p>







<hr>
<h3><a name="407"></a>407. Can singular iterators be destroyed?</h3>
<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Clause X [iterator.concepts], paragraph 5, says that the only expression
that is defined for a singular iterator is "an assignment of a
non-singular value to an iterator that holds a singular value".  This 
means that destroying a singular iterator (e.g. letting an automatic
variable go out of scope) is technically undefined behavior.  This
seems overly strict, and probably unintentional.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the sentence in question to "... the only exceptions are
destroying an iterator that holds a singular value, or the assignment
of a non-singular value to an iterator that holds a singular value."
</p>





<hr>
<h3><a name="409"></a>409. Closing an fstream should clear error state</h3>
<p><b>Section:</b> 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A strict reading of 27.9.1 [fstreams] shows that opening or
closing a basic_[io]fstream does not affect the error bits.  This
means, for example, that if you read through a file up to EOF, and
then close the stream and reopen it at the beginning of the file,
the EOF bit in the stream's error state is still set.  This is
counterintuitive.
</p>
<p>
The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>,
and put in a footnote to clarify that the strict reading was indeed
correct.  We did that because we believed the standard was
unambiguous and consistent, and that we should not make architectural
changes in a TC.  Now that we're working on a new revision of the
language, those considerations no longer apply.
</p>


<p><b>Proposed resolution:</b></p>

<p>Change 27.9.1.9 [ifstream.members], para. 3 from:</p>

<blockquote><p>
Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)].
</p></blockquote>

<p>to:</p>

<blockquote><p>
Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
</p></blockquote>

<p>Change 27.9.1.13 [ofstream.members], para. 3 from:</p>

<blockquote><p>
Calls rdbuf()-&gt;open(s,mode|out). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)).
</p></blockquote>

<p>to:</p>

<blockquote><p>
Calls rdbuf()-&gt;open(s,mode|out). If that function returns a null pointer, calls setstate(failbit) (which may throw ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
</p></blockquote>

<p>Change 27.9.1.17 [fstream.members], para. 3 from:</p>

<blockquote><p>
Calls rdbuf()-&gt;open(s,mode), If that function returns a null pointer, calls setstate(failbit), (which may throw ios_base::failure). (lib.iostate.flags) )
</p></blockquote>

<p>to:</p>

<blockquote><p>
Calls rdbuf()-&gt;open(s,mode), If that function returns a null pointer, calls setstate(failbit), (which may throw ios_base::failure). (lib.iostate.flags) ), else calls clear().
</p></blockquote>



<p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
provided wording.  He suggests having open, not close, clear the error
flags.]</i></p>


<p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
  old one didn't make sense because it proposed to fix this at the
  level of basic_filebuf, which doesn't have access to the stream's
  error state.  Howard's proposed resolution fixes this at the level
  of the three fstream class template instead.]</i></p>








<hr>
<h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
<p><b>Section:</b> 23.3.4.1 [list.cons], 23.3.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Hans Bos <b>Opened:</b> 2003-06-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Sections 23.3.4.1 [list.cons] and 23.3.4.3 [list.modifiers] list
comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
stack.  Only the semantics for queue::operator== (23.3.4.1 [list.cons] par2) and queue::operator&lt; (23.3.4.1 [list.cons]
par3) are defined.
</p>


<p><b>Proposed resolution:</b></p>

<p>Add the following new paragraphs after 23.3.4.1 [list.cons]
  paragraph 3:</p>

<blockquote>

<pre>  operator!=
</pre>
<p>Returns: <tt>x.c != y.c</tt></p>

<pre>  operator&gt;
</pre>
<p>Returns: <tt>x.c &gt; y.c</tt></p>

<pre>  operator&lt;=
</pre>
<p>Returns: <tt>x.c &lt;= y.c</tt></p>

<pre>  operator&gt;=
</pre>
<p>Returns: <tt>x.c &gt;= y.c</tt></p>

</blockquote>

<p>Add the following paragraphs at the end of 23.3.4.3 [list.modifiers]:</p>

<blockquote>

<pre>  operator==
</pre>
<p>Returns: <tt>x.c == y.c</tt></p>

<pre>  operator&lt;
</pre>
<p>Returns: <tt>x.c &lt; y.c</tt></p>

<pre>  operator!=
</pre>
<p>Returns: <tt>x.c != y.c</tt></p>

<pre>  operator&gt;
</pre>
<p>Returns: <tt>x.c &gt; y.c</tt></p>

<pre>  operator&lt;=
</pre>
<p>Returns: <tt>x.c &lt;= y.c</tt></p>

<pre>  operator&gt;=
</pre>
<p>Returns: <tt>x.c &gt;= y.c</tt></p>

</blockquote>


<p><i>[Kona: Matt provided wording.]</i></p>




<p><b>Rationale:</b></p>
<p>There isn't any real doubt about what these operators are
supposed to do, but we ought to spell it out.</p>





<hr>
<h3><a name="411"></a>411. Wrong names of set member functions</h3>
<p><b>Section:</b> 25.4.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2003-07-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
25.4.5 [alg.set.operations] paragraph 1 reads:
"The semantics of the set operations are generalized to multisets in a 
standard way by defining union() to contain the maximum number of 
occurrences of every element, intersection() to contain the minimum, and 
so on."
</p>

<p>
This is wrong.  The name of the functions are set_union() and
set_intersection(), not union() and intersection().
</p>


<p><b>Proposed resolution:</b></p>
<p>Change that sentence to use the correct names.</p>





<hr>
<h3><a name="412"></a>412. Typo in 27.4.4.3</h3>
<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-07-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p>
<p><b>Discussion:</b></p>
<p>
The Effects clause in 27.5.4.3 [iostate.flags] paragraph 5 says that the
function only throws if the respective bits are already set prior to
the function call. That's obviously not the intent. The typo ought to
be corrected and the text reworded as: "If (<i>state</i> &amp;
exceptions()) == 0, returns. ..."
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 27.5.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &amp;
exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
&amp; exceptions()) == 0".
</p>

<p><i>[Kona: the original proposed resolution wasn't quite right.  We
  really do mean rdstate(); the ambiguity is that the wording in the
  standard doesn't make it clear whether we mean rdstate() before
  setting the new state, or rdsate() after setting it.  We intend the
  latter, of course. Post-Kona: Martin provided wording.]</i></p>







<hr>
<h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3>
<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2003-07-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The second sentence of the proposed resolution says:
</p>

<p>
"If it inserted no characters because it caught an exception thrown
while extracting characters from sb and ..."
</p>

<p>
However, we are not extracting from sb, but extracting from the
basic_istream (*this) and inserting into sb. I can't really tell if
"extracting" or "sb" is a typo.
</p>

<p><i>[
Sydney: Definitely a real issue. We are, indeed, extracting characters
from an istream and not from sb. The problem was there in the FDIS and
wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was
to have *this instead of sb. We're talking about the exception flag
state of a basic_istream object, and there's only one basic_istream
object in this discussion, so that would be a consistent
interpretation.  (But we need to be careful: the exception policy of
this member function must be consistent with that of other
extractors.)  PJP will provide wording.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>Change the sentence from:</p>

<blockquote><p>
If it inserted no characters because it caught an exception thrown
while extracting characters from sb and failbit is on in exceptions(),
then the caught exception is rethrown.
</p></blockquote>

<p>to:</p>

<blockquote><p>
If it inserted no characters because it caught an exception thrown
while extracting characters from *this and failbit is on in exceptions(),
then the caught exception is rethrown.
</p></blockquote>





<hr>
<h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
<p><b>Section:</b> 23.4.1.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-08-19 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following code fragment:
</p>
<blockquote>
<pre>int A[8] = { 1,3,5,7,9,8,4,2 };
std::vector&lt;int&gt; v(A, A+8);

std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
v.erase(i1);
</pre>
</blockquote>

<p>
Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
both, or neither?
</p>

<p>
On all existing implementations that I know of, the status of i1 and
i2 is the same: both of them will be iterators that point to some
elements of the vector (albeit not the same elements they did
before).  You won't get a crash if you use them.  Depending on 
exactly what you mean by "invalidate", you might say that neither one
has been invalidated because they still point to <i>something</i>,
or you might say that both have been invalidated because in both
cases the elements they point to have been changed out from under the
iterator.
</p>

<p>
The standard doesn't say either of those things.  It says that erase
invalidates all iterators and references "after the point of the
erase".  This doesn't include i1, since it's at the point of the
erase instead of after it.  I can't think of any sensible definition
of invalidation by which one can say that i2 is invalidated but i1
isn't.
</p>

<p>
(This issue is important if you try to reason about iterator validity
based only on the guarantees in the standard, rather than reasoning
from typical implementation techniques.  Strict debugging modes,
which some programmers find useful, do not use typical implementation
techniques.)
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 23.4.1.4 [vector.modifiers] paragraph 3, change "Invalidates all the
iterators and references after the point of the erase" to
"Invalidates iterators and references at or after the point of the
erase". 
</p>


<p><b>Rationale:</b></p>
<p>I believe this was essentially a typographical error, and that it
  was taken for granted that erasing an element invalidates iterators
  that point to it.  The effects clause in question treats iterators
  and references in parallel, and it would seem counterintuitive to
  say that a reference to an erased value remains valid.</p>





<hr>
<h3><a name="415"></a>415. behavior of std::ws</h3>
<p><b>Section:</b> 27.7.1.4 [istream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to 27.6.1.4, the ws() manipulator is not required to construct
the sentry object. The manipulator is also not a member function so the
text in 27.6.1, p1 through 4 that describes the exception policy for
istream member functions does not apply. That seems inconsistent with
the rest of extractors and all the other input functions (i.e., ws will
not cause a tied stream to be flushed before extraction, it doesn't check
the stream's exceptions or catch exceptions thrown during input, and it
doesn't affect the stream's gcount).
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add to 27.7.1.4 [istream.manip], immediately before the first sentence
of paragraph 1, the following text:
</p>

    <blockquote><p>
    Behaves as an unformatted input function (as described in
    27.6.1.3, paragraph 1), except that it does not count the number
    of characters extracted and does not affect the value returned by
    subsequent calls to is.gcount(). After constructing a sentry
    object...  
    </p></blockquote>

<p><i>[Post-Kona: Martin provided wording]</i></p>






<hr>
<h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3>
<p><b>Section:</b> 18.3.2 [c.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

Given two overloads of the function foo(), one taking an argument of type
int and the other taking a long, which one will the call foo(LONG_MAX)
resolve to? The expected answer should be foo(long), but whether that
is true depends on the #defintion of the LONG_MAX macro, specifically
its type. This issue is about the fact that the type of these macros
is not actually required to be the same as the the type each respective
limit.
<br>

Section 18.2.2 of the C++ Standard does not specify the exact types of
the XXX_MIN and XXX_MAX macros #defined in the &lt;climits&gt; and &lt;limits.h&gt;
headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
<br>

Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
these constants] shall be replaced by constant expressions suitable for use
in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
the following shall be replaced by expressions that have the same type as
would an expression that is an object of the corresponding type converted
according to the integer promotions."
<br>

The "corresponding type converted according to the integer promotions" for
LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
converted to the first of the following set of types that can represent it:
int, long int, long long int. So on an implementation where (sizeof(long)
== sizeof(int)) this type is actually int, while on an implementation where
(sizeof(long) &gt; sizeof(int)) holds this type will be long.
<br>

This is not an issue in C since the type of the macro cannot be detected
by any conforming C program, but it presents a portability problem in C++
where the actual type is easily detectable by overload resolution.

        </p>
<p><i>[Kona: the LWG does not believe this is a defect.  The C macro
  definitions are what they are; we've got a better
  mechanism, <tt>std::numeric_limits</tt>, that is specified more
  precisely than the C limit macros.  At most we should add a
  nonnormative note recommending that users who care about the exact
  types of limit quantities should use &lt;limits&gt; instead of
  &lt;climits&gt;.]</i></p>


    

<p><b>Proposed resolution:</b></p>

<p>
Change 18.3.2 [c.limits], paragraph 2:
</p>

<blockquote><p>
-2- The contents are the same as the Standard C library header <tt>&lt;limits.h&gt;</tt>.
<ins>[<i>Note:</i> The types of the macros in <tt>&lt;climits&gt;</tt> are not guaranteed
to match the type to which they refer.<i>--end note</i>]</ins>
</p></blockquote>





<hr>
<h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
<p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

27.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then
says that a formatted input function endeavors to obtain the requested input
if the sentry's operator bool() returns true.

Given these requirements, no formatted extractor should ever set failbit if
the initial stream rdstate() == eofbit. That is contrary to the behavior of
all implementations I tested. The program below prints out

eof = 1, fail = 0
eof = 1, fail = 1

on all of them.
        </p>
<pre>
#include &lt;sstream&gt;
#include &lt;cstdio&gt;

int main()
{
    std::istringstream strm ("1");

    int i = 0;

    strm &gt;&gt; i;

    std::printf ("eof = %d, fail = %d\n",
                 !!strm.eof (), !!strm.fail ());

    strm &gt;&gt; i;

    std::printf ("eof = %d, fail = %d\n",
                 !!strm.eof (), !!strm.fail ());
}

</pre>
        <p>
<br>

Comments from Jerry Schwarz (c++std-lib-11373):
<br>

Jerry Schwarz wrote:
<br>

I don't know where (if anywhere) it says it in the standard, but the
formatted extractors are supposed to set failbit if they don't extract
any characters. If they didn't then simple loops like
<br>

while (cin &gt;&gt; x);
<br>

would loop forever.
<br>

Further comments from Martin Sebor:
<br>

The question is which part of the extraction should prevent this from happening
by setting failbit when eofbit is already set. It could either be the sentry
object or the extractor. It seems that most implementations have chosen to
set failbit in the sentry [...] so that's the text that will need to be
corrected. 

        </p>
<p>
Pre Berlin:  This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>.  If the sentry
sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
you can never seek away from the end of stream.
</p>
<p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
  then set <i>ok</i> to false.  We believe that the sentry's
  constructor should always set failbit when <i>ok</i> is false, and
  we also think the standard already says that.  Possibly it could be
  clearer.</p> 


<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 27.7.1.1.3 [istream::sentry], p2 to:
</p>

<blockquote>
<pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
<p>
-2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
<ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>. 
Otherwise</ins> prepares for formatted or unformatted input. ...
</p>
</blockquote>






<hr>
<h3><a name="420"></a>420. is std::FILE a complete type?</h3>
<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
7.19.1, p2, of C99 requires that the FILE type only be declared in
&lt;stdio.h&gt;.  None of the (implementation-defined) members of the
struct is mentioned anywhere for obvious reasons.
</p>

<p>
C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
it really the intent that FILE be a complete type or is an implementation
allowed to just declare it without providing a full definition?
</p>


<p><b>Proposed resolution:</b></p>
<p>In the first sentence of 27.9.1 [fstreams] paragraph 2, change
  "defined" to "declared".</p>


<p><b>Rationale:</b></p>
<p>We don't want to impose any restrictions beyond what the C standard
  already says. We don't want to make anything implementation defined,
  because that imposes new requirements in implementations.</p>





<hr>
<h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
<p><b>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It has been suggested that 17.4.3.1, p1 may or may not allow programs to
explicitly specialize members of standard templates on user-defined types.
The answer to the question might have an impact where library requirements
are given using the "as if" rule. I.e., if programs are allowed to specialize
member functions they will be able to detect an implementation's strict
conformance to Effects clauses that describe the behavior of the function
in terms of the other member function (the one explicitly specialized by
the program) by relying on the "as if" rule.
</p>


<p><b>Proposed resolution:</b></p>

<p>
  Add the following sentence to 17.6.3.3 [reserved.names], p1:
</p>

<blockquote><p>
It is undefined for a C++ program to add declarations or definitions to
namespace std or namespaces within namespace <tt>std</tt> unless otherwise specified. A
program may add template specializations for any standard library template to
namespace <tt>std</tt>. Such a specialization (complete or partial) of a standard library
template results in undefined behavior unless the declaration depends on a
user-defined type of external linkage and unless the specialization meets the
standard library requirements for the original template.<sup>168)</sup>
<ins>A program has undefined behavior if it declares</ins>
</p>
<ul>
<li><ins>an explicit specialization of any member function of a standard
            library class template, or</ins></li>
<li><ins>an explicit specialization of any member function template of a
            standard library class or class template, or</ins></li>
<li><ins>an explicit or partial specialization of any member class
            template of a standard library class or class template.</ins></li>
</ul>
<p>
A program may explicitly instantiate any templates in the standard library only
if the declaration depends on the name of a user-defined type of external
linkage and the instantiation meets the standard library requirements for the
original template.
</p></blockquote>

<p><i>[Kona: straw poll was 6-1 that user programs should not be
  allowed to specialize individual member functions of standard
  library class templates, and that doing so invokes undefined
  behavior. Post-Kona: Martin provided wording.]</i></p>


<p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
to specialize individual member functions unless they specialize the
whole class, but we're not sure these words say what we want them to;
they could be read as prohibiting the specialization of any standard
library class templates. We need to consult with CWG to make sure we
use the right wording.]</i></p>






<hr>
<h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
<p><b>Section:</b> 20.9.7 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard is not clear about the requirements on the value returned from
a call to get_temporary_buffer(0). In particular, it fails to specify whether
the call should return a distinct pointer each time it is called (like
operator new), or whether the value is unspecified (as if returned by
malloc). The standard also fails to mention what the required behavior
is when the argument is less than 0.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 20.7.3 [meta.help] paragraph 2 from "...or a pair of 0
values if no storage can be obtained" to "...or a pair of 0 values if
no storage can be obtained or if <i>n</i> &lt;= 0."</p>
<p><i>[Kona: Matt provided wording]</i></p>





<hr>
<h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
<p><b>Section:</b> 25.2.13 [alg.search], 25.3.6 [alg.fill], 25.3.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The complexity requirements for these function templates are incorrect
(or don't even make sense) for negative n:</p>

<p>25.1.9, p7 (search_n):
<br>
Complexity: At most (last1 - first1) * count applications
of the corresponding predicate.</p>

<p>25.2.5, p3 (fill_n):
<br>
Complexity: Exactly last - first (or n) assignments.</p>

<p>25.2.6, p3 (generate_n):
<br>
Complexity: Exactly last - first (or n) assignments.</p>

<p>
In addition, the Requirements or the Effects clauses for the latter two
templates don't say anything about the behavior when n is negative.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 25.1.9, p7 to</p>

<blockquote><p>
Complexity: At most (last1 - first1) * count applications
of the corresponding predicate if count is positive,
or 0 otherwise.
</p></blockquote>

<p>Change 25.2.5, p2 to</p>
<blockquote><p>
Effects: Assigns value through all the iterators in the range [first,
last), or [first, first + n) if n is positive, none otherwise.
</p></blockquote>

<p>Change 25.2.5, p3 to:</p>
<blockquote><p>
Complexity: Exactly last - first (or n if n is positive,
or 0 otherwise) assignments.
</p></blockquote>

<p>
Change 25.2.6, p1 
to (notice the correction for the misspelled "through"):
</p>
<blockquote><p>
Effects: Invokes the function object genand assigns the return
value of gen through all the iterators in the range [first, last),
or [first, first + n) if n is positive, or [first, first)
otherwise.
</p></blockquote>

<p>Change 25.2.6, p3 to:</p>
<blockquote><p>
Complexity: Exactly last - first (or n if n is positive,
or 0 otherwise) assignments.
</p></blockquote>


<p><b>Rationale:</b></p>
<p>Informally, we want to say that whenever we see a negative number
  we treat it the same as if it were zero.  We believe the above
  changes do that (although they may not be the minimal way of saying
  so).  The LWG considered and rejected the alternative of saying that
  negative numbers are undefined behavior.</p>





<hr>
<h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements specified in Stage 2 and reiterated in the rationale
of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
do_get() compares characters on the stream against the widened elements
of "012...abc...ABCX+-"
</p>

<p>
An implementation is required to allow programs to instantiate the num_get
template on any charT that satisfies the requirements on a user-defined
character type. These requirements do not include the ability of the
character type to be equality comparable (the char_traits template must
be used to perform tests for equality). Hence, the num_get template cannot
be implemented to support any arbitrary character type. The num_get template
must either make the assumption that the character type is equality-comparable
(as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
the comparisons (some other popular implementations do that). This diversity
of approaches makes it difficult to write portable programs that attempt to
instantiate the num_get template on user-defined types.
</p>

<p><i>[Kona: the heart of the problem is that we're theoretically
  supposed to use traits classes for all fundamental character
  operations like assignment and comparison, but facets don't have
  traits parameters.  This is a fundamental design flaw and it
  appears all over the place, not just in this one place.  It's not
  clear what the correct solution is, but a thorough review of facets
  and traits is in order.  The LWG considered and rejected the
  possibility of changing numeric facets to use narrowing instead of
  widening.  This may be a good idea for other reasons (see issue
  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#459">459</a>), but it doesn't solve the problem raised by this
  issue.  Whether we use widen or narrow the <tt>num_get</tt> facet
  still has no idea which traits class the user wants to use for 
  the comparison, because only streams, not facets, are passed traits
  classes.   The standard does not require that two different
  traits classes with the same <tt>char_type</tt> must necessarily 
  have the same behavior.]</i></p>


<p>Informally, one possibility: require that some of the basic
character operations, such as <tt>eq</tt>, <tt>lt</tt>,
and <tt>assign</tt>, must behave the same way for all traits classes
with the same <tt>char_type</tt>.  If we accept that limitation on
traits classes, then the facet could reasonably be required to
use <tt>char_traits&lt;charT&gt;</tt>.</p>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
There was general agreement that the standard only needs to specify the
behavior when the character type is char or wchar_t.
</p>
<p>
Beman: we don't need to worry about C++1x because there is a non-zero
possibility that we would have a replacement facility for iostreams that
would solve these problems.
</p>
<p>
We need to change the following sentence in [locale.category], paragraph
6 to specify that C is char and wchar_t:
</p>
<p>
"A template formal parameter with name C represents the set of all
possible specializations on a parameter that satisfies the requirements
for a character on which any member of the iostream components can be
instantiated."
</p>
<p>
We also need to specify in 27 that the basic character operations, such
as eq, lt, and assign use std::char_traits.
</p>
<p>
Daniel volunteered to provide wording.
</p>
</blockquote>

<p><i>[
2009-09-19 Daniel provided wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as Open. Alisdair and/or Tom will provide wording based on discussions.
We want to clearly state that streams and locales work just on <tt>char</tt>
and <tt>wchar_t</tt> (except where otherwise specified).
</blockquote>

<p><i>[
2010-02-06 Tom updated the proposed wording.
]</i></p>


<blockquote>
<p><i>[
The original proposed wording is preserved here:
]</i></p>


<blockquote class="note">
<ol>
<li>
<p>
Change 22.3.1.1.1 [locale.category]/6:
</p>

<blockquote>
[..] A template formal parameter with name <tt>C</tt> represents the set of all possible
specializations on a <ins><tt>char</tt> or <tt>wchar_t</tt></ins> parameter<del> that satisfies
the requirements for a character on which any of the iostream components
can be instantiated</del>. [..]
</blockquote>
</li>

<li>
<p>
Add the following sentence to the end of 22.4.2 [category.numeric]/2:
</p>

<blockquote>
[..] These specializations refer to [..], and also for the <tt>ctype&lt;&gt;</tt> facet to
perform character classification. <ins>Implementations are encouraged
but not required to use the <tt>char_traits&lt;charT&gt;</tt> functions for all
comparisons and assignments of characters of type <tt>charT</tt> that do
not belong to the set of required specializations.</ins>
</blockquote>
</li>

<li>
<p>
Change 22.4.2.1.2 [facet.num.get.virtuals]/3:
</p>

<blockquote>
<p>
Stage 2: If <tt>in==end</tt> then stage 2 terminates. Otherwise a <tt>charT</tt> is taken
from <tt>in</tt> and local variables are initialized as if by
</p>

<blockquote><pre>char_type ct = *in;
<ins>using tr = char_traits&lt;char_type&gt;;
const char_type* pos = tr::find(atoms, sizeof(src) - 1, ct);</ins>
char c = src[<del>find(atoms, atoms + sizeof(src) - 1, ct) - atoms</del>
             <ins>pos ? pos - atoms : sizeof(src) - 1</ins>];
if (<ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).decimal_point()<ins>)</ins>)
    c = '.';
bool discard =
    <ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).thousands_sep()<ins>)</ins>
    &amp;&amp; use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().length() != 0;
</pre></blockquote>

<p>
where the values <tt>src</tt> and <tt>atoms</tt> are defined as if by: [..]
</p>
</blockquote>

<p>
[Remark of the author: I considered to replace the initialization
"<tt>char_type ct = *in;</tt>"
by the sequence "<tt>char_type ct; tr::assign(ct, *in);</tt>", but decided
against it, because
it is a copy-initialization context, not an assignment]
</p>
</li>

<li>
<p>
Add the following sentence to the end of 22.4.5 [category.time]/1:
</p>

<blockquote>
[..] Their members use [..] , to determine formatting details.
<ins>Implementations are encouraged but not required to use the
<tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
of characters of type <tt>charT</tt> that do
not belong to the set of required specializations.</ins>
</blockquote>
</li>

<li>
<p>
Change 22.4.5.1.1 [locale.time.get.members]/8 bullet 4:
</p>

<ul>
<li>
<del>The next element of <tt>fmt</tt> is equal to <tt>'%'</tt></del> <ins>For the next element <tt>c</tt>
of <tt>fmt char_traits&lt;char_type&gt;::eq(c, use_facet&lt;ctype&lt;char_type&gt;&gt;(f.getloc()).widen('%')) == true</tt></ins>,
[..]
</li>
</ul>
</li>

<li>
<p>
Add the following sentence to the end of 22.4.6 [category.monetary]/2:
</p>

<blockquote>
Their members use [..] to determine formatting details.
<ins>Implementations are encouraged but not required to use the
<tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
of characters of type <tt>charT</tt> that do
not belong to the set of required specializations.</ins>
</blockquote>
</li>

<li>
<p>
Change 22.4.6.1.2 [locale.money.get.virtuals]/4:
</p>

<blockquote>
<p>
[..] The value <tt>units</tt> is produced as if by:
</p>

<blockquote><pre>for (int i = 0; i &lt; n; ++i)
  buf2[i] = src[<ins>char_traits&lt;charT&gt;::</ins>find(atoms, <del>atoms+</del>sizeof(src), buf1[i]) - atoms];
buf2[n] = 0;
sscanf(buf2, "%Lf", &amp;units);
</pre></blockquote>
</blockquote>
</li>

<li>
<p>
Change 22.4.6.2.2 [locale.money.put.virtuals]/1:
</p>

<blockquote>
[..] for character buffers <tt>buf1</tt> and <tt>buf2</tt>. If <ins>for</ins> the first
character <ins><tt>c</tt></ins>
in <tt>digits</tt> or <tt>buf2</tt> <del>is equal to
<tt>ct.widen('-')</tt></del><ins><tt>char_traits&lt;charT&gt;::eq(c,
ct.widen('-')) == true</tt></ins>, [..]
</blockquote>
</li>

<li>
<p>
Add a footnote to the first sentence of 27.7.1.2.2 [istream.formatted.arithmetic]/1:
</p>

<blockquote>
<p>
As in the case of the inserters, these extractors depend on the locale's
<tt>num_get&lt;&gt;</tt> (22.4.2.1) object to perform parsing the input stream
data.<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
Add a footnote to the second sentence of 27.7.2.6.2 [ostream.inserters.arithmetic]/1:
</p>

<blockquote>
<p>
<i>Effects:</i> The classes <tt>num_get&lt;&gt;</tt> and
<tt>num_put&lt;&gt;</tt> handle locale-dependent numeric formatting and
parsing. These inserter functions use the imbued locale value to perform
numeric formatting.<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
Add a footnote after the first sentence of 27.7.4 [ext.manip]/4:
</p>

<blockquote>
<p>
<i>Returns:</i> An object of unspecified type such that if in is an object of type
<tt>basic_istream&lt;charT, traits&gt;</tt> then the expression <tt>in &gt;&gt; get_money(mon, intl)</tt>
behaves as if it called <tt>f(in, mon, intl)</tt>, where the function <tt>f</tt> is defined
as:<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
Add a footnote after the first sentence of 27.7.4 [ext.manip]/5:
</p>

<blockquote>
<p>
<i>Returns:</i> An object of unspecified type such that if <tt>out</tt> is an object of type
<tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt; put_money(mon, intl)</tt>
behaves as a formatted input function that calls <tt>f(out, mon, intl)</tt>, where the
function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
13) Add a footnote after the first sentence of 27.7.4 [ext.manip]/8:
</p>

<blockquote>
<p>
<i>Returns:</i> An object of unspecified type such that if <tt>in</tt> is an
object of type b<tt>asic_istream&lt;charT, traits&gt;</tt> then the expression
<tt>in &gt;&gt;get_time(tmb, fmt)</tt> behaves as if it called <tt>f(in, tmb, fmt)</tt>,
where the function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
Add a footnote after the first sentence of 27.7.4 [ext.manip]/10:
</p>

<blockquote>
<p>
Returns: An object of unspecified type such that if <tt>out</tt> is an object of type
<tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt;put_time(tmb, fmt)</tt>
behaves as if it called <tt>f(out, tmb, fmt)</tt>, where the function <tt>f</tt> is defined
as:<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>
</ol>

</blockquote>
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
<p>
Moved to Ready with only two of the bullets.  The original wording is preserved
here:
</p>

<blockquote class="note">
<ol>
<li>
<p>
Change 22.3.1.1.1 [locale.category]/6:
</p>

<blockquote>
[..] A template formal parameter with name <tt>C</tt> represents 
the set 
<del>of all possible specializations on a</del> 
<ins>of types containing <tt>char</tt>, <tt>wchar_t</tt>,
and any other implementation-defined character type
</ins>
<del> parameter</del>
that satisfies
the requirements for a character on which any of the iostream components
can be instantiated. [..]
</blockquote>
</li>

<li>
<p>
Add the following sentence to the end of 22.4.2 [category.numeric]/2:
</p>

<blockquote>
[..] These specializations refer to [..], and also for the <tt>ctype&lt;&gt;</tt> facet to
perform character classification. <ins>[<i>Note:</i> Implementations are encouraged
but not required to use the <tt>char_traits&lt;charT&gt;</tt> functions for all
comparisons and assignments of characters of type <tt>charT</tt> that do
not belong to the set of required specializations - <i>end note</i>].</ins>
</blockquote>
</li>

<li>
<p>
Change 22.4.2.1.2 [facet.num.get.virtuals]/3:
</p>

<blockquote>
<p>
Stage 2: If <tt>in==end</tt> then stage 2 terminates. Otherwise a <tt>charT</tt> is taken
from <tt>in</tt> and local variables are initialized as if by
</p>

<blockquote><pre>char_type ct = *in;
<ins>using tr = char_traits&lt;char_type&gt;;
const char_type* pos = tr::find(atoms, sizeof(src) - 1, ct);</ins>
char c = src[<del>find(atoms, atoms + sizeof(src) - 1, ct) - atoms</del>
             <ins>pos ? pos - atoms : sizeof(src) - 1</ins>];
if (<ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).decimal_point()<ins>)</ins>)
    c = '.';
bool discard =
    <ins>tr::eq(ct, </ins><del>ct == </del>use_facet&lt;numpunct&lt;charT&gt;(loc).thousands_sep()<ins>)</ins>
    &amp;&amp; use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().length() != 0;
</pre></blockquote>

<p>
where the values <tt>src</tt> and <tt>atoms</tt> are defined as if by: [..]
</p>
</blockquote>

<p>
[Remark of the author: I considered to replace the initialization
"<tt>char_type ct = *in;</tt>"
by the sequence "<tt>char_type ct; tr::assign(ct, *in);</tt>", but decided
against it, because
it is a copy-initialization context, not an assignment]
</p>
</li>

<li>
<p>
Add the following sentence to the end of 22.4.5 [category.time]/1:
</p>

<blockquote>
[..] Their members use [..] , to determine formatting details.
<ins>[<i>Note:</i> Implementations are encouraged but not required to use the
<tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
of characters of type <tt>charT</tt> that do
not belong to the set of required specializations - <i>end note</i>].</ins>
</blockquote>
</li>

<li>
<p>
Change 22.4.5.1.1 [locale.time.get.members]/8 bullet 4:
</p>

<ul>
<li>
<del>The next element of <tt>fmt</tt> is equal to <tt>'%'</tt></del> <ins>For the next element <tt>c</tt>
of <tt>fmt char_traits&lt;char_type&gt;::eq(c, use_facet&lt;ctype&lt;char_type&gt;&gt;(f.getloc()).widen('%')) == true</tt></ins>,
[..]
</li>
</ul>
</li>

<li>
<p>
Add the following sentence to the end of 22.4.6 [category.monetary]/2:
</p>

<blockquote>
Their members use [..] to determine formatting details.
<ins>[<i>Note:</i> Implementations are encouraged but not required to use the
<tt>char_traits&lt;charT&gt;</tt> functions for all comparisons and assignments
of characters of type <tt>charT</tt> that do
not belong to the set of required specializations - <i>end note</i>].</ins>
</blockquote>
</li>

<li>
<p>
Change 22.4.6.1.2 [locale.money.get.virtuals]/4:
</p>

<blockquote>
<p>
[..] The value <tt>units</tt> is produced as if by:
</p>

<blockquote><pre>for (int i = 0; i &lt; n; ++i)
  buf2[i] = src[<ins>char_traits&lt;charT&gt;::</ins>find(atoms, <del>atoms+</del>sizeof(src), buf1[i]) - atoms];
buf2[n] = 0;
sscanf(buf2, "%Lf", &amp;units);
</pre></blockquote>
</blockquote>
</li>

<li>
<p>
Change 22.4.6.2.2 [locale.money.put.virtuals]/1:
</p>

<blockquote>
[..] for character buffers <tt>buf1</tt> and <tt>buf2</tt>. If <ins>for</ins> the first
character <ins><tt>c</tt></ins>
in <tt>digits</tt> or <tt>buf2</tt> <del>is equal to
<tt>ct.widen('-')</tt></del><ins><tt>char_traits&lt;charT&gt;::eq(c,
ct.widen('-')) == true</tt></ins>, [..]
</blockquote>
</li>

<li>
<p>
Add a new paragraph after the 
first paragraph of 27.2.2 [iostreams.limits.pos]/1:
</p>
<blockquote>
In the classes of clause 27,
a template formal parameter with name <tt>charT</tt> represents 
one of
the set of types
containing <tt>char</tt>, <tt>wchar_t</tt>,
and any other implementation-defined character type
that satisfies
the requirements for a character on which any of the iostream components
can be instantiated.
</blockquote>
</li>

<li>
<p>
Add a footnote to the first sentence of 27.7.1.2.2 [istream.formatted.arithmetic]/1:
</p>

<blockquote>
<p>
As in the case of the inserters, these extractors depend on the locale's
<tt>num_get&lt;&gt;</tt> (22.4.2.1) object to perform parsing the input stream
data.<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
Add a footnote to the second sentence of 27.7.2.6.2 [ostream.inserters.arithmetic]/1:
</p>

<blockquote>
<p>
<i>Effects:</i> The classes <tt>num_get&lt;&gt;</tt> and
<tt>num_put&lt;&gt;</tt> handle locale-dependent numeric formatting and
parsing. These inserter functions use the imbued locale value to perform
numeric formatting.<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>


<li>
<p>
Add a footnote after the first sentence of 27.7.4 [ext.manip]/4:
</p>

<blockquote>
<p>
<i>Returns:</i> An object of unspecified type such that if in is an object of type
<tt>basic_istream&lt;charT, traits&gt;</tt> then the expression <tt>in &gt;&gt; get_money(mon, intl)</tt>
behaves as if it called <tt>f(in, mon, intl)</tt>, where the function <tt>f</tt> is defined
as:<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
Add a footnote after the first sentence of 27.7.4 [ext.manip]/5:
</p>

<blockquote>
<p>
<i>Returns:</i> An object of unspecified type such that if <tt>out</tt> is an object of type
<tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt; put_money(mon, intl)</tt>
behaves as a formatted input function that calls <tt>f(out, mon, intl)</tt>, where the
function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
Add a footnote after the first sentence of 27.7.4 [ext.manip]/8:
</p>

<blockquote>
<p>
<i>Returns:</i> An object of unspecified type such that if <tt>in</tt> is an
object of type b<tt>asic_istream&lt;charT, traits&gt;</tt> then the expression
<tt>in &gt;&gt;get_time(tmb, fmt)</tt> behaves as if it called <tt>f(in, tmb, fmt)</tt>,
where the function <tt>f</tt> is defined as:<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the input stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>

<li>
<p>
Add a footnote after the first sentence of 27.7.4 [ext.manip]/10:
</p>

<blockquote>
<p>
Returns: An object of unspecified type such that if <tt>out</tt> is an object of type
<tt>basic_ostream&lt;charT, traits&gt;</tt> then the expression <tt>out &lt;&lt;put_time(tmb, fmt)</tt>
behaves as if it called <tt>f(out, tmb, fmt)</tt>, where the function <tt>f</tt> is defined
as:<ins><sup>(footnote)</sup></ins> [..]
</p>

<p>
<ins>
<sup>footnote)</sup> If the traits of the output stream has different semantics for <tt>lt()</tt>,
<tt>eq()</tt>, and <tt>assign()</tt> than <tt>char_traits&lt;char_type&gt;</tt>, this may give surprising
results.
</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>
</blockquote>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change 22.3.1.1.1 [locale.category]/6:
</p>

<blockquote>
[..] A template formal parameter with name <tt>C</tt> represents 
the set 
<del>of all possible specializations on a</del> 
<ins>of types containing <tt>char</tt>, <tt>wchar_t</tt>,
and any other implementation-defined character type
</ins>
<del> parameter</del>
that satisfies
the requirements for a character on which any of the iostream components
can be instantiated. [..]
</blockquote>
</li>

<li>
<p>
Add a new paragraph after the 
first paragraph of 27.2.2 [iostreams.limits.pos]/1:
</p>
<blockquote>
In the classes of clause 27,
a template formal parameter with name <tt>charT</tt> represents 
one of
the set of types
containing <tt>char</tt>, <tt>wchar_t</tt>,
and any other implementation-defined character type
that satisfies
the requirements for a character on which any of the iostream components
can be instantiated.
</blockquote>
</li>

</ol>




<hr>
<h3><a name="428"></a>428. string::erase(iterator) validity</h3>
<p><b>Section:</b> 21.4.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
that q must be a valid dereferenceable iterator into the sequence a.
</p>

<p>
However, 21.3.5.5, p5 describing string::erase(p) only requires that
p be a valid iterator.
</p>

<p>
This may be interepreted as a relaxation of the general requirement,
which is most likely not the intent.
</p>


<p><b>Proposed resolution:</b></p>
<p>Remove 21.4.6.5 [string::erase] paragraph 5.</p>


<p><b>Rationale:</b></p>
<p>The LWG considered two options: changing the string requirements to
  match the general container requirements, or just removing the
  erroneous string requirements altogether.  The LWG chose the latter
  option, on the grounds that duplicating text always risks the
  possibility that it might be duplicated incorrectly.</p>





<hr>
<h3><a name="430"></a>430. valarray subset operations</h3>
<p><b>Section:</b> 26.6.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard fails to specify the behavior of valarray::operator[](slice)
and other valarray subset operations when they are passed an "invalid"
slice object, i.e., either a slice that doesn't make sense at all (e.g.,
slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
object (e.g., slice (2, 1, 1) for a valarray of size 1).
</p>
<p><i>[Kona: the LWG believes that invalid slices should invoke
  undefined behavior.  Valarrays are supposed to be designed for high
  performance, so we don't want to require specific checking.  We
  need wording to express this decision.]</i></p>


<p><i>[
Bellevue:
]</i></p>


<blockquote>
Please note that the standard also fails to specify the behavior of
slice_array and gslice_array in the valid case. Bill Plauger will
endeavor to provide revised wording for slice_array and gslice_array.
</blockquote>

<p><i>[
post-Bellevue:  Bill provided wording.
]</i></p>


<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Move to Ready.
</p>
</blockquote>

<p><i>[
2009-11-04 Pete opens:
]</i></p>


<blockquote>
The resolution to LWG issue 430 has not been applied --- there have been
changes to the underlying text, and the resolution needs to be reworked.
</blockquote>

<p><i>[
2010-03-09 Matt updated wording.
]</i></p>


<p><i>[
2010 Pittsburgh: Moved to Ready for Pittsburgh.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Replace 26.6.2.4 [valarray.sub], with the following:
</p>

<blockquote>
<p>
The member operator is overloaded to provide several ways to select
sequences of elements from among those controlled by <tt>*this</tt>.
Each of these operations returns a subset of the array.  The
const-qualified versions return this subset as a new <tt>valarray</tt>. The
non-const versions return a class template object which has reference
semantics to the original array, working in conjunction with various
overloads of <tt>operator=</tt> (and other assigning operators) to allow
selective replacement (slicing) of the controlled sequence. In each case
the selected element(s) must exist.
</p>

<pre>valarray&lt;T&gt; operator[](slice slicearr) const; 
</pre>

<blockquote>
<p>
This function returns an object of class <tt>valarray&lt;T&gt;</tt>
containing those elements of the controlled sequence designated by
<tt>slicearr</tt>. [<i>Example:</i>
</p>

<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
valarray&lt;char&gt; v1("ABCDE", 5); 
v0[slice(2, 5, 3)] = v1; 
// v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
</pre></blockquote>
<p>
<i>end example</i>]
</p>
</blockquote>
 
<pre>valarray&lt;T&gt; operator[](slice slicearr); 
</pre>

<blockquote>
<p>
This function selects those elements of the controlled sequence
designated by <tt>slicearr</tt>.  [<i>Example</i>:
</p>

<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
valarray&lt;char&gt; v1("ABCDE", 5); 
v0[slice(2, 5, 3)] = v1; 
// v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
</pre></blockquote>
<p>
<i>end example</i>]
</p>
</blockquote>
 
<pre>valarray&lt;T&gt; operator[](const gslice&amp; gslicearr) const; 
</pre>

<blockquote>
<p>
This function returns an object of class <tt>valarray&lt;T&gt;</tt>
containing those elements of the controlled sequence designated by
<tt>gslicearr</tt>. [<i>Example:</i>
</p>

<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
const size_t lv[] = {2, 3}; 
const size_t dv[] = {7, 2}; 
const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2); 
// v0[gslice(3, len, str)] returns 
// valarray&lt;char&gt;("dfhkmo", 6)
</pre></blockquote>
<p>
<i>end example</i>]
</p>
</blockquote>
 
<pre>gslice_array&lt;T&gt; operator[](const gslice&amp; gslicearr); 
</pre>

<blockquote>
<p>
This function selects those elements of the controlled sequence
designated by <tt>gslicearr</tt>.  [<i>Example:</i>
</p>

<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
valarray&lt;char&gt; v1("ABCDEF", 6); 
const size_t lv[] = {2, 3}; 
const size_t dv[] = {7, 2}; 
const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2); 
v0[gslice(3, len, str)] = v1; 
// v0 == valarray&lt;char&gt;("abcAeBgCijDlEnFp", 16)
</pre></blockquote>
<p>
<i>end example</i>]
</p>
</blockquote>
 
<pre>valarray&lt;T&gt; operator[](const valarray&lt;bool&gt;&amp; boolarr) const; 
</pre>

<blockquote>
<p>
This function returns an object of class <tt>valarray&lt;T&gt;</tt>
containing those elements of the controlled sequence designated by
<tt>boolarr</tt>. [<i>Example:</i>
</p>

<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
const bool vb[] = {false, false, true, true, false, true}; 
// v0[valarray&lt;bool&gt;(vb, 6)] returns 
// valarray&lt;char&gt;("cdf", 3)
</pre></blockquote>
<p>
<i>end example</i>] 
</p>
</blockquote>
 
<pre>mask_array&lt;T&gt; operator[](const valarray&lt;bool&gt;&amp; boolarr); 
</pre>

<blockquote>
<p>
This function selects those elements of the controlled sequence
designated by <tt>boolarr</tt>. [<i>Example:</i>
</p>

<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
valarray&lt;char&gt; v1("ABC", 3); 
const bool vb[] = {false, false, true, true, false, true}; 
v0[valarray&lt;bool&gt;(vb, 6)] = v1; 
// v0 == valarray&lt;char&gt;("abABeCghijklmnop", 16)
</pre></blockquote>
<p>
<i>end example</i>]
</p>
</blockquote>
 
<pre>valarray&lt;T&gt; operator[](const valarray&lt;size_t&gt;&amp; indarr) const; 
</pre>

<blockquote>
<p>
This function returns an object of class <tt>valarray&lt;T&gt;</tt>
containing those elements of the controlled sequence designated by
<tt>indarr</tt>. [<i>Example:</i>
</p>

<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
const size_t vi[] = {7, 5, 2, 3, 8}; 
// v0[valarray&lt;size_t&gt;(vi, 5)] returns 
// valarray&lt;char&gt;("hfcdi", 5)
</pre></blockquote>
<p>
<i>end example</i>] 
</p>
</blockquote>
 
<pre>indirect_array&lt;T&gt; operator[](const valarray&lt;size_t&gt;&amp; indarr);
</pre>

<blockquote>
<p>
This function selects those elements of the controlled sequence
designated by <tt>indarr</tt>. [<i>Example:</i>
</p>

<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16); 
valarray&lt;char&gt; v1("ABCDE", 5); 
const size_t vi[] = {7, 5, 2, 3, 8}; 
v0[valarray&lt;size_t&gt;(vi, 5)] = v1; 
// v0 == valarray&lt;char&gt;("abCDeBgAEjklmnop", 16)
</pre></blockquote>
<p>
<i>end example</i>]
</p>
</blockquote>

</blockquote>





<hr>
<h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
<p><b>Section:</b> 20.2.5 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-09-20 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>Clause 20.2.5 [allocator.requirements] paragraph 4 says that implementations
  are permitted to supply containers that are unable to cope with
  allocator instances and that container implementations may assume
  that all instances of an allocator type compare equal.  We gave
  implementers this latitude as a temporary hack, and eventually we
  want to get rid of it.  What happens when we're dealing with
  allocators that <i>don't</i> compare equal?
</p>

<p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
  objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
  <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
  we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>

<p>1. This operation is illegal.  Perhaps we could say that an
  implementation is required to check and to throw an exception, or
  perhaps we could say it's undefined behavior.</p>
<p>2. The operation performs a slow swap (i.e. using three
  invocations of <tt>operator=</tt>, leaving each allocator with its
  original container.  This would be an O(N) operation.</p>
<p>3. The operation swaps both the vectors' contents and their
  allocators.  This would be an O(1) operation. That is:</p>
  <blockquote>
  <pre>    my_alloc a1(...);
    my_alloc a2(...);
    assert(a1 != a2);

    vector&lt;int, my_alloc&gt; v1(a1);
    vector&lt;int, my_alloc&gt; v2(a2);
    assert(a1 == v1.get_allocator());
    assert(a2 == v2.get_allocator());

    v1.swap(v2);
    assert(a1 == v2.get_allocator());
    assert(a2 == v1.get_allocator());
  </pre>
  </blockquote>

<p><i>[Kona: This is part of a general problem.  We need a paper
  saying how to deal with unequal allocators in general.]</i></p>


<p><i>[pre-Sydney: Howard argues for option 3 in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
]</i></p>


<p><i>[
2007-01-12, Howard:  This issue will now tend to come up more often with move constructors
and move assignment operators.  For containers, these members transfer resources (i.e.
the allocated memory) just like swap.
]</i></p>


<p><i>[
Batavia:  There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
requirement using concepts.  If the allocator supports Swappable, then container's swap will
swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
]</i></p>


<p><i>[
2009-04-28 Pablo adds:
]</i></p>

<blockquote>
Fixed in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>.
I argued for marking this Tentatively-Ready right after Bellevue,
but there was a concern that
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
would break in the presence of the RVO. (That breakage had nothing to do with
swap, but never-the-less). I addressed that breakage in in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
(Summit) by means of a non-normative reference:

<blockquote>
[<i>Note:</i> in situations where the copy constructor for a container is elided,
this function is not called. The behavior in these cases is as if
<tt>select_on_container_copy_construction</tt> returned <tt>x</tt> � <i>end note</i>]
</blockquote>

</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Addressed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3>
<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Christian W Brock <b>Opened:</b> 2003-09-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.7.1.3 par 8 says:</p>
<blockquote><p>
Notes: The function can make a write position available only if
    ( mode &amp; ios_base::out) != 0. To make a write position
    available, the function reallocates (or initially allocates) an
    array object with a sufficient number of elements to hold the
    current array object (if any), plus one additional write position.
    If ( mode &amp; ios_base::in) != 0, the function alters the read end
    pointer egptr() to point just past the new write position (as
    does the write end pointer epptr()).
</p></blockquote>

<p>
The sentences "plus one additional write position." and especially
    "(as does the write end pointer epptr())" COULD by interpreted
    (and is interpreted by at least my library vendor) as:
</p>

<blockquote><p>
    post-condition: epptr() == pptr()+1
</p></blockquote>

<p>
This WOULD force sputc() to call the virtual overflow() each time.
</p>

<p>The proposed change also affects Defect Report 169.</p>



<p><b>Proposed resolution:</b></p>
<p>27.7.1.1/2 Change:</p>

<blockquote><p>
2- Notes: The function allocates no array object.
</p></blockquote>

<p>
to:
</p>

<blockquote><p>
2- Postcondition: str() == "".
</p></blockquote>

<p>
27.7.1.1/3 Change:
</p>

<blockquote>
<p>
-3- Effects: Constructs an object of class basic_stringbuf,
initializing the base class with basic_streambuf()
(lib.streambuf.cons), and initializing mode with which . Then copies
the content of str into the basic_stringbuf underlying character
sequence and initializes the input and output sequences according to
which. If which &amp; ios_base::out is true, initializes the output
sequence with the underlying sequence. If which &amp; ios_base::in is
true, initializes the input sequence with the underlying sequence.
</p>
</blockquote>

<p>to:</p>

<blockquote>
<p>
-3- Effects: Constructs an object of class basic_stringbuf,
initializing the base class with basic_streambuf()
(lib.streambuf.cons), and initializing mode with which. Then copies
the content of str into the basic_stringbuf underlying character
sequence. If which &amp; ios_base::out is true, initializes the output
sequence such that pbase() points to the first underlying character,
epptr() points one past the last underlying character, and if (which &amp;
ios_base::ate) is true, pptr() is set equal to
epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
is true, initializes the input sequence such that eback() and gptr()
point to the first underlying character and egptr() points one past
the last underlying character.
</p>
</blockquote>

<p>27.7.1.2/1 Change:</p>

<blockquote>
<p>
-1- Returns: A basic_string object whose content is equal to the
basic_stringbuf underlying character sequence. If the buffer is only
created in input mode, the underlying character sequence is equal to
the input sequence; otherwise, it is equal to the output sequence. In
case of an empty underlying character sequence, the function returns
basic_string&lt;charT,traits,Allocator&gt;().
</p>
</blockquote>

<p>to:</p>

<blockquote>
<p>
-1- Returns: A basic_string object whose content is equal to the
basic_stringbuf underlying character sequence. If the basic_stringbuf
was created only in input mode, the resultant basic_string contains
the character sequence in the range [eback(), egptr()).  If the
basic_stringbuf was created with (which &amp; ios_base::out) being true
then the resultant basic_string contains the character sequence in the
range [pbase(), high_mark) where high_mark represents the position one
past the highest initialized character in the buffer.  Characters can
be initialized either through writing to the stream, or by
constructing the basic_stringbuf with a basic_string, or by calling
the str(basic_string) member function.  In the case of calling the
str(basic_string) member function, all characters initialized prior to
the call are now considered uninitialized (except for those
characters re-initialized by the new basic_string).  Otherwise the
basic_stringbuf has been created in neither input nor output mode and
a zero length basic_string is returned.
</p>
</blockquote>

<p>
27.7.1.2/2 Change:
</p>

<blockquote>
<p>
-2- Effects: If the basic_stringbuf's underlying character sequence is
not empty, deallocates it. Then copies the content of s into the
basic_stringbuf underlying character sequence and initializes the
input and output sequences according to the mode stored when creating
the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
initializes the output sequence with the underlying sequence. If
(mode&amp;ios_base::in) is true, then initializes the input sequence with
the underlying sequence.
</p>
</blockquote>

<p>to:</p>

<blockquote>
<p>
-2- Effects: Copies the content of s into the basic_stringbuf
underlying character sequence. If mode &amp; ios_base::out is true,
initializes the output sequence such that pbase() points to the first
underlying character, epptr() points one past the last underlying
character, and if (mode &amp; ios_base::ate) is true,
pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
mode &amp; ios_base::in is true, initializes the input sequence such that
eback() and gptr() point to the first underlying character and egptr()
points one past the last underlying character.
</p>
</blockquote>

<p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>

<p>27.7.1.3/1 Change:</p>

<blockquote>
<p>
1- Returns: If the input sequence has a read position available,
returns traits::to_int_type(*gptr()).  Otherwise, returns
traits::eof().
</p>
</blockquote>

<p>to:</p>

<blockquote>
<p>
1- Returns: If the input sequence has a read position available,
returns traits::to_int_type(*gptr()).  Otherwise, returns
traits::eof().  Any character in the underlying buffer which has been
initialized is considered to be part of the input sequence.
</p>
</blockquote>

<p>27.7.1.3/9 Change:</p>

<blockquote>
<p>
-9- Notes: The function can make a write position available only if (
mode &amp; ios_base::out) != 0. To make a write position available, the
function reallocates (or initially allocates) an array object with a
sufficient number of elements to hold the current array object (if
any), plus one additional write position. If ( mode &amp; ios_base::in) !=
0, the function alters the read end pointer egptr() to point just past
the new write position (as does the write end pointer epptr()).
</p>
</blockquote>

<p>to:</p>

<blockquote>
<p>
-9- The function can make a write position available only if ( mode &amp;
ios_base::out) != 0. To make a write position available, the function
reallocates (or initially allocates) an array object with a sufficient
number of elements to hold the current array object (if any), plus one
additional write position. If ( mode &amp; ios_base::in) != 0, the
function alters the read end pointer egptr() to point just past the
new write position.
</p>
</blockquote>

<p>27.7.1.3/12 Change:</p>

<blockquote>
<p>
-12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
positioning operation fails. Otherwise, the function assigns xbeg +
newoff + off to the next pointer xnext .
</p>
</blockquote>

<p>to:</p>

<blockquote>
<p>
-12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
uninitialized character (as defined in 27.8.1.3 [stringbuf.members]
paragraph 1), the positioning operation fails. Otherwise, the function
assigns xbeg + newoff + off to the next pointer xnext .
</p>
</blockquote>

<p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
  something along these lines was a good idea, but the original
  proposed resolution didn't say enough about the effect of various
  member functions on the underlying character sequences.]</i></p>




<p><b>Rationale:</b></p>
<p>The current basic_stringbuf description is over-constrained in such
a way as to prohibit vendors from making this the high-performance
in-memory stream it was meant to be.  The fundamental problem is that
the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
observable from a derived client, and the current description
restricts the range [pbase(), epptr()) from being grown geometrically.
This change allows, but does not require, geometric growth of this
range.</p>

<p>Backwards compatibility issues: These changes will break code that
derives from basic_stringbuf, observes epptr(), and depends upon
[pbase(), epptr()) growing by one character on each call to overflow()
(i.e. test suites).  Otherwise there are no backwards compatibility
issues.</p>

<p>27.7.1.1/2: The non-normative note is non-binding, and if it were
binding, would be over specification.  The recommended change focuses
on the important observable fact.</p>

<p>27.7.1.1/3: This change does two things: 1.  It describes exactly
what must happen in terms of the sequences.  The terms "input
sequence" and "output sequence" are not well defined.  2.  It
introduces a common extension: open with app or ate mode.  I concur
with issue 238 that paragraph 4 is both wrong and unnecessary.</p>

<p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
resultant basic_string is not dependent upon epptr(), and thus
implementors are free to grow the underlying buffer geometrically
during overflow() *and* place epptr() at the end of that buffer.</p>

<p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>

<p>27.7.1.3/1: Clarifies that characters written to the stream beyond
the initially specified string are available for reading in an i/o
basic_streambuf.</p>

<p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
trailing parenthetical comment concerning epptr().</p>

<p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
longer allowable since [pbase(), epptr()) may now contain
uninitialized characters.  Positioning is only allowable over the
initialized range.</p>





<hr>
<h3><a name="434"></a>434. bitset::to_string() hard to use</h3>
<p><b>Section:</b> 20.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It has been pointed out a number of times that the bitset to_string() member
function template is tedious to use since callers must explicitly specify the
entire template argument list (3 arguments). At least two implementations
provide a number of overloads of this template to make it easier to use.
</p>



<p><b>Proposed resolution:</b></p>
<p>In order to allow callers to specify no template arguments at all, just the
first one (charT), or the first 2 (charT and traits), in addition to all
three template arguments, add the following three overloads to both the
interface (declarations only) of the class template bitset as well as to
section 23.3.5.2, immediately after p34, the Returns clause of the existing
to_string() member function template:</p>

<pre>    template &lt;class charT, class traits&gt;
    basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
    to_string () const;

    -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().

    template &lt;class charT&gt;
    basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
    to_string () const;

    -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().

    basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
    to_string () const;

    -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
</pre>

<p><i>[Kona: the LWG agrees that this is an improvement over the
  status quo.  Dietmar thought about an alternative using a proxy
  object but now believes that the proposed resolution above is the
  right choice.
]</i></p>








<hr>
<h3><a name="435"></a>435. bug in DR 25</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>
It has been pointed out that the proposed resolution in DR 25 may not be
quite up to snuff: <br>
http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
</p>

<p>
It looks like Petur is right. The complete corrected text is copied below.
I think we may have have been confused by the reference to 22.2.2.2.2 and
the subsequent description of `n' which actually talks about the second
argument to sputn(), not about the number of fill characters to pad with.
</p>

<p>
So the question is: was the original text correct? If the intent was to
follow classic iostreams then it most likely wasn't, since setting width()
to less than the length of the string doesn't truncate it on output. This
is also the behavior of most implementations (except for SGI's standard
iostreams where the operator does truncate).
</p>



<p><b>Proposed resolution:</b></p>
<p>Change the text in 21.3.7.9, p4 from</p>
    <blockquote><p>
    If bool(k) is true, inserts characters as if by calling
    os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
    of lib.facet.num.put.virtuals, where n is the larger of os.width()
    and str.size(); 
    </p></blockquote>
<p>to</p>
    <blockquote><p>
    If bool(k) is true, determines padding as described in
    lib.facet.num.put.virtuals, and then inserts the resulting
    sequence of characters <tt>seq</tt> as if by calling
    <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
    <tt>os.width()</tt> and <tt>str.size()</tt>;
     </p></blockquote>

<p><i>[Kona: it appears that neither the original wording, DR25, nor the
  proposed resolution, is quite what we want.  We want to say that
  the string will be output, padded to os.width() if necessary.  We
  don't want to duplicate the padding rules in clause 22, because
  they're complicated, but we need to be careful because they weren't
  quite written with quite this case in mind.  We need to say what
  the character sequence is, and then defer to clause 22.  Post-Kona:
  Benjamin provided wording.]</i></p>







<hr>
<h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3>
<p><b>Section:</b> 22.3.1.1.2 [locale.facet] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
and the locale template ctor? And if so, does it designate the same Facet as
the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
Different implementations behave differently: some fail to compile, others
accept such types but behave inconsistently.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 22.1.1.1.2, p1 to read:</p>

<p>Template parameters in this clause which are required to be facets
are those named Facet in declarations. A program that passes a type
that is not a facet, or a type that refers to volatile-qualified
facet, as an (explicit or deduced) template parameter to a locale
function expecting a facet, is ill-formed.  A const-qualified facet is
a valid template argument to any locale function that expects a Facet
template parameter.</p>

<p><i>[Kona: changed the last sentence from a footnote to normative
text.]</i></p>






<hr>
<h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2003-10-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>Section 23.2.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
noticed with statements like:</p>
<pre>vector&lt;int&gt; v(10, 1);
</pre>

<p>The intent of the above statement was to construct with:</p>
<pre>vector(size_type, const value_type&amp;);
</pre>

<p>but early implementations failed to compile as they bound to:</p>
<pre>template &lt;class InputIterator&gt;
vector(InputIterator f, InputIterator l);
</pre>
<p>instead.</p>

<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
member template constructor will have the same effect as:</p>
<pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
</pre>
<p>(and similarly for the other member template functions of sequences).</p>

<p>There is also a note that describes one implementation technique:</p>
<blockquote><p>
   One way that sequence implementors can satisfy this requirement is to
   specialize the member template for every integral type.
</p></blockquote>

<p>This might look something like:</p>
<blockquote>
<pre>template &lt;class T&gt;
struct vector
{
     typedef unsigned size_type;

     explicit vector(size_type) {}
     vector(size_type, const T&amp;) {}

     template &lt;class I&gt;
     vector(I, I);

     // ...
};

template &lt;class T&gt;
template &lt;class I&gt;
vector&lt;T&gt;::vector(I, I) { ... }

template &lt;&gt;
template &lt;&gt;
vector&lt;int&gt;::vector(int, int) { ... }

template &lt;&gt;
template &lt;&gt;
vector&lt;int&gt;::vector(unsigned, unsigned) { ... }

//  ...
</pre>
</blockquote>

<p>Label this solution 'A'.</p>

<p>The standard also says:</p>
<blockquote><p>
 Less cumbersome implementation techniques also exist.
</p></blockquote>
<p>
A popular technique is to not specialize as above, but instead catch
every call with the member template, detect the type of InputIterator,
and then redirect to the correct logic.  Something like:
</p>
<blockquote>
<pre>template &lt;class T&gt;
template &lt;class I&gt;
vector&lt;T&gt;::vector(I f, I l)
{
     choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
}

template &lt;class T&gt;
template &lt;class I&gt;
vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
{
    // construct with iterators
}

template &lt;class T&gt;
template &lt;class I&gt;
vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
{
    size_type sz = static_cast&lt;size_type&gt;(f);
    value_type v = static_cast&lt;value_type&gt;(l);
    // construct with sz,v
}
</pre>
</blockquote>

<p>Label this solution 'B'.</p>

<p>Both of these solutions solve the case the standard specifically
mentions:</p>
<pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
</pre>

<p>
However, (and here is the problem), the two solutions have different
behavior in some cases where the value_type of the sequence is not an
integral type.  For example consider:
</p>
<blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
</pre></blockquote>
<p>
The second line of this snippet is likely an error.  Solution A catches
the error and refuses to compile.  The reason is that there is no
specialization of the member template constructor that looks like:
</p>
<pre>template &lt;&gt;
template &lt;&gt;
vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
</pre>

<p>
So the expression binds to the unspecialized member template
constructor, and then fails (compile time) because char is not an
InputIterator.
</p>

<p>
Solution B compiles the above example though.  'a' is casted to an
unsigned integral type and used to size the outer vector.  'b' is
static casted to the inner vector using it's explicit constructor:
</p>

<pre>explicit vector(size_type n);
</pre>

<p>
and so you end up with a static_cast&lt;size_type&gt;('a') by
static_cast&lt;size_type&gt;('b') matrix.
</p>

<p>
It is certainly possible that this is what the coder intended.  But the
explicit qualifier on the inner vector has been thwarted at any rate.
</p>

<p>
The standard is not clear whether the expression:
</p>

<pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
</pre>

<p>
(and similar expressions) are:
</p>

<ol>
<li>  undefined behavior.</li>
<li>  illegal and must be rejected.</li>
<li>  legal and must be accepted.</li>
</ol>

<p>My preference is listed in the order presented.</p>

<p>There are still other techniques for implementing the requirements of
paragraphs 9-11, namely the "restricted template technique" (e.g.
enable_if).  This technique is the most compact and easy way of coding
the requirements, and has the behavior of #2 (rejects the above
expression).
</p>

<p>
Choosing 1 would allow all implementation techniques I'm aware of.
Choosing 2 would allow only solution 'A' and the enable_if technique.
Choosing 3 would allow only solution 'B'.
</p>

<p>
Possible wording for a future standard if we wanted to actively reject
the expression above would be to change "static_cast" in paragraphs
9-11 to "implicit_cast" where that is defined by:
</p>

<blockquote>
<pre>template &lt;class T, class U&gt;
inline
T implicit_cast(const U&amp; u)
{
     return u;
}
</pre>
</blockquote>



<p><b>Proposed resolution:</b></p>

<p>Replace 23.2.3 [sequence.reqmts] paragraphs 9 - 11 with:</p>

<p>For every sequence defined in this clause and in clause lib.strings:</p>

<ul>
  <li>
    <p>If the constructor</p>
       <pre>       template &lt;class InputIterator&gt;
       X(InputIterator f, InputIterator l,
         const allocator_type&amp; a = allocator_type())
       </pre>
    <p>is called with a type InputIterator that does not qualify as
    an input iterator, then the constructor will behave as if the
    overloaded constructor:</p>
       <pre>       X(size_type, const value_type&amp; = value_type(),
         const allocator_type&amp; = allocator_type())
       </pre>
    <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
  </li>

  <li>
    <p>If the member functions of the forms:</p>
       <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
       rt fx1(iterator p, InputIterator f, InputIterator l);

       template &lt;class InputIterator&gt;          //  such as  append(), assign()
       rt fx2(InputIterator f, InputIterator l);

       template &lt;class InputIterator&gt;          //  such as  replace()
       rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
       </pre>
    <p>are called with a type InputIterator that does not qualify as
    an input iterator, then these functions will behave as if the
    overloaded member functions:</p>
       <pre>       rt fx1(iterator, size_type, const value_type&amp;);

       rt fx2(size_type, const value_type&amp;);

       rt fx3(iterator, iterator, size_type, const value_type&amp;);
       </pre>
    <p>were called instead, with the same arguments.</p>
  </li>
</ul>

<p>In the previous paragraph the alternative binding will fail if f 
is not implicitly convertible to X::size_type or if l is not implicitly 
convertible to X::value_type.</p>

<p>
The extent to which an implementation determines that a type cannot be
an input iterator is unspecified, except that as a minimum integral
types shall not qualify as input iterators.
</p>



<p><i>[
Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
to be accepted, and also agreed that this is surprising behavior.  The
LWG considered several options, including something like
implicit_cast, which doesn't appear to be quite what we want.  We
considered Howards three options: allow acceptance or rejection,
require rejection as a compile time error, and require acceptance.  By
straw poll (1-6-1), we chose to require a compile time error.
Post-Kona: Howard provided wording.
]</i></p>


<p><i>[
Sydney: The LWG agreed with this general direction, but there was some
discomfort with the wording in the original proposed resolution.
Howard submitted new wording, and we will review this again in
Redmond.
]</i></p>


<p><i>[Redmond: one very small change in wording: the first argument
  is cast to size_t.  This fixes the problem of something like
  <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not 
  implicitly convertible to the value type.]</i></p>




<p><b>Rationale:</b></p>
<p>The proposed resolution fixes:</p>

<pre>  vector&lt;int&gt; v(10, 1);
</pre>

<p>
since as integral types 10 and 1 must be disqualified as input
iterators and therefore the (size,value) constructor is called (as
if).</p>

<p>The proposed resolution breaks:</p>

<pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
</pre>

<p>
because the integral type 1 is not *implicitly* convertible to
vector&lt;T&gt;.  The wording above requires a diagnostic.</p>

<p>
The proposed resolution leaves the behavior of the following code
unspecified.
</p>

<pre>  struct A
  {
    operator int () const {return 10;}
  };

  struct B
  {
    B(A) {}
  };

  vector&lt;B&gt; v(A(), A());
</pre>

<p>
The implementation may or may not detect that A is not an input
iterator and employee the (size,value) constructor.  Note though that
in the above example if the B(A) constructor is qualified explicit,
then the implementation must reject the constructor as A is no longer
implicitly convertible to B.
</p>





<hr>
<h3><a name="441"></a>441. Is fpos::state const?</h3>
<p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In section 27.5.3.1 [fpos.members] fpos&lt;stateT&gt;::state() is declared
non const, but in section 27.5.3 [fpos] it is declared const.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In section 27.5.3.1 [fpos.members], change the declaration of 
<tt>fpos&lt;stateT&gt;::state()</tt> to const.
</p>





<hr>
<h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</h3>
<p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In section 27.7.2.4 [ostream::sentry] paragraph 4, in description part
basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
as non const, but in section 27.6.2.3, in synopsis it is declared
const.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In section 27.7.2.4 [ostream::sentry] paragraph 4, change the declaration
of <tt>sentry::operator bool()</tt> to const.
</p>





<hr>
<h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
<p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In section 27.9.1.4 [filebuf.members] par6, in effects description of
basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
should be overflow(traits::eof()).
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change overflow(EOF) to overflow(traits::eof()).
</p>





<hr>
<h3><a name="444"></a>444. Bad use of casts in fstream</h3>
<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
27.9.1.9 [ifstream.members] p1, 27.9.1.13 [ofstream.members] p1, 27.9.1.17 [fstream.members] p1 seems have same problem as exposed in LWG issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
</p>


<p><b>Proposed resolution:</b></p>

<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
 constness. The other two places are stylistic: we could change the
 C-style casts to const_cast. Post-Sydney: Howard provided wording.
]</i></p>


<p>Change 27.8.1.7/1 from:</p>
<blockquote><p>
  Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
</p></blockquote>

<p>to:</p>
<blockquote><p>
  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
</p></blockquote>

<p>Change 27.8.1.10/1 from:</p>
<blockquote><p>
  Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
</p></blockquote>

<p>to:</p>
<blockquote><p>
  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
</p></blockquote>

<p>Change 27.8.1.13/1 from:</p>
<blockquote><p>
  Returns: &amp;sb.
</p></blockquote>

<p>to:</p>
<blockquote><p>
  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
</p></blockquote>








<hr>
<h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3>
<p><b>Section:</b> 24.4.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-12-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard places no restrictions at all on the reference type
of input, output, or forward iterators (for forward iterators it
only specifies that *x must be value_type&amp; and doesn't mention
the reference type).  Bidirectional iterators' reference type is
restricted only by implication, since the base iterator's
reference type is used as the return type of reverse_iterator's
operator*, which must be T&amp; in order to be a conforming forward
iterator.
</p>

<p>
Here's what I think we ought to be able to expect from an input
or forward iterator's reference type R, where a is an iterator
and V is its value_type
</p>

<ul>
  <li>
      *a is convertible to R
  </li>

  <li>
      R is convertible to V
  </li>

  <li>
      static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
      static_cast&lt;V&gt;(*a) 
  </li>
</ul>

<p>A mutable forward iterator ought to satisfy, for x of type V:</p>
  <pre>      { R r = *a; r = x; } is equivalent to *a = x;
  </pre>

<p>
I think these requirements capture existing container iterators
(including vector&lt;bool&gt;'s), but render istream_iterator invalid;
its reference type would have to be changed to a constant
reference.
</p>


<p>
(Jeremy Siek) During the discussion in Sydney, it was felt that a
simpler long term solution for this was needed. The solution proposed
was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
iterators in the Standard Library already meet this requirement. Some
iterators are output iterators, and do not need to meet the
requirement, and others are only specified through the general
iterator requirements (which will change with this resolution). The
sole case where there is an explicit definition of the reference type
that will need to change is <tt>istreambuf_iterator</tt> which returns
<tt>charT</tt> from <tt>operator*</tt> but has a reference type of
<tt>charT&amp;</tt>. We propose changing the reference type of
<tt>istreambuf_iterator</tt> to <tt>charT</tt>.
</p>

<p>The other option for resolving the issue with <tt>pointer</tt>,
  mentioned in the note below, is to remove <tt>pointer</tt>
  altogether. I prefer placing requirements on <tt>pointer</tt> to
  removing it for two reasons. First, <tt>pointer</tt> will become
  useful for implementing iterator adaptors and in particular,
  <tt>reverse_iterator</tt> will become more well defined. Second,
  removing <tt>pointer</tt> is a rather drastic and publicly-visible
  action to take.</p>

<p>The proposed resolution technically enlarges the requirements for
iterators, which means there are existing iterators (such as
<tt>istreambuf_iterator</tt>, and potentially some programmer-defined
iterators) that will no longer meet the requirements. Will this break
existing code? The scenario in which it would is if an algorithm
implementation (say in the Standard Library) is changed to rely on
<tt>iterator_traits::reference</tt>, and then is used with one of the
iterators that do not have an appropriately defined
<tt>iterator_traits::reference</tt>.
</p>


<p>The proposed resolution makes one other subtle change. Previously,
it was required that output iterators have a <tt>difference_type</tt>
and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
iterator could not be an output iterator. This is clearly a mistake,
so I've changed the wording to say that those types may be
<tt>void</tt>.
</p>



<p><b>Proposed resolution:</b></p>

<p>In 24.4.1 [iterator.traits], after:</p>

<blockquote><p>
be defined as the iterator's difference type, value type and iterator
category, respectively.
</p></blockquote>

<p>add</p>

<blockquote><p>
In addition, the types</p>
<pre>iterator_traits&lt;Iterator&gt;::reference
iterator_traits&lt;Iterator&gt;::pointer
</pre>
<p>must be defined as the iterator's reference and pointer types, that
is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
respectively.</p>
</blockquote>

<p>In 24.4.1 [iterator.traits], change:</p>

<blockquote><p>
In the case of an output iterator, the types</p>
<pre>iterator_traits&lt;Iterator&gt;::difference_type
iterator_traits&lt;Iterator&gt;::value_type
</pre>
<p>are both defined as <tt>void</tt>.</p>
</blockquote>

<p>to:</p>
<blockquote><p>
In the case of an output iterator, the types</p>
<pre>iterator_traits&lt;Iterator&gt;::difference_type
iterator_traits&lt;Iterator&gt;::value_type
iterator_traits&lt;Iterator&gt;::reference
iterator_traits&lt;Iterator&gt;::pointer
</pre>
<p>may be defined as <tt>void</tt>.</p>
</blockquote>

<p>In 24.6.3 [istreambuf.iterator], change:</p>
<blockquote>
<pre>typename traits::off_type, charT*, charT&amp;&gt;
</pre>
</blockquote>
<p>to:</p>
<blockquote>
<pre>typename traits::off_type, charT*, charT&gt;
</pre>
</blockquote>

<p><i>[
Redmond: there was concern in Sydney that this might not be the only place
where things were underspecified and needed to be changed.  Jeremy
reviewed iterators in the standard and confirmed that nothing else
needed to be changed.
]</i></p>









<hr>
<h3><a name="448"></a>448. Random Access Iterators over abstract classes</h3>
<p><b>Section:</b> 24.2.7 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 76, the random access iterator requirement table, says that the
return type of a[n] must be "convertible to T".  When an iterator's
value_type T is an abstract class, nothing is convertible to T.
Surely this isn't an intended restriction?
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the return type to "convertible to T const&amp;".
</p>





<hr>
<h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3>
<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2004-01-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Original text:</p>
<blockquote><p>
The macro offsetof accepts a restricted set of type arguments in this
International Standard. type shall be a POD structure or a POD union
(clause 9). The result of applying the offsetof macro to a field that
is a static data member or a function member is undefined."
</p></blockquote>

<p>Revised text:</p>
<blockquote><p>
"If type is not a POD structure or a POD union the results are undefined."
</p></blockquote>

<p>
Looks to me like the revised text should have replaced only the second
sentence. It doesn't make sense standing alone.
</p>



<p><b>Proposed resolution:</b></p>
<p>Change 18.1, paragraph 5, to:</p>

<blockquote><p>
The macro offsetof accepts a restricted set of type arguments in this
International Standard.  If type is not a POD structure or a POD union
the results are undefined.  The result of applying the offsetof macro
to a field that is a static data member or a function member is
undefined."
</p></blockquote>





<hr>
<h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3>
<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
                                    ios_base::openmode);
</pre>
<p>
is obliged to fail if nothing has been inserted into the stream. This
is unnecessary and undesirable. It should be permissible to seek to
an effective offset of zero.</p>

<p><i>[
 Sydney: Agreed that this is an annoying problem: seeking to zero should be
 legal. Bill will provide wording.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>Change the sentence from:</p>
<blockquote><p>
For a sequence to be positioned, if its next pointer (either
gptr() or pptr()) is a null pointer, the positioning operation
fails.
</p></blockquote>

<p>to:</p>

<blockquote><p>
For a sequence to be positioned, if its next pointer (either
gptr() or pptr()) is a null pointer and the new offset newoff
is nonzero, the positioning operation fails.
</p></blockquote>





<hr>
<h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</h3>
<p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Both cerr::tie() and wcerr::tie() are obliged to be null at program
startup. This is overspecification and overkill. It is both traditional
and useful to tie cerr to cout, to ensure that standard output is drained
whenever an error message is written. This behavior should at least be
permitted if not required. Same for wcerr::tie().
</p>


<p><b>Proposed resolution:</b></p>

<p>Add to the description of cerr:</p>
<blockquote><p>
After the object cerr is initialized, cerr.tie() returns &amp;cout.
Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
(lib.basic.ios.cons).
</p></blockquote>

<p>Add to the description of wcerr:</p>

<blockquote><p>
After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
(lib.basic.ios.cons).
</p></blockquote>

<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
  permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
  provide wording.]</i></p>






<hr>
<h3><a name="456"></a>456. Traditional C header files are overspecified</h3>
<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>The C++ Standard effectively requires that the traditional C headers
(of the form &lt;xxx.h&gt;) be defined in terms of the newer C++
headers (of the form &lt;cxxx&gt;). Clauses 17.4.1.2/4 and D.5 combine
to require that:</p>

<ul>
 <li>Including the header &lt;cxxx&gt; declares a C name in namespace std.</li>

 <li> Including the header &lt;xxx.h&gt; declares a C name in namespace std
    (effectively by including &lt;cxxx&gt;), then imports it into the global
    namespace with an individual using declaration.</li>
</ul>

<p>
The rules were left in this form despited repeated and heated objections
from several compiler vendors. The C headers are often beyond the direct
control of C++ implementors. In some organizations, it's all they can do
to get a few #ifdef __cplusplus tests added. Third-party library vendors
can perhaps wrap the C headers. But neither of these approaches supports
the drastic restructuring required by the C++ Standard. As a result, it is
still widespread practice to ignore this conformance requirement, nearly
seven years after the committee last debated this topic. Instead, what is
often implemented is:
</p>

<ul>
 <li> Including the header &lt;xxx.h&gt; declares a C name in the
 global namespace.</li> 

 <li> Including the header &lt;cxxx&gt; declares a C name in the
 global namespace (effectively by including &lt;xxx.h&gt;), then
 imports it into namespace std with an individual using declaration.</li>
</ul>

<p>
The practical benefit for implementors with the second approach is that
they can use existing C library headers, as they are pretty much obliged
to do. The practical cost for programmers facing a mix of implementations
is that they have to assume weaker rules:</p>

<ul>
  <li> If you want to assuredly declare a C name in the global
  namespace, include &lt;xxx.h&gt;. You may or may not also get the
  declaration in namespace std.</li>

  <li> If you want to assuredly declare a C name in namespace std,
  include &lt;cxxx&gt;. You may or may not also get the declaration in
  the global namespace.</li>
</ul>

<p>
There also exists the <i>possibility</i> of subtle differences due to
Koenig lookup, but there are so few non-builtin types defined in the C
headers that I've yet to see an example of any real problems in this
area.
</p>

<p>
It is worth observing that the rate at which programmers fall afoul of
these differences has remained small, at least as measured by newsgroup
postings and our own bug reports. (By an overwhelming margin, the
commonest problem is still that programmers include &lt;string&gt; and can't
understand why the typename string isn't defined -- this a decade after
the committee invented namespace std, nominally for the benefit of all
programmers.)
</p>

<p>
We should accept the fact that we made a serious mistake and rectify it,
however belatedly, by explicitly allowing either of the two schemes for
declaring C names in headers.
</p>

<p><i>[Sydney: This issue has been debated many times, and will
  certainly have to be discussed in full committee before any action
  can be taken.  However, the preliminary sentiment of the LWG was in
  favor of the change.  (6 yes, 0 no, 2 abstain) Robert Klarer
  suggests that we might also want to undeprecate the
  C-style <tt>.h</tt> headers.]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add to 17.6.1.2 [headers], para. 4:
</p>

<blockquote><p>
Except as noted in clauses 18 through 27 and Annex D, the contents of each
header <i>cname</i> shall be the same as that of the corresponding header
<i>name.h</i>, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause
7), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause
7), as appropriate, as if by inclusion. In the C++ Standard Library, however,
the declarations <del>and definitions</del> (except for names which are defined
as macros in C) are within namespace scope (3.3.5) of the namespace std. 
<ins>It is unspecified whether these names are first declared within the global
namespace scope and are then injected into namespace std by explicit
using-declarations (7.3.3 [namespace.udecl]).</ins>
</p></blockquote>

<p>
Change D.7 [depr.c.headers], para. 2-3:
</p>

<blockquote>
<p>
-2- Every C header, each of which has a name of the form <i>name.h</i>, behaves
as if each name placed in the Standard library namespace by the corresponding
<i>cname</i> header is <del>also</del> placed within the <ins>global</ins>
namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed
by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del>
<ins>It is unspecified whether these names are first declared or defined within
namespace scope (3.3.6 [basic.scope.namespace]) of the namespace
<tt>std</tt> and are then injected into the global namespace scope by explicit
using-declarations (7.3.3 [namespace.udecl]).</ins>
</p>
<p>
-3- [<i>Example:</i> The header <tt>&lt;cstdlib&gt;</tt> <ins>assuredly</ins>
provides its declarations and definitions within the namespace <tt>std</tt>.
<ins>It may also provide these names within the global namespace.</ins> The
header <tt>&lt;stdlib.h&gt;</tt> <del>makes these available also in</del>
<ins>assuredly provides the same declarations and definitions within</ins> the
global namespace, much as in the C Standard. <ins>It may also provide these
names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
</p>
</blockquote>





<hr>
<h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
<p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dag Henriksson <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The constructor from unsigned long says it initializes "the first M
bit positions to the corresponding bit values in val. M is the smaller
of N and the value CHAR_BIT * sizeof(unsigned long)."
</p>

<p>
Object-representation vs. value-representation strikes again. CHAR_BIT *
sizeof (unsigned long) does not give us the number of bits an unsigned long
uses to hold the value. Thus, the first M bit position above is not
guaranteed to have any corresponding bit values in val.
</p>


<p><b>Proposed resolution:</b></p>
<p>In 20.5.1 [bitset.cons] paragraph 2, change "M is the smaller of
  N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
  "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
  the value representation (section 3.9 [basic.types]) of <tt>unsigned
  long</tt>."
</p>





<hr>
<h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</h3>
<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Ben Hutchings <b>Opened:</b> 2004-04-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The second parameters of the non-default constructor and of the open
member function for basic_fstream, named "mode", are optional
according to the class declaration in 27.8.1.11 [lib.fstream].  The
specifications of these members in 27.8.1.12 [lib.fstream.cons] and
27.8.1.13 lib.fstream.members] disagree with this, though the
constructor declaration has the "explicit" function-specifier implying
that it is intended to be callable with one argument.
</p>


<p><b>Proposed resolution:</b></p>
<p>In 27.9.1.15 [fstream.cons], change</p>
<pre>  explicit basic_fstream(const char* s, ios_base::openmode mode); 
</pre>
<p>to</p>
<pre>  explicit basic_fstream(const char* s,
                         ios_base::openmode mode = ios_base::in|ios_base::out);
</pre>
<p>In 27.9.1.17 [fstream.members], change</p>
<pre>  void open(const char*s, ios_base::openmode mode); 
</pre>
<p>to</p>
<pre>  void open(const char*s,
            ios_base::openmode mode = ios_base::in|ios_base::out);
</pre>





<hr>
<h3><a name="461"></a>461. time_get hard or impossible to implement</h3>
<p><b>Section:</b> 22.4.5.1.2 [locale.time.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-03-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Template time_get currently contains difficult, if not impossible,
requirements for do_date_order, do_get_time, and do_get_date. All require
the implementation to scan a field generated by the %x or %X conversion
specifier in strftime. Yes, do_date_order can always return no_order, but
that doesn't help the other functions. The problem is that %x can be
nearly anything, and it can vary widely with locales. It's horribly
onerous to have to parse "third sunday after Michaelmas in the year of
our Lord two thousand and three," but that's what we currently ask of
do_get_date. More practically, it leads some people to think that if
%x produces 10.2.04, we should know to look for dots as separators. Still
not easy.
</p>

<p>
Note that this is the <i>opposite</i> effect from the intent stated in the
footnote earlier in this subclause:
</p>

<blockquote><p>
"In other words, user confirmation is required for reliable parsing of
user-entered dates and times, but machine-generated formats can be
parsed reliably. This allows parsers to be aggressive about interpreting
user variations on standard formats."
</p></blockquote>

<p>
We should give both implementers and users an easier and more reliable
alternative: provide a (short) list of alternative delimiters and say
what the default date order is for no_order. For backward compatibility,
and maximum latitude, we can permit an implementation to parse whatever
%x or %X generates, but we shouldn't require it.
</p>


<p><b>Proposed resolution:</b></p>

<p><b>In the description:</b></p>
<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
        ios_base::iostate&amp; err, tm* t) const;
</pre>

<p>
2 Effects: Reads characters starting at suntil it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce the format specified by 'X', or until it
encounters an error or end of sequence.
</p>

<p><b>change:</b> 'X'</p>

<p><b>to:</b> "%H:%M:%S"</p>


<p>Change</p>
<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
        ios_base::iostate&amp; err, tm* t) const;

4 Effects: Reads characters starting at s until it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce the format specified by 'x', or until it
encounters an error.
</pre>

<p>to</p>
<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
        ios_base::iostate&amp; err, tm* t) const;
</pre>

<p>
4 Effects: Reads characters starting at s until it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce one of the following formats, or until it
encounters an error. The format depends on the value returned by
date_order() as follows:
</p>

<pre>        date_order()  format

        no_order      "%m/%d/%y"
        dmy           "%d/%m/%y"
        mdy           "%m/%d/%y"
        ymd           "%y/%m/%d"
        ydm           "%y/%d/%m"
</pre>
<p>
An implementation may also accept additional implementation-defined formats.
</p>

<p><i>[Redmond: agreed that this is a real problem.  The solution is
  probably to match C99's parsing rules.  Bill provided wording.
]</i></p>







<hr>
<h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
<p><b>Section:</b> 23.4.1 [vector], 23.6.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2004-05-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
<ol>
<li> add vector&lt;T&gt;::data() member (const and non-const version)
semantics: if( empty() ) return 0; else return buffer_;</li>
<li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
</ol>

<p>Rationale:</p>

<ul>
<li>To obtain a pointer to the vector's buffer, one must use either operator[]() (which can give undefined  behavior for empty vectors) or at() (which will then throw if the vector is empty).  </li>
<li>tr1::array&lt;T,sz&gt; already has a data() member</li>
<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
<li>Neither when the map is const.</li>
<li>when we want to make sure we don't add an element accidently</li>
<li>when it should be considered an error if a key is not in the map</li>
</ul>



<p><b>Proposed resolution:</b></p>
<p>In 23.4.1 [vector], add the following to the <tt>vector</tt>
  synopsis after "element access" and before "modifiers":</p>
<pre>  // <i>[lib.vector.data] data access</i>
  pointer       data();
  const_pointer data() const;
</pre>

<p>Add a new subsection of 23.4.1 [vector]:</p>
<blockquote>
<p>23.2.4.x <tt>vector</tt> data access</p>
<pre>   pointer       data();
   const_pointer data() const;
</pre>
<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
   range.  For a non-empty vector, data() == &amp;front().</p>
<p><b>Complexity:</b> Constant time.</p>
<p><b>Throws:</b> Nothing.</p>
</blockquote>

<p>In 23.6.1 [map], add the following to the <tt>map</tt>
synopsis immediately after the line for operator[]:</p>
<pre>  T&amp;       at(const key_type&amp; x);
  const T&amp; at(const key_type&amp; x) const;
</pre>

<p>Add the following to 23.6.1.2 [map.access]:</p>
<blockquote>
<pre>  T&amp;       at(const key_type&amp; x);
  const T&amp; at(const key_type&amp; x) const;
</pre>

<p><b>Returns:</b> A reference to the element whose key is equivalent
  to x, if such an element is present in the map.</p>
<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>

</blockquote>



<p><b>Rationale:</b></p>
<p>Neither of these additions provides any new functionality but the
  LWG agreed that they are convenient, especially for novices.  The
  exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
  was chosen to match <tt>vector::at</tt>.</p>





<hr>
<h3><a name="465"></a>465. Contents of &lt;ciso646&gt;</h3>
<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2004-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>C header &lt;iso646.h&gt; defines macros for some operators, such as
not_eq for !=.</p>

<p>Section 17.6.1.2 [headers] "Headers" says that except as noted in
clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
as the C header &lt;name.h&gt;. In particular, table 12 lists
&lt;ciso646&gt; as a C++ header.</p>

<p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
&lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>

<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
"Header &lt;iso646.h&gt;" says that the alternative tokens are not
defined as macros in &lt;ciso646&gt;, but does not mention the contents
of &lt;iso646.h&gt;.</p>

<p>I don't find any normative text to support C.2.2.2.</p>



<p><b>Proposed resolution:</b></p>
<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
  paragraph 6 (the one about functions must be functions):</p> 

<blockquote>
<p>Identifiers that are keywords or operators in C++ shall not be defined
as macros in C++ standard library headers. 
[Footnote:In particular, including the standard header &lt;iso646.h&gt;
or &lt;ciso646&gt; has no effect. </p>
</blockquote>

<p><i>[post-Redmond: Steve provided wording.]</i></p>







<hr>
<h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3>
<p><b>Section:</b> 21.2.3.1 [char.traits.specializations.char] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Table 37 describes the requirements on Traits::compare() in terms of
those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
to yield the same result as operator&lt;(char, char).
</p>

<p>
Most, if not all, implementations of char_traits&lt;char&gt;::compare()
call memcmp() for efficiency. However, the C standard requires both
memcmp() and strcmp() to interpret characters under comparison as
unsigned, regardless of the signedness of char. As a result, all
these char_traits implementations fail to meet the requirement
imposed by Table 37 on compare() when char is signed.
</p>


<p>Read email thread starting with c++std-lib-13499 for more. </p>


<p><b>Proposed resolution:</b></p>


<p>Change 21.1.3.1, p6 from</p>
<blockquote><p>
    The two-argument members assign, eq, and lt are defined identically
    to the built-in operators =, ==, and &lt; respectively.
</p></blockquote>
<p>to</p>
<blockquote><p>
  The two-argument member assign is defined identically to
  the built-in operator =. The two
  argument members eq and lt are defined identically to
  the built-in operators == and &lt; for type unsigned char.
</p></blockquote>

<p><i>[Redmond: The LWG agreed with this general direction, but we
  also need to change <tt>eq</tt> to be consistent with this change.
  Post-Redmond: Martin provided wording.]</i></p>






<hr>
<h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</h3>
<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>The program below is required to compile but when run it typically
produces unexpected results due to the user-defined conversion from
std::cout or any object derived from basic_ios to void*.
</p>

<pre>    #include &lt;cassert&gt;
    #include &lt;iostream&gt;

    int main ()
    {
        assert (std::cin.tie () == std::cout);
        // calls std::cout.ios::operator void*()
    }
</pre>


<p><b>Proposed resolution:</b></p>

<p>
Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
conversion operator to some unspecified type that is guaranteed not
to be convertible to any other type except for bool (a pointer-to-member
might be one such suitable type). In addition, make it clear that the
pointer type need not be a pointer to a complete type and when non-null,
the value need not be valid.
</p>

<p>Specifically, change in [lib.ios] the signature of</p>
<pre>    operator void*() const;
</pre>
<p>to</p>
<pre>    operator unspecified-bool-type() const;
</pre>
<p>and change [lib.iostate.flags], p1 from</p>
<pre>    operator void*() const;
</pre>
<p>to</p>
<pre>operator unspecified-bool-type() const;

     -1- Returns: if fail() then a value that will evaluate false in a
      boolean context; otherwise a value that will evaluate true in a
      boolean context. The value type returned shall not be
      convertible to int.

     -2- [Note: This conversion can be used in contexts where a bool
      is expected (e.g., an if condition); however, implicit
      conversions (e.g., to int) that can occur with bool are not
      allowed, eliminating some sources of user error. One possible
      implementation choice for this type is pointer-to-member.  - end
      note]
</pre>

<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>

<p><i>[Lillehammer: Doug provided revised wording for
  "unspecified-bool-type".]</i></p>
 







<hr>
<h3><a name="469"></a>469. vector&lt;bool&gt; ill-formed relational operators</h3>
<p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The overloads of relational operators for vector&lt;bool&gt; specified
in [lib.vector.bool] are redundant (they are semantically identical
to those provided for the vector primary template) and may even be
diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
in c++std-lib-13647).
</p>



<p><b>Proposed resolution:</b></p>
<p>
Remove all overloads of overloads of relational operators for
vector&lt;bool&gt; from [lib.vector.bool].
</p>




<hr>
<h3><a name="471"></a>471. result of what() implementation-defined</h3>
<p><b>Section:</b> 18.8.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>[lib.exception] specifies the following:</p>
<pre>    exception (const exception&amp;) throw();
    exception&amp; operator= (const exception&amp;) throw();

    -4- Effects: Copies an exception object.
    -5- Notes: The effects of calling what() after assignment
        are implementation-defined.
</pre>

<p>
First, does the Note only apply to the assignment operator? If so,
what are the effects of calling what() on a copy of an object? Is
the returned pointer supposed to point to an identical copy of
the NTBS returned by what() called on the original object or not?
</p>

<p>
Second, is this Note intended to extend to all the derived classes
in section 19? I.e., does the standard provide any guarantee for
the effects of what() called on a copy of any of the derived class
described in section 19?
</p>

<p>
Finally, if the answer to the first question is no, I believe it
constitutes a defect since throwing an exception object typically
implies invoking the copy ctor on the object. If the answer is yes,
then I believe the standard ought to be clarified to spell out
exactly what the effects are on the copy (i.e., after the copy
ctor was called).
</p>

<p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
  fuzzy too.]</i></p>


<p><i>[
Batavia: Howard provided wording.
]</i></p>


<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Eric concerned this is unimplementable, due to nothrow guarantees.
Suggested implementation would involve reference counting.
</p>
<p>
Is the implied reference counting subtle enough to call out a note on
implementation? Probably not.
</p>
<p>
If reference counting required, could we tighten specification further
to require same pointer value? Probably an overspecification, especially
if exception classes defer evalutation of final string to calls to
what().
</p>
<p>
Remember issue moved open and not resolved at Batavia, but cannot
remember who objected to canvas a disenting opinion - please speak up if
you disagree while reading these minutes!
</p>
<p>
Move to Ready as we are accepting words unmodified.
</p>
</blockquote>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
The issue was pulled from Ready.  It needs to make clear that only homogenous copying
is intended to be supported, not coping from a derived to a base.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Howard supplied the following replacement wording
for paragraph 7 of the proposed resolution:
</p>
<blockquote>
<ins>-7- <i>Postcondition:</i> <tt>what()</tt> shall return the same NTBS
  as would be obtained by using <tt>static_cast</tt>
  to cast the rhs to the same types as the lhs
  and then calling <tt>what()</tt> on that possibly sliced object.</ins>
</blockquote>
<p>
Pete asks what "the same NTBS" means.
</p>
</blockquote>

<p><i>[
2009-07-30 Niels adds:
]</i></p>


<blockquote>
Further discussion in the thread starting with c++std-lib-24512.
</blockquote>

<p><i>[
2009-09-24 Niels provided updated wording:
]</i></p>


<blockquote>
<p>
I think the resolution should at least guarantee
that the result of <tt>what()</tt> is independent of whether the compiler does
copy-elision. And for any class derived from <tt>std::excepion</tt> that has a
constructor that allows specifying a <tt>what_arg</tt>, it should make sure that
the text of a user-provided <tt>what_arg</tt> is preserved, when the object is
copied. Note that all the implementations I've tested already appear to
satisfy the proposed resolution, including MSVC 2008 SP1, Apache
stdcxx-4.2.1, GCC 4.1.2, GCC 4.3.2, and CodeGear C++ 6.13.
</p>
<p>
The proposed resolution was updated with help from Daniel Kr�gler;
the update aims to clarify that the proposed postcondition only
applies to homogeneous copying.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready after inserting "publicly accessible" in two places.
</blockquote>



<p><b>Proposed resolution:</b></p>

<p>
Change 18.8.1 [exception] to:
</p>

<blockquote>
<p>
-1- The class <tt>exception</tt> defines the base class for the types of
objects thrown as exceptions by C++ standard library components, and
certain expressions, to report errors detected during program execution.
</p>
<p><ins>
Each standard library class <tt>T</tt> that derives from class
<tt>exception</tt> shall have a publicly accessible copy constructor and a publicly accessible copy assignment
operator that do not exit with an exception. These member functions
shall preserve the following postcondition: If two objects <i>lhs</i>
and <i>rhs</i> both have dynamic type <tt>T</tt>, and <i>lhs</i> is a
copy of <i>rhs</i>, then <tt>strcmp(<i>lhs</i>.what(),
<i>rhs</i>.what()) == 0</tt>.
</ins></p>
<p>
 ...
</p>

<pre>exception(const exception&amp; <ins>rhs</ins>) throw();
exception&amp; operator=(const exception&amp; <ins>rhs</ins>) throw();</pre>

<blockquote>
<p>
-4- <i>Effects:</i> Copies an exception object.
</p>
<p>
<del> -5- <i>Remarks:</i> The effects of calling <tt>what()</tt> after assignment
are implementation-defined.</del>
</p>
<p>
<ins>-5- <i>Postcondition:</i>
	If <tt>*this</tt>
	and <i>rhs</i> both have dynamic type <tt>exception</tt>
	then <tt>strcmp(what(), <i>rhs</i>.what()) == 0</tt>.</ins>
</p>

</blockquote>

</blockquote>





<hr>
<h3><a name="473"></a>473. underspecified ctype calls</h3>
<p><b>Section:</b> 22.4.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Most ctype member functions come in two forms: one that operates
on a single character at a time and another form that operates
on a range of characters. Both forms are typically described by
a single Effects and/or Returns clause.
</p>
<p>
The Returns clause of each of the single-character non-virtual forms
suggests that the function calls the corresponding single character
virtual function, and that the array form calls the corresponding
virtual array form. Neither of the two forms of each virtual member
function is required to be implemented in terms of the other.
</p>
<p>
There are three problems:
</p>
<p>
1. One is that while the standard does suggest that each non-virtual
member function calls the corresponding form of the virtual function,
it doesn't actually explicitly require it.
</p>
<p>
Implementations that cache results from some of the virtual member
functions for some or all values of their arguments might want to
call the array form from the non-array form the first time to fill
the cache and avoid any or most subsequent virtual calls. Programs
that rely on each form of the virtual function being called from
the corresponding non-virtual function will see unexpected behavior
when using such implementations.
</p>
<p>
2. The second problem is that either form of each of the virtual
functions can be overridden by a user-defined function in a derived
class to return a value that is different from the one produced by
the virtual function of the alternate form that has not been
overriden.
</p>
<p>
Thus, it might be possible for, say, ctype::widen(c) to return one
value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
wc to another value. This is almost certainly not intended. Both
forms of every function should be required to return the same result
for the same character, otherwise the same program using an
implementation that calls one form of the functions will behave
differently than when using another implementation that calls the
other form of the function "under the hood."
</p>
<p>
3. The last problem is that the standard text fails to specify whether
one form of any of the virtual functions is permitted to be implemented
in terms of the other form or not, and if so, whether it is required
or permitted to call the overridden virtual function or not.
</p>
<p>
Thus, a program that overrides one of the virtual functions so that
it calls the other form which then calls the base member might end
up in an infinite loop if the called form of the base implementation
of the function in turn calls the other form.
</p>
<p>
Lillehammer: Part of this isn't a real problem. We already talk about
caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
each other, so users don't know which ones to override to avoid avoid
infinite loops.</p>

<p>This is a problem for all facet virtuals, not just ctype virtuals,
so we probably want a blanket statement in clause 22 for all
facets. The LWG is leaning toward a blanket prohibition, that a
facet's virtuals may never call each other. We might want to do that
in clause 27 too, for that matter. A review is necessary.  Bill will
provide wording.</p>

<p><i>[
2009-07 Frankfurt, Howard provided wording directed by consensus.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add paragraph 3 to 22.4 [locale.categories]:
</p>

<blockquote><ins>
-3- Within this clause it is unspecified if one virtual function calls another
virtual function.
</ins></blockquote>



<p><b>Rationale:</b></p>
<p>
We are explicitly not addressing bullet
item #2, thus giving implementors more latitude. Users will have to
override both virtual functions, not just one.
</p>




<hr>
<h3><a name="474"></a>474. confusing Footnote 297</h3>
<p><b>Section:</b> 27.7.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>
I think Footnote 297 is confused. The paragraph it applies to seems
quite clear in that widen() is only called if the object is not a char
stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
value of widen(c) is otherwise.
</p>


<p><b>Proposed resolution:</b></p>
<p>
I propose to strike the Footnote.
</p>




<hr>
<h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
<p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Opened:</b> 2004-07-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is not clear whether the function object passed to for_each is allowed to
modify the elements of the sequence being iterated over.
</p>

<p>
for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
Non-modifying sequence operations". 'Non-modifying sequence operation' is
never defined.
</p>

<p>
25(5) says: "If an algorithm's Effects section says that a value pointed to
by any iterator passed as an argument is modified, then that algorithm has
an additional type requirement: The type of that argument shall satisfy the
requirements of a mutable iterator (24.1)."
</p>

<p>for_each's Effects section does not mention whether arguments can be
modified:</p>

<blockquote><p>
  "Effects: Applies f to the result of dereferencing every iterator in the
   range [first, last), starting from first and proceeding to last - 1."
</p></blockquote>

<p>
Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
the sense that neither the algorithms themselves nor the function objects
passed to the algorithms may modify the sequences or elements in any way.
This DR affects only for_each.
</p>

<p>
We suspect that for_each's classification in "non-modifying sequence
operations" means that the algorithm itself does not inherently modify the
sequence or the elements in the sequence, but that the function object
passed to it may modify the elements it operates on. 
</p>

<p>
The original STL document by Stepanov and Lee explicitly prohibited the
function object from modifying its argument.
The "obvious" implementation of for_each found in several standard library 
implementations, however, does not impose this restriction.
As a result, we suspect that the use of for_each with function objects that modify
their arguments is wide-spread. 
If the restriction was reinstated, all such code would become non-conforming.
Further, none of the other algorithms in the Standard
could serve the purpose of for_each (transform does not guarantee the order in
which its function object is called). 
</p>

<p>
We suggest that the standard be clarified to explicitly allow the function object 
passed to for_each modify its argument.</p>



<p><b>Proposed resolution:</b></p>
<p>Add a nonnormative note to the Effects in 25.2.4 [alg.foreach]: If
the type of 'first' satisfies the requirements of a mutable iterator,
'f' may apply nonconstant functions through the dereferenced iterators
passed to it.
</p>



<p><b>Rationale:</b></p>
<p>The LWG believes that nothing in the standard prohibits function
  objects that modify the sequence elements. The problem is that
  for_each is in a secion entitled "nonmutating algorithms", and the
  title may be confusing.  A nonnormative note should clarify that.</p>





<hr>
<h3><a name="478"></a>478. Should forward iterator requirements table have a line for r-&gt;m?</h3>
<p><b>Section:</b> 24.2.5 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
<p><b>Discussion:</b></p>
<p>
The Forward Iterator requirements table contains the following:
</p>
<pre> expression  return type         operational  precondition
                                  semantics
  ==========  ==================  ===========  ==========================
  a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
              otherwise const U&amp;

  r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
</pre>

<p>The second line may be unnecessary.  Paragraph 11 of
  [lib.iterator.requirements] says:
</p>

<blockquote><p>
   In the following sections, a and b denote values of type const X, n
   denotes a value of the difference type Distance, u, tmp, and m
   denote identifiers, r denotes a value of X&amp;, t denotes a value of
   value type T, o denotes a value of some type that is writable to
   the output iterator.
</p></blockquote>

<p>
Because operators can be overloaded on an iterator's const-ness, the
current requirements allow iterators to make many of the operations
specified using the identifiers a and b invalid for non-const
iterators.</p>

<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>


<p><b>Proposed resolution:</b></p>

<p>Remove the "r-&gt;m" line from the Forward Iterator requirements
table. Change</p>
<blockquote><p>
    "const X"
</p></blockquote>

<p> to </p>

<blockquote><p>
    "X or const X" 
</p></blockquote>

<p>in paragraph 11 of [lib.iterator.requirements].</p>




<p><b>Rationale:</b></p>
<p>
This is a defect because it constrains an lvalue to returning a modifiable lvalue.
</p>





<hr>
<h3><a name="482"></a>482. Swapping pairs</h3>
<p><b>Section:</b> 20.3.5 [pairs], 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2004-09-14 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>(Based on recent comp.std.c++ discussion)</p>

<p>Pair (and tuple) should specialize std::swap to work in terms of
std::swap on their components.  For example, there's no obvious reason
why swapping two objects of type pair&lt;vector&lt;int&gt;,
list&lt;double&gt; &gt; should not take O(1).</p>

<p><i>[Lillehammer: We agree it should be swappable.  Howard will
  provide wording.]</i></p>


<p><i>[
Post Oxford:  We got <tt>swap</tt> for <tt>pair</tt> but accidently
missed <tt>tuple</tt>.  <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Wording provided in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
</p>

<p><b>Rationale:</b></p>
<p>
Recommend <del>NAD</del><ins>Resolved</ins>, fixed by 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
</p>





<hr>
<h3><a name="488"></a>488. rotate throws away useful information</h3>
<p><b>Section:</b> 25.3.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2004-11-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
rotate takes 3 iterators:  first, middle and last which point into a
sequence, and rearranges the sequence such that the subrange [middle,
last) is now at the beginning of the sequence and the subrange [first,
middle) follows.  The return type is void. 
</p>

<p>
In many use cases of rotate, the client needs to know where the
subrange [first, middle) starts after the rotate is performed.  This
might look like: 
</p>
<pre>  rotate(first, middle, last);
  Iterator i = advance(first, distance(middle, last));
</pre>

<p>
Unless the iterators are random access, the computation to find the
start of the subrange [first, middle) has linear complexity.  However,
it is not difficult for rotate to return this information with
negligible additional computation expense.  So the client could code: 
</p>
<pre>  Iterator i = rotate(first, middle, last);
</pre>

<p>
and the resulting program becomes significantly more efficient.
</p>

<p>
While the backwards compatibility hit with this change is not zero, it
is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
a significant benefit to the change. 
</p>



<p><b>Proposed resolution:</b></p>
<p>In 25 [algorithms] p2, change:</p>

<blockquote><pre>  template&lt;class ForwardIterator&gt;
    <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
                ForwardIterator last);
</pre></blockquote>

<p>In 25.3.11 [alg.rotate], change:</p>

<blockquote><pre>  template&lt;class ForwardIterator&gt;
    <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
                ForwardIterator last);
</pre></blockquote>

<p>In 25.3.11 [alg.rotate] insert a new paragraph after p1:</p>

<blockquote>
<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
</blockquote>

<p><i>[
The LWG agrees with this idea, but has one quibble: we want to make
sure not to give the impression that the function "advance" is
actually called, just that the nth iterator is returned.  (Calling
advance is observable behavior, since users can specialize it for
their own iterators.)  Howard will provide wording.
]</i></p>


<p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>


<p><i>[
Toronto: moved to Ready.
]</i></p>







<hr>
<h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-01-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>It appears that there are no requirements specified for many of the
template parameters in clause 22. It looks like this issue has never
come up, except perhaps for Facet.</p>

<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
either, which is the wording that allows requirements on template
parameters to be identified by name.</p>

<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
changed to cover clause 22. A better change, which will cover us in
the future, would be to say that it applies to all the library
clauses. Then if a template gets added to any library clause we are
covered.</p>

<p>charT, InputIterator, and other names with requirements defined
elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
But there are a few template arguments names which I don't think have
requirements given elsewhere:</p>

<ul>
<li>internT and externT.  The fix is to add wording saying that internT
and externT must meet the same requirements as template arguments
named charT.</li>

<li>stateT.  I'm not sure about this one. There already is some wording,
but it seems a bit vague.</li>

<li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
rename "Intl" to "International". The name is important because other
text identifies the requirements for the name International but not
for Intl.</li>
</ul>

<p><b>Proposed resolution:</b></p>
<p>Change 17.5.2.1 [type.descriptions], paragraph 1, from:</p>
<blockquote><p>
The Requirements subclauses may describe names that are used to
specify constraints on template arguments.153) These names are used in
clauses 20, 23, 25, and 26 to describe the types that may be supplied
as arguments by a C++ program when instantiating template components
from the library. 
</p></blockquote>
<p>to:</p>
<blockquote><p>
The Requirements subclauses may describe names that are used to
specify constraints on template arguments.153) These names are used in
library clauses to describe the types that may be supplied as
arguments by a C++ program when instantiating template components from
the library.
</p></blockquote>

<p>In the front matter of class 22, locales, add:</p>
<blockquote><p>
Template parameter types internT and externT shall meet the
requirements of charT (described in 21 [strings]).
</p></blockquote>


<p><b>Rationale:</b></p>
<p>
 Again, a blanket clause isn't blanket enough. Also, we've got a
 couple of names that we don't have blanket requirement statements
 for. The only issue is what to do about stateT. This wording is
 thin, but probably adequate.</p>





<hr>
<h3><a name="496"></a>496. Illegal use of "T" in vector&lt;bool&gt;</h3>
<p><b>Section:</b> 23.4.1 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> richard@ex-parrot.com <b>Opened:</b> 2005-02-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.4.1 [vector],
the non-template assign() function has the signature</p>

<pre>  void assign( size_type n, const T&amp; t );
</pre>

<p>The type, T, is not defined in this context.</p>


<p><b>Proposed resolution:</b></p>
<p>Replace "T" with "value_type".</p>





<hr>
<h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3>
<p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-03-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>

<blockquote>
<p>static const bool traps;<br>
-59- true if trapping is implemented for the type.204)
<br>
Footnote 204: Required by LIA-1.
</p>
</blockquote>

<p>It's not clear what is meant by "is implemented" here.</p>

<p>
In the context of floating point numbers it seems reasonable to expect
to be able to use traps to determine whether a program can "safely" use
infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
without causing a trap (i.e., on UNIX without having to worry about
getting a signal). When traps is true, I would expect any of the
operations in section 7 of IEEE 754 to cause a trap (and my program
to get a SIGFPE). So, for example, on Alpha, I would expect traps
to be true by default (unless I compiled my program with the -ieee
option), false by default on most other popular architectures,
including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
traps to be explicitly enabled by the program.
</p>

<p>
Another possible interpretation of p59 is that traps should be true
on any implementation that supports traps regardless of whether they
are enabled by default or not. I don't think such an interpretation
makes the traps member very useful, even though that is how traps is
implemented on several platforms. It is also the only way to implement
traps on platforms that allow programs to enable and disable trapping
at runtime.
</p>


<p><b>Proposed resolution:</b></p>
<p>Change p59 to read:</p>
<blockquote><p>True if, at program startup, there exists a value of the type that
  would cause an arithmetic operation using that value to trap.</p></blockquote>


<p><b>Rationale:</b></p>
<p>
 Real issue, since trapping can be turned on and off. Unclear what a
 static query can say about a dynamic issue. The real advice we should
 give users is to use cfenv for these sorts of queries. But this new
 proposed resolution is at least consistent and slightly better than
 nothing.</p>





<hr>
<h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
<p><b>Section:</b> 25.3.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Sean Parent, Joe Gottman <b>Opened:</b> 2005-05-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Problem:
The iterator requirements for partition() and stable_partition() [25.2.12]
are listed as BidirectionalIterator, however, there are efficient algorithms
for these functions that only require ForwardIterator that have been known
since before the standard existed. The SGI implementation includes these (see
<a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
and
<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
</p>

<p><i>[
2009-04-30 Alisdair adds:
]</i></p>


<blockquote>
<p>
Now we have concepts this is easier to express!
</p>
<p>
Proposed resolution:
</p>
<p>
Add the following signature to:
</p>
<p>
Header <tt>&lt;algorithm&gt;</tt> synopsis  [algorithms.syn]<br>
p3 Partitions 25.3.13 [alg.partitions]
</p>
<blockquote><pre> template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred&gt;
   requires ShuffleIterator&lt;Iter&gt;
         &amp;&amp; CopyConstructible&lt;Pred&gt;
   Iter partition(Iter first, Iter last, Pred pred);
</pre></blockquote>

<p>
Update p3 Partitions 25.3.13 [alg.partitions]:
</p>

<blockquote>
<p>
<i>Complexity:</i> <del>At most <tt>(last - first)/2</tt> swaps. Exactly <tt>last - first</tt>
applications of the predicate
are done.</del>
<ins>
If <tt>Iter</tt> satisfies <tt>BidirectionalIterator</tt>, at most <tt>(last -
first)/2</tt> swaps. Exactly <tt>last - first</tt> applications of the predicate
are done.
</ins>
</p>
<p><ins>
If <tt>Iter</tt> merely satisfied <tt>ForwardIterator</tt> at most <tt>(last - first)</tt> swaps
are done. Exactly <tt>(last - first)</tt> applications of the predicate are done.
</ins></p>
</blockquote>

<p>
[Editorial note: I looked for existing precedent in how we might call out
distinct overloads overloads from a set of constrained templates, but there
is not much existing practice to lean on.   advance/distance were the only
algorithms I could find, and that wording is no clearer.]
</p>

</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Hinnant: if you want to partition your std::forward_list, you'll need
partition() to accept ForwardIterators.
</p>
<p>
No objection to Ready.
</p>
<p>
Move to Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 25.2.12 from </p>
<blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt; 
BidirectionalIterator partition(BidirectionalIterato r first, 
                                BidirectionalIterator last, 
                                Predicate pred); 
</pre></blockquote>
<p>to </p>
<blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt; 
ForwardIterator partition(ForwardIterator first, 
                          ForwardIterator last, 
                          Predicate pred); 
</pre></blockquote>
<p>Change the complexity from </p>

<blockquote><p>
At most (last - first)/2 swaps are done. Exactly (last - first) 
applications of the predicate are done. 
</p></blockquote>

<p>to </p>

<blockquote><p>
If ForwardIterator is a bidirectional_iterator, at most (last - first)/2 
swaps are done; otherwise at most (last - first) swaps are done. Exactly 
(last - first) applications of the predicate are done. 
</p></blockquote>



<p><b>Rationale:</b></p>
<p>
Partition is a "foundation" algorithm useful in many contexts (like sorting
as just one example) - my motivation for extending it to include forward
iterators is foward_list - without this extension you can't partition an foward_list
(without writing your own partition). Holes like this in the standard
library weaken the argument for generic programming (ideally I'd be able
to provide a library that would refine std::partition() to other concepts
without fear of conflicting with other libraries doing the same - but
that is a digression). I consider the fact that partition isn't defined
to work for ForwardIterator a minor embarrassment.
</p>

<p><i>[Mont Tremblant:  Moved to Open, request motivation and use cases by next meeting. Sean provided further rationale by post-meeting mailing.]</i></p>







<hr>
<h3><a name="505"></a>505. Result_type in random distribution requirements</h3>
<p><b>Section:</b> 26.5.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 17: Random distribution requirements
</p>
<p>
Row 1 requires that each random distribution provide a nested type "input_type";
this type denotes the type of the values that the distribution consumes.
</p>
<p>
Inspection of all distributions in [tr.rand.dist] reveals that each distribution
provides a second typedef ("result_type") that denotes the type of the values the
distribution produces when called.  
</p>


<p><b>Proposed resolution:</b></p>
<p>
It seems to me that this is also a requirement
for all distributions and should therefore be  indicated as such via a new second
row to this table 17:
</p>
<table border="1" cellpadding="5">
<tbody><tr><td>X::result_type</td><td>T</td><td>---</td><td>compile-time</td></tr>
</tbody></table>

<p><i>[
Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
]</i></p>







<hr>
<h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3>
<p><b>Section:</b> 26.5 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Paragraph 11 of [tr.rand.var] equires that the member template
</p>
<blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
</pre></blockquote>
<p>
return
</p>
<blockquote><pre>distribution()(e, value)
</pre></blockquote>
<p>
However, not all distributions have an operator() with a corresponding signature.
</p>

<p><i>[
Berlin:  As a working group we voted in favor of N1932 which makes this moot:
variate_generator has been eliminated.  Then in full committee we voted to give
this issue WP status (mistakenly).
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
We therefore  recommend that we insert the following precondition before paragraph 11:
</p>
<blockquote><p>
Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
</p></blockquote>





<hr>
<h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3>
<p><b>Section:</b> 26.5.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The fifth of these engines with predefined parameters, ranlux64_base_01,
appears to have an unintentional error for which there is a simple correction.
The two pre-defined  subtract_with_carry_01 engines are given as: 
</p>
<blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
</pre></blockquote>
<p>
We demonstrate below that ranlux64_base_01 fails to meet the intent of the
random number generation proposal, but that the simple correction to
</p>
<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
</pre></blockquote>
<p>
does meet the intent of defining well-known good parameterizations.
</p>
<p>
The ranlux64_base_01 engine as presented fails to meet the intent for
predefined engines, stated in proposal N1398 (section E):
</p>
<blockquote><p>
In order to make good random numbers available to a large number of library
users, this proposal not only defines generic random-number engines, but also
provides a number of predefined well-known good parameterizations for those.
</p></blockquote>
<p>
The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
long period and so meets this criterion.  This property makes it suitable for
use in the excellent discard_block  engines defined subsequently.  The proof
of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
as defined in [tr.rand.eng.sub1]).
</p>
<p>
The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
explicit factorization  would be a challenge).  In consequence, while it is
certainly possible for some seeding states that this engine would have a very
long period, it is not at all "well-known" that this is the case. The intent
in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
to deliver 48 random bits at a time rather than 24.
</p>


<p><b>Proposed resolution:</b></p>
<p>
To achieve this intended behavior, the correct template parameteriztion  would be:
</p>
<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
</pre></blockquote>
<p>
The sequence of mantissa bits delivered by this is isomorphic (treating each
double as having the  bits of two floats) to that delivered by ranlux_base_01.
</p>
<p>
<b>References:</b>
</p>
<ol>
<li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
</ol>

<p><i>[
Berlin: Voted to WP.  N1932 adopts the proposed resolution in 26.3.5,
just above paragraph 5.
]</i></p>







<hr>
<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
<p><b>Section:</b> 23.2.5 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue 371 deals with stability of multiset/multimap under insert and erase
(i.e. do they preserve the relative order in ranges of equal elements).
The same issue applies to unordered_multiset and unordered_multimap.
</p>
<p><i>[
Moved to open (from review):  There is no resolution.
]</i></p>


<p><i>[
Toronto:  We have a resolution now.  Moved to Review.  Some concern was noted
as to whether this conflicted with existing practice or not.  An additional
concern was in specifying (partial) ordering for an unordered container.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Wording for the proposed resolution is taken from the equivalent text for associative containers.
</p>

<p>
Change 23.2.5 [unord.req], Unordered associative containers, paragraph 6 to:
</p>

<blockquote><p>
An unordered associative container supports <i>unique</i> keys if it may 
contain at most one element for each key. Otherwise, it supports <i>equivalent 
keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support 
unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> 
support equivalent keys. In containers that support equivalent keys, elements 
with equivalent keys are adjacent to each other. <ins>For
<tt>unordered_multiset</tt> 
and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt> 
preserve the relative ordering of equivalent elements.</ins>
</p></blockquote>

<p>
Change 23.2.5 [unord.req], Unordered associative containers, paragraph 8 to:
</p>

<blockquote>
<p>The elements of an unordered associative container are organized into <i>
buckets</i>. Keys with the same hash code appear in the same bucket. The number 
of buckets is automatically increased as elements are added to an unordered 
associative container, so that the average number of elements per bucket is kept 
below a bound. Rehashing invalidates iterators, changes ordering between 
elements, and changes which buckets elements appear in, but does not invalidate 
pointers or references to elements. <ins>For <tt>unordered_multiset</tt> 
and <tt>unordered_multimap</tt>, rehashing 
preserves the relative ordering of equivalent elements.</ins></p>
</blockquote>






<hr>
<h3><a name="519"></a>519. Data() undocumented</h3>
<p><b>Section:</b> 23.3.1 [array], TR1 6.2.2 [tr.array.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add a new section, after 6.2.2.3:
</p>
<blockquote><pre>T*       data()
const T* data() const;
</pre></blockquote>
<p>
<b>Returns:</b> <tt>elems</tt>.
</p>
<p>
Change 6.2.2.4/2 to:
</p>
<blockquote><p>
In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
of <tt>data()</tt> is unspecified.
</p></blockquote>





<hr>
<h3><a name="520"></a>520. Result_of and pointers to data members</h3>
<p><b>Section:</b> 20.8.10.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the original proposal for binders, the return type of bind() when
called with a pointer to member data as it's callable object was
defined to be mem_fn(ptr); when Peter Dimov and I  unified the
descriptions of the TR1 function objects we hoisted the descriptions
of return types into the INVOKE pseudo-function and into result_of.
Unfortunately, we left pointer to member data out of result_of, so
bind doesn't have any specified behavior when called with a pointer
to  member data.
</p>


<p><b>Proposed resolution:</b></p>
<p><i>[
Pete and Peter will provide wording.
]</i></p>


<p>
In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
</p>
<ol start="3">
<li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
shall be <tt><i>cv</i> R&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
<tt>R</tt> otherwise.</li>
</ol>

<p><i>[
Peter provided wording.
]</i></p>







<hr>
<h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
<p><b>Section:</b> 20.8.4 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
derived from unary_function&lt;T, R&gt; if T is:
</p>
<blockquote><p>
a pointer to member function type with cv-qualifier cv and no arguments;
the type T1 is cv T* and R is the return type of the pointer to member function;
</p></blockquote>
<p>
The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
function. It should be a pointer to the class that T is a pointer to member of.
Like this:
</p>
<blockquote><p>
a pointer to a member function R T0::f() cv (where cv represents the member
function's cv-qualifiers); the type T1 is cv T0*
</p></blockquote>
<p>
Similarly, bullet item 2 in 2.1.2/4 should be:
</p>
<blockquote><p>
a pointer to a member function R T0::f(T2) cv (where cv represents the member
function's cv-qualifiers); the type T1 is cv T0*
</p></blockquote>


<p><b>Proposed resolution:</b></p>

<p>
Change bullet item 2 in 2.1.2/3:
</p>

<blockquote>
<ul>
<li>
a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return 
type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
(where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
</li>
</ul>
</blockquote>

<p>
Change bullet item 2 in 2.1.2/4:
</p>

<blockquote>
<ul>
<li>
a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and 
<tt>R</tt> is the return type of the pointer to member function</del>
<ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
</li>
</ul>
</blockquote>






<hr>
<h3><a name="522"></a>522. Tuple doesn't define swap</h3>
<p><b>Section:</b> 20.4 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Tuple doesn't define swap().  It should.
</p>
<p><i>[
Berlin: Doug to provide wording.
]</i></p>

<p><i>[
Batavia: Howard to provide wording.
]</i></p>

<p><i>[
Toronto: Howard to provide wording (really this time).
]</i></p>


<p><i>[
Bellevue:  Alisdair provided wording.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Add these signatures to 20.4 [tuple]
</p>

<blockquote><pre>template &lt;class... Types&gt;
  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
template &lt;class... Types&gt;
  void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
template &lt;class... Types&gt;
  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y); 
</pre></blockquote>

<p>
Add this signature to 20.4.2 [tuple.tuple]
</p>

<blockquote><pre>void swap(tuple&amp;&amp;);
</pre></blockquote>

<p>
Add the following two sections to the end of the tuple clauses
</p>

<blockquote>
<p>
20.3.1.7 tuple swap [tuple.swap]
</p>

<pre>void swap(tuple&amp;&amp; rhs); 
</pre>

<blockquote>
<p>
<i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
</p>
<p>
<i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
in <tt>rhs</tt>.
</p>
<p>
<i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
exception. 
</p>
</blockquote>

<p>
20.3.1.8 tuple specialized algorithms [tuple.special]
</p>

<pre>template &lt;class... Types&gt;
  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
template &lt;class... Types&gt;
  void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
template &lt;class... Types&gt;
  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y); 
</pre>

<blockquote>
<p>
<i>Effects:</i> x.swap(y)
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3>
<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This defect is also being discussed on the Boost developers list. The 
full discussion can be found here:
http://lists.boost.org/boost/2005/07/29546.php
</p>
<p>
-- Begin original message --
</p>
<p>
Also, I may have found another issue, closely related to the one under
discussion. It regards case-insensitive matching of named character
classes. The regex_traits&lt;&gt; provides two functions for working with
named char classes: lookup_classname and isctype. To match a char class
such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
bitmask. Later, you pass a char and the bitmask to isctype and get a
bool yes/no answer.
</p>
<p>
But how does case-insensitivity work in this scenario? Suppose we're
doing a case-insensitive match on [[:lower:]]. It should behave as if it
were [[:lower:][:upper:]], right? But there doesn't seem to be enough
smarts in the regex_traits interface to do this.
</p>
<p>
Imagine I write a traits class which recognizes [[:fubar:]], and the
"fubar" char class happens to be case-sensitive. How is the regex engine
to know that? And how should it do a case-insensitive match of a
character against the [[:fubar:]] char class? John, can you confirm this
is a legitimate problem?
</p>
<p>
I see two options:
</p>
<p>
1) Add a bool icase parameter to lookup_classname. Then,
lookup_classname( "upper", true ) will know to return lower|upper
instead of just upper.
</p>
<p>
2) Add a isctype_nocase function
</p>
<p>
I prefer (1) because the extra computation happens at the time the
pattern is compiled rather than when it is executed.
</p>
<p>
-- End original message --
</p>

<p>
For what it's worth, John has also expressed his preference for option 
(1) above.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="525"></a>525. type traits definitions not clear</h3>
<p><b>Section:</b> 20.7.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2005-07-11 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary">issues</a> in [meta.unary].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is not completely clear how the primary type traits deal with
cv-qualified types.  And several of the secondary type traits
seem to be lacking a definition.
</p>

<p><i>[
Berlin:  Howard to provide wording.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>.
A
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
provides more detail for motivation.
</p>


<p><b>Rationale:</b></p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
in the WP.





<hr>
<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
<p><b>Section:</b> 20.8.10.1.2 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2005-10-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The original bind proposal gives the guarantee that tr1::bind(f, t1, ..., tN) does not throw when the copy constructors of f, t1, ..., tN don't.
</p>

<p>
This guarantee is not present in the final version of TR1.
</p>

<p>
I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
</p>

<p><i>[
Berlin: not quite editorial, needs proposed wording.
]</i></p>

<p><i>[
Batavia:  Doug to translate wording to variadic templates.
]</i></p>


<p><i>[
Toronto:  We agree but aren't quite happy with the wording.  The "t"'s no
longer refer to anything.  Alan to provide improved wording.
]</i></p>



<p><i>[
Pre-Bellevue:  Alisdair provided wording.
]</i></p>


<p>
TR1 proposed resolution:
</p>

<blockquote>
<p>
In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2:
</p>
<blockquote><p>
<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
throws an exception.
</p></blockquote>

<p>
Add a new paragraph after p4:
</p>
<blockquote><p>
<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
throws an exception.
</p></blockquote>

</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In 20.8.10.1.2 [func.bind.bind], add a new paragraph after p2:
</p>

<blockquote>
<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
in the <tt>BoundArgs...</tt> pack expansion throws an exception. 
</blockquote>

<p>
In 20.8.10.1.2 [func.bind.bind], add a new paragraph after p4:
</p>

<blockquote>
<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
in the <tt>BoundArgs...</tt> pack expansion throws an exception. 
</blockquote>






<hr>
<h3><a name="530"></a>530. Must elements of a string be contiguous?</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-11-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
   that the elements of a vector must be stored in contiguous memory.
   Should the same also apply to <tt>basic_string</tt>?</p>

<p>We almost require contiguity already. Clause 23.6.4 [multiset]
  defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
  is a similar guarantee if we access the string's elements via the
  iterator interface.</p>

<p>Given the existence of <tt>data()</tt>, and the definition of
  <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
  I don't believe it's possible to write a useful and standard-
  conforming <tt>basic_string</tt> that isn't contiguous. I'm not
  aware of any non-contiguous implementation. We should just require
  it.
</p>


<p><b>Proposed resolution:</b></p>
<p>Add the following text to the end of 21.4 [basic.string],
paragraph 2. </p>

<blockquote>
  <p>The characters in a string are stored contiguously, meaning that if
  <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
  it obeys the identity
  <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
  for all <tt>0 &lt;= n &lt; s.size()</tt>.
  </p>
</blockquote>


<p><b>Rationale:</b></p>
<p>
Not standardizing this existing practice does not give implementors more
freedom.  We thought it might a decade ago.  But the vendors have spoken
both with their implementations, and with their voice at the LWG
meetings.  The implementations are going to be contiguous no matter what
the standard says.  So the standard might as well give string clients
more design choices.
</p>





<hr>
<h3><a name="531"></a>531. array forms of unformatted input functions</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The array forms of unformatted input functions don't seem to have well-defined
semantics for zero-element arrays in a couple of cases. The affected ones
(<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to
terminate when <tt>(n - 1)</tt> characters are stored, which obviously can
never be true when <tt>(n == 0)</tt> holds to start with. See
c++std-lib-16071.
</p>


<p><b>Proposed resolution:</b></p>
<p>
I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read:
</p>
            <ul>
                <li>
                    <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
                    are stored;
                </li>
            </ul>
<p>
Change 27.6.1.3, p9:
</p>

<blockquote><p>
If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
may throw <tt>ios_base::failure</tt> (27.4.4.3)).  In any case, <ins>if <tt>(n
&gt; 0)</tt> is true</ins> it then stores a null character into the next
successive location of the array.
</p></blockquote>

        <p>

and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:

        </p>
            <ul>
                <li>
                    <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
                    are stored (in which case the function calls
                    <tt>setstate(failbit)</tt>).
                </li>
            </ul>

        <p>

In addition, to clarify that <tt>istream::getline()</tt> must not store the
terminating NUL character unless the the array has non-zero size, Robert
Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:

        </p>
            <blockquote><p>

In any case, provided <tt>(n &gt; 0)</tt> is true, it then stores a null character
(using charT()) into the next successive location of the array.

            </p></blockquote>

<p><i>[
post-Redmond:  Pete noticed that the current resolution for <tt>get</tt> requires
writing to out of bounds memory when <tt>n == 0</tt>.  Martin provided fix.
]</i></p>







<hr>
<h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
<p><b>Section:</b> 20.9.10.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-11-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
says:
</p>
<blockquote><p>
If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
</p></blockquote>
<p>
but <tt>get_deleter</tt> is a free function!
</p>


<p><b>Proposed resolution:</b></p>
<p>
Therefore, I think should be:
</p>
<blockquote><p>
If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
</p></blockquote>





<hr>
<h3><a name="534"></a>534. Missing basic_string members</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2005-11-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
OK, we all know std::basic_string is bloated and already has way too
many members.  However, I propose it is missing 3 useful members that
are often expected by users believing it is a close approximation of the
container concept.  All 3 are listed in table 71 as 'optional'
</p>

<p>
i/  pop_back.
</p>

<p>
This is the one I feel most strongly about, as I only just discovered it
was missing as we are switching to a more conforming standard library
&lt;g&gt;
</p>

<p>
I find it particularly inconsistent to support push_back, but not
pop_back.
</p>

<p>
ii/ back.
</p>

<p>
There are certainly cases where I want to examine the last character of
a string before deciding to append, or to trim trailing path separators
from directory names etc.  *rbegin() somehow feels inelegant.
</p>

<p>
iii/ front
</p>

<p>
This one I don't feel strongly about, but if I can get the first two,
this one feels that it should be added as a 'me too' for consistency.
</p>

<p>
I believe this would be similarly useful to the data() member recently
added to vector, or at() member added to the maps.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the following members to definition of class template basic_string, 21.3p7
</p>
<blockquote><pre>void pop_back ()

const charT &amp; front() const
charT &amp; front()

const charT &amp; back() const
charT &amp; back()
</pre></blockquote>
<p>
Add the following paragraphs to basic_string description
</p>

<p>
21.3.4p5
</p>
<blockquote>
<pre>const charT &amp; front() const
charT &amp; front()
</pre>
<p>
<i>Precondition:</i> <tt>!empty()</tt>
</p>
<p>
<i>Effects:</i> Equivalent to <tt>operator[](0)</tt>.
</p>
</blockquote>

<p>
21.3.4p6
</p>
<blockquote>
<pre>const charT &amp; back() const
charT &amp; back()
</pre>
<p>
<i>Precondition:</i> <tt>!empty()</tt>
</p>
<p>
<i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>.
</p>
</blockquote>

<p>
21.3.5.5p10
</p>
<blockquote>
<pre>void pop_back ()
</pre>
<p>
<i>Precondition:</i> <tt>!empty()</tt>
</p>
<p>
<i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>.
</p>
</blockquote>

<p>
Update Table 71: (optional sequence operations)
Add basic_string to the list of containers for the following operations.
</p>
<blockquote><pre>a.front()
a.back()
a.push_back()
a.pop_back()
a[n]
</pre></blockquote>

<p><i>[
Berlin: Has support.  Alisdair provided wording.
]</i></p>






<hr>
<h3><a name="535"></a>535. std::string::swap specification poorly worded</h3>
<p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-12-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
std::string::swap currently says for effects and postcondition:
</p>

<blockquote>
<p>
<i>Effects:</i> Swaps the contents of the two strings.
</p>

<p>
<i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
<tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
</p>
</blockquote>

<p>
Specifying both Effects and Postcondition seems redundant, and the postcondition
needs to be made stronger. Users would be unhappy if the characters were not in
the same order after the swap.
</p>


<p><b>Proposed resolution:</b></p>
<blockquote>
<p>
<del><i>Effects:</i> Swaps the contents of the two strings.</del>
</p>

<p>
<i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
<tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
<del>were</del> <ins>was</ins> in <tt>*this</tt>.
</p>
</blockquote>





<hr>
<h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the most recent working draft, I'm still seeing:
</p>

<blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
</pre></blockquote>

<p>
and
</p>

<blockquote><pre>seekp(pos_type&amp; pos)

seekp(off_type&amp; off, ios_base::seekdir dir)
</pre></blockquote>

<p>
that is, by reference off and pos arguments.
</p>


<p><b>Proposed resolution:</b></p>
<p>
After 27.6.1.3p42 change:
</p>

<blockquote><pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
</pre></blockquote>

<p>
After 27.6.2.4p1 change:
</p>

<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
</pre></blockquote>

<p>
After 27.6.2.4p3 change:
</p>

<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
</pre></blockquote>





<hr>
<h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3>
<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I believe I botched the resolution of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
has WP status.
</p>

<p>
This talks about <tt>unique_copy</tt> requirements and currently reads:
</p>

<blockquote><p>
-5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
requirements of forward iterator then the value type of <tt>InputIterator</tt>
must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
</p></blockquote>

<p>
The problem (which Paolo discovered) is that when the iterators are at their
most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
<tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt> (for the most efficient implementation).  However this
proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
This latter requirement does not necessarily imply that you can:
</p>

<blockquote><pre>*<i>first</i> = *<i>first</i>;
</pre></blockquote>


<p><b>Proposed resolution:</b></p>
<blockquote><p>
-5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
shall
be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
requirements of forward iterator then the <del>value type</del> 
<ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
Otherwise CopyConstructible is not required.
</p></blockquote>





<hr>
<h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
<p><b>Section:</b> 26.7.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Marc Schoolderman <b>Opened:</b> 2006-02-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are some problems in the definition of partial_sum and
adjacent_difference in 26.4 [lib.numeric.ops]
</p>

<p>
Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
specifies the effects clause as;
</p>

<blockquote><p>
Assigns to every element referred to by iterator <tt>i</tt> in the range
<tt>[result,result + (last - first))</tt> a value correspondingly equal to
</p>
<blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
</pre></blockquote>
</blockquote>

<p>
And similarly for BinaryOperation. Using just this definition, it seems
logical to expect that:
</p>


<blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
int  o_array[4];

std::partial_sum(i_array, i_array+4, o_array);
</pre></blockquote>

<p>
Is equivalent to
</p>

<blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
</pre></blockquote>

<p>
i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
<tt>int</tt>.
</p>

<p>
Yet all implementations I have tested produce 100, -56, 44, -112,
because they are using an accumulator of the <tt>InputIterator</tt>'s
<tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
</p>

<p>
The issue becomes more noticeable when the result of the expression <tt>*i +
*(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
<tt>value_type</tt>. In a contrived example:
</p>

<blockquote><pre>enum not_int { x = 1, y = 2 };
...
not_int e_array[4] = { x, x, y, y };
std::partial_sum(e_array, e_array+4, o_array);
</pre></blockquote>

<p>
Is it the intent that the operations happen in the <tt>input type</tt>, or in
the <tt>result type</tt>?
</p>

<p>
If the intent is that operations happen in the <tt>result type</tt>, something
like this should be added to the "Requires" clause of 26.4.3/4
[lib.partial.sum]:
</p>

<blockquote><p>
The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
(23.1) types.
</p></blockquote>

<p>
(As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
[lib.inner.product].)
</p>

<p>
The "auto initializer" feature proposed in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
is not required to
implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
obtained by using the <tt>std::plus&lt;&gt;</tt> function object.
</p>

<p>
If the intent is that operations happen in the <tt>input type</tt>, then
something like this should be added instead;
</p>

<blockquote><p>
The type of *first shall meet the requirements of
<tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
convertible to this type.
</p></blockquote>

<p>
The 'widening' behaviour can then be obtained by writing a custom proxy
iterator, which is somewhat involved.
</p>

<p>
In both cases, the semantics should probably be clarified.
</p>

<p>
26.4.4 [lib.adjacent.difference] is similarly underspecified, although
all implementations seem to perform operations in the 'result' type:
</p>

<blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
int o_array[4];

std::adjacent_difference(i_array, i_array+4, o_array);
</pre></blockquote>

<p>
o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
</p>

<p>
In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
<tt>value_type</tt>; it can be brought in line with the rest of 26.4
[lib.numeric.ops] by adding the following to 26.4.4/2
[lib.adjacent.difference]:
</p>

<blockquote><p>
The type of <tt>*first</tt> shall meet the requirements of
<tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
</p></blockquote>
<p><i>[
Berlin: Giving output iterator's value_types very controversial. Suggestion of
adding signatures to allow user to specify "accumulator".
]</i></p>


<p><i>[
Bellevue:
]</i></p>


<blockquote>
The intent of the algorithms is to perform their calculations using the type of the input iterator.
Proposed wording provided.
</blockquote>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
We did not agree that the proposed resolution was correct. For example,
when the arguments are types <tt>(float*, float*, double*)</tt>, the
highest-quality solution would use double as the type of the
accumulator. If the intent of the wording is to require that the type of
the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording
should specify it.
</blockquote>

<p><i>[
2009-05-09 Alisdair adds:
]</i></p>


<blockquote>
<p>
Now that we have the facility, the 'best' accumulator type could probably be
deduced as:
</p>
<blockquote><pre>std::common_type&lt;InIter::value_type, OutIter::reference&gt;::type
</pre></blockquote>
<p>
This type would then have additional requirements of constructability and
incrementability/assignability.
</p>
<p>
If this extracting an accumulator type from a pair/set of iterators (with
additional requirements on that type) is a problem for multiple functions,
it might be worth extracting into a SharedAccumulator concept or similar.
</p>
<p>
I'll go no further in writing up wording now, until the group gives a
clearer indication of preferred direction.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
The proposed resolution isn't quite right. For example, "the type of
*first" should be changed to "iterator::value_type" or similar. Daniel
volunteered to correct the wording.
</blockquote>

<p><i>[
2009-07-29 Daniel corrected wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>



<ol>
<li>
<p>
Change 26.7.3 [partial.sum]/1 as indicated:
</p>

<blockquote>
<p>
<i>Effects:</i> <ins>Let <tt>VT</tt> be <tt>InputIterator</tt>'s value type. For a nonempty range,
initializes an accumulator <tt>acc</tt> of type <tt>VT</tt> with <tt>*first</tt> and performs
<tt>*result = acc</tt>. For every iterator <tt>i</tt> in <tt>[first + 1, last)</tt> in order, <tt>acc</tt> is then
modified by <tt>acc = acc + *i</tt> or <tt>acc = binary_op(acc, *i)</tt> and is assigned
to <tt>*(result + (i - first))</tt>.</ins> <del>Assigns to every element referred to by
iterator <tt>i</tt> in the range <tt>[result,result + (last - first))</tt> a value
correspondingly
equal to</del>
</p>

<blockquote><pre><del>
((...(*first + *(first + 1)) + ...) + *(first + (i - result)))
</del></pre></blockquote>

<p><del>
or
</del></p>

<blockquote><pre><del>
binary_op(binary_op(...,
   binary_op(*first, *(first + 1)),...), *(first + (i - result)))
</del></pre></blockquote>
</blockquote>
</li>

<li>
<p>
Change 26.7.3 [partial.sum]/3 as indicated:
</p>

<blockquote>
<i>Complexity:</i> Exactly <tt><ins>max(</ins>(last - first) - 1<ins>, 0)</ins></tt>
applications
of <tt><del>binary_op</del></tt><ins>the binary operation</ins>.
</blockquote>
</li>

<li>
<p>
Change 26.7.3 [partial.sum]/4 as indicated:
</p>

<blockquote>
<i>Requires:</i> <ins><tt>VT</tt> shall be constructible from the type of <tt>*first</tt>, the result of
<tt>acc + *i</tt> or <tt>binary_op(acc, *i)</tt> shall be implicitly convertible to <tt>VT</tt>, and
the result of the expression <tt>acc</tt> shall be writable to the <tt>result</tt>
output iterator.</ins> In the ranges <tt>[first,last]</tt> and
<tt>[result,result + (last - first)]</tt> [..]
</blockquote>
</li>

<li>
<p>
Change 26.7.4 [adjacent.difference]/1 as indicated:
</p>

<blockquote>
<p>
<i>Effects:</i> <ins>Let <tt>VT</tt> be <tt>InputIterator</tt>'s value type. For a nonempty range,
initializes an accumulator <tt>acc</tt> of type <tt>VT</tt> with <tt>*first</tt> and performs
<tt>*result = acc</tt>. For every iterator <tt>i</tt> in <tt>[first + 1, last)</tt> in order,
initializes a
value <tt>val</tt> of type <tt>VT</tt> with <tt>*i</tt>, assigns the result of <tt>val - acc</tt> or
<tt>binary_op(val, acc)</tt>
to <tt>*(result + (i - first))</tt> and modifies <tt>acc = std::move(val)</tt>.</ins>
<del>Assigns to every element referred to by iterator <tt>i</tt> in the range
<tt>[result + 1,
result + (last - first))</tt> a value correspondingly equal to</del>
</p>

<blockquote><pre><del>
*(first + (i - result)) - *(first + (i - result) - 1)
</del></pre></blockquote>

<p><del>
or
</del></p>

<blockquote><pre><del>
binary_op(*(first + (i - result)), *(first + (i - result) - 1)).
</del></pre></blockquote>

<p><del>
result gets the value of *first.</del>
</p>
</blockquote>
</li>

<li>
<p>
Change 26.7.4 [adjacent.difference]/2 as indicated:
</p>

<blockquote>
<i>Requires:</i> <ins><tt>VT</tt> shall be <tt>MoveAssignable</tt> ([moveassignable])
and shall be
constructible from the type of <tt>*first</tt>. The result
of the expression <tt>acc</tt> and the result of the expression <tt>val - acc</tt> or
<tt>binary_op(val, acc)</tt>
shall be writable to the <tt>result</tt> output iterator.</ins> In the ranges
<tt>[first,last]</tt> [..]
</blockquote>
</li>

<li>
<p>
Change 26.7.4 [adjacent.difference]/5 as indicated:
</p>

<blockquote>
<i>Complexity:</i> Exactly <tt><ins>max(</ins>(last - first) - 1<ins>, 0)</ins></tt>
applications
of <del><tt>binary_op</tt></del><ins>the binary operation</ins>.
</blockquote>
</li>
</ol>








<hr>
<h3><a name="540"></a>540. shared_ptr&lt;void&gt;::operator*()</h3>
<p><b>Section:</b> 20.9.10.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
that talks about the operator*() member function of shared_ptr:
</p>

<blockquote><p>
  Notes: When T is void, attempting to instantiate this member function
  renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
  does not necessarily result in instantiating this member function.
  --end note]
</p></blockquote>

<p>
with the requirement in temp.inst, p1:
</p>

<blockquote><p>
  The implicit instantiation of a class template specialization causes
  the implicit instantiation of the declarations, but not of the
  definitions...
</p></blockquote>

<p>
I assume that what the note is really trying to say is that
"instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
this member function." That is, that this function must not be
declared a member of shared_ptr&lt;void&gt;. Is my interpretation
correct?
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 2.2.3.5p6
</p>

<blockquote><p>
-6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
this member function renders the program ill-formed. [<i>Note:</i>
Instantiating <tt>shared_ptr&lt;void&gt;</tt> does not necessarily result in
instantiating this member function. <i>--end note</i>]</del> <ins>it is
unspecified whether this member function is declared or not, and if so, what its
return type is, except that the declaration (although not necessarily the
definition) of the function shall be well-formed.</ins>
</p></blockquote>






<hr>
<h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
<p><b>Section:</b> 20.9.10.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is the void specialization of the template assignment operator taking
a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
</p>
<p>
I.e., is this snippet well-formed:
</p>
<blockquote><pre>shared_ptr&lt;void&gt; p;
p.operator=&lt;void&gt;(p);
</pre></blockquote>

<p>
Gcc complains about auto_ptr&lt;void&gt;::operator*() returning a reference
to void. I suspect it's because shared_ptr has two template assignment
operators, one of which takes auto_ptr, and the auto_ptr template gets
implicitly instantiated in the process of overload resolution.
</p>

<p>
The only way I see around it is to do the same trick with auto_ptr&lt;void&gt;
operator*() as with the same operator in shared_ptr&lt;void&gt;.
</p>

<p>
PS Strangely enough, the EDG front end doesn't mind the code, even
though in a small test case (below) I can reproduce the error with
it as well.
</p>

<blockquote><pre>template &lt;class T&gt;
struct A { T&amp; operator*() { return *(T*)0; } };

template &lt;class T&gt;
struct B {
    void operator= (const B&amp;) { }
    template &lt;class U&gt;
    void operator= (const B&lt;U&gt;&amp;) { }
    template &lt;class U&gt;
    void operator= (const A&lt;U&gt;&amp;) { }
};

int main ()
{
    B&lt;void&gt; b;
    b.operator=&lt;void&gt;(b);
}
</pre></blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In [lib.memory] change:
</p>
<blockquote><pre>template&lt;class X&gt; class auto_ptr;
<ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
</pre></blockquote>

<p>
In [lib.auto.ptr]/2 add the following before the last closing brace:
</p>

<blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
{
public:
    typedef void element_type;
};
</pre></blockquote>






<hr>
<h3><a name="542"></a>542. shared_ptr observers</h3>
<p><b>Section:</b> 20.9.10.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Peter Dimov wrote:
To: C++ libraries mailing list
Message c++std-lib-15614
[...]
The intent is for both use_count() and unique() to work in a threaded environment.
They are intrinsically prone to race conditions, but they never return garbage.
</p>

<p>
This is a crucial piece of information that I really wish were
captured in the text. Having this in a non-normative note would
have made everything crystal clear to me and probably stopped
me from ever starting this discussion :) Instead, the sentence
in p12 "use only for debugging and testing purposes, not for
production code" very strongly suggests that implementations
can and even are encouraged to return garbage (when threads
are involved) for performance reasons.
</p>
<p>
How about adding an informative note along these lines:
</p>
<blockquote><p>
  Note: Implementations are encouraged to provide well-defined
  behavior for use_count() and unique() even in the presence of
  multiple threads.
</p></blockquote>
<p>
I don't necessarily insist on the exact wording, just that we
capture the intent.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.10.2.5 [util.smartptr.shared.obs] p12:
</p>
<blockquote><p>
[<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
debugging and testing purposes, not for production code.</del> --<i>end note</i>]
</p></blockquote>

<p>
Change 20.9.10.3.5 [util.smartptr.weak.obs] p3:
</p>
<blockquote><p>
[<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
debugging and testing purposes, not for production code.</del> --<i>end note</i>]
</p></blockquote>





<hr>
<h3><a name="543"></a>543. valarray slice default constructor</h3>
<p><b>Section:</b> 26.6.4 [class.slice] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2005-11-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
If one explicitly constructs a slice or glice with the default
constructor, does the standard require this slice to have any usable
state?  It says "creates a slice which specifies no elements", which
could be interpreted two ways:
</p>
<ol>
<li>There are no elements to which the slice refers (i.e. undefined).</li>
<li>The slice specifies an array with no elements in it (i.e. defined).</li>
</ol>
<p>
Here is a bit of code to illustrate:
</p>
<blockquote><pre>#include &lt;iostream&gt;
#include &lt;valarray&gt;

int main()
{
    std::valarray&lt;int&gt; v(10);
    std::valarray&lt;int&gt; v2 = v[std::slice()];
    std::cout &lt;&lt; "v[slice()].size() = " &lt;&lt; v2.size() &lt;&lt; '\n';
}
</pre></blockquote>

<p>
Is the behavior undefined?  Or should the output be:
</p>

<blockquote><pre>v[slice()].size() = 0
</pre></blockquote>

<p>
There is a similar question and wording for gslice at 26.3.6.1p1.
</p>


<p><b>Proposed resolution:</b></p>

<p><i>[Martin suggests removing the second sentence in 26.6.4.1 [cons.slice] as well.]</i></p>


<p>
Change 26.6.4.1 [cons.slice]:
</p>

<blockquote><p>
1 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt>
which specifies no elements.</del> <ins>The default constructor is equivalent to
<tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit
the declaration of arrays of slices. The constructor with arguments for a slice
takes a start, length, and stride parameter.
</p></blockquote>

<p>
Change 26.6.6.1 [gslice.cons]:
</p>

<blockquote><p>
1 - <del>The default constructor creates a <tt>gslice</tt> which specifies no
elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0,
valarray&lt;size_t&gt;(), valarray&lt;size_t&gt;())</tt>.</ins> The constructor
with arguments builds a <tt>gslice</tt> based on a specification of start,
lengths, and strides, as explained in the previous section.
</p></blockquote>






<hr>
<h3><a name="545"></a>545. When is a deleter deleted?</h3>
<p><b>Section:</b> 20.9.10.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
any, is destroyed. In principle there are two possibilities: it is destroyed
unconditionally whenever ~shared_ptr is executed (which, from an implementation
standpoint, means that the deleter is copied whenever the shared_ptr is copied),
or it is destroyed immediately after the owned pointer is destroyed (which, from
an implementation standpoint, means that the deleter object is shared between
instances). We should say which it is.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add after the first sentence of 20.9.10.2.11 [util.smartptr.getdeleter]/1:
</p>
<blockquote>
<p>
The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance
that owns <tt><i>d</i></tt>.
</p>
<p>
[<i>Note:</i> it is unspecified whether the pointer remains valid longer than that.
This can happen if the implementation doesn't destroy the deleter until all
<tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>]
</p>
</blockquote>





<hr>
<h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Assuming we adopt the
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
compatibility package from C99</a>  what should be the return type of the
following signature be:
</p>
<blockquote><pre>?  pow(float, int);
</pre></blockquote>
<p>
C++03 says that the return type should be <tt>float</tt>. 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
TR1</a> and C90/99 say the return type should be <tt>double</tt>.  This can put
clients into a situation where C++03 provides answers that are not as high
quality as C90/C99/TR1.  For example:
</p>
<blockquote><pre>#include &lt;math.h&gt;

int main()
{
    float x = 2080703.375F;
    double y = pow(x, 2);
}
</pre></blockquote>
<p>
Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
</p>

<blockquote><pre>y = 4329326534736.390625
</pre></blockquote>

<p>
which is exactly right.  While C++98/C++03 demands:
</p>

<blockquote><pre>y = 4329326510080.
</pre></blockquote>

<p>
which is only approximately right.
</p>

<p>
I recommend that C++0X adopt the mixed mode arithmetic already adopted by
Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
<tt>double</tt>.
</p>

<p><i>[
Kona (2007): Other functions that are affected by this issue include
<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
resolution appears above, rather than below, the heading "Proposed
resolution")
]</i></p>


<p><i>[
</i></p><p><i>
Howard, post Kona:
</i></p><i>
<blockquote>
<p>
Unfortunately I strongly disagree with a part of the resolution
from Kona.  I am moving from New to Open instead of to Review because I do not believe
we have consensus on the intent of the resolution.
</p>
<p>
This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
the second integral parameter in each of these signatures (from C99) is <b>not</b> a
<i>generic parameter</i> according to C99 7.22p2.  The corresponding C++ overloads are
intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
</p>
<p>
For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
<tt>nexttoward</tt>, nor the return type of this function, is in error.  I believe the
correct signature is:
</p>
<blockquote>
<pre>float nexttoward(float, long double);
</pre>
</blockquote>
<p>
which is what both the C++0X working paper and C99 state (as far as I currently understand).
</p>
<p>
This is really <b>only</b> about <tt>pow(float, int)</tt>.  And this is because C++98 took one
route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
</p>
</blockquote>
]</i><p></p>


<p><i>[
Bellevue:
]</i></p>


<blockquote>
This signature was not picked up from C99. Instead, if one types
pow(2.0f,2), the promotion rules will invoke "double pow(double,
double)", which generally gives special treatment for integral
exponents, preserving full accuracy of the result.  New proposed
wording provided.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 26.8 [c.math] p10:
</p>

<blockquote>
<p>
The added signatures are:
</p>
<blockquote><pre>...
<del>float pow(float, int);</del>
...
<del>double pow(double, int);</del>
...
<del>long double pow(long double, int);</del>
</pre></blockquote>
</blockquote>






<hr>
<h3><a name="551"></a>551. &lt;ccomplex&gt;</h3>
<p><b>Section:</b> X [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Previously xxx.h was parsable by C++.  But in the case of C99's &lt;complex.h&gt;
it isn't.  Otherwise we could model it just like &lt;string.h&gt;, &lt;cstring&gt;, &lt;string&gt;:
</p>

<ul>
<li>&lt;string&gt;   : C++ API in namespace std</li>
<li>&lt;cstring&gt;  : C API in namespace std</li>
<li>&lt;string.h&gt; : C API in global namespace</li>
</ul>

<p>
In the case of C's complex, the C API won't compile in C++.  So we have:
</p>

<ul>
<li>&lt;complex&gt;   : C++ API in namespace std</li>
<li>&lt;ccomplex&gt;  : ?</li>
<li>&lt;complex.h&gt; : ?</li>
</ul>

<p>
The ? can't refer to the C API.  TR1 currently says:
</p>

<ul>
<li>&lt;complex&gt;   : C++ API in namespace std</li>
<li>&lt;ccomplex&gt;  : C++ API in namespace std</li>
<li>&lt;complex.h&gt; : C++ API in global namespace</li>
</ul>



<p><b>Proposed resolution:</b></p>
<p>
Change 26.3.11 [cmplxh]:
</p>

<blockquote>
<p>
The header behaves as if it includes the header
<tt>&lt;ccomplex&gt;</tt><ins>.</ins><del>, and provides sufficient using
declarations to declare in the global namespace all function and type names
declared or defined in the neader <tt>&lt;complex&gt;</tt>.</del>
<ins>[<i>Note:</i> <tt>&lt;complex.h&gt;</tt> does not promote any interface
into the global namespace as there is no C interface to promote. <i>--end
note</i>]</ins>
</p>
</blockquote>






<hr>
<h3><a name="552"></a>552. random_shuffle and its generator</h3>
<p><b>Section:</b> 25.3.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-01-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
...is specified to shuffle its range by calling swap but not how
(or even that) it's supposed to use the RandomNumberGenerator
argument passed to it.
</p>
<p>
Shouldn't we require that the generator object actually be used
by the algorithm to obtain a series of random numbers and specify
how many times its operator() should be invoked by the algorithm?
</p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
<p><b>Section:</b> 25.4 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 25, p8 we allow BinaryPredicates to return a type that's convertible
to bool but need not actually be bool. That allows predicates to return
things like proxies and requires that implementations be careful about
what kinds of expressions they use the result of the predicate in (e.g.,
the expression in if (!pred(a, b)) need not be well-formed since the
negation operator may be inaccessible or return a type that's not
convertible to bool).
</p>
<p>
Here's the text for reference:
</p>
<blockquote><p>
  ...if an algorithm takes BinaryPredicate binary_pred as its argument
 and first1 and first2 as its iterator arguments, it should work
 correctly in the construct if (binary_pred(*first1, first2)){...}.
</p></blockquote>

<p>
In 25.3, p2 we require that the Compare function object return true
of false, which would seem to preclude such proxies. The relevant text
is here:
</p>
<blockquote><p>
  Compare is used as a function object which returns true if the first
  argument is less than the second, and false otherwise...
</p></blockquote>

<p><i>[
Portland:  Jack to define "convertible to bool" such that short circuiting isn't
destroyed.
]</i></p>


<p><i>[
2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Review once wording received. Stefanus to send proposed wording.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Review once wording received. Stefanus to send proposed wording.
</blockquote>

<p><i>[
2009-10-24 Stefanus supplied wording.
]</i></p>


<blockquote>
Move to Review once wording received. Stefanus to send proposed wording.
Old proposed wording here:
<blockquote>
<p>
I think we could fix this by rewording 25.3, p2 to read somthing like:
</p>
<blockquote><p>
-2- <tt>Compare</tt> is <del>used as a function object which returns
<tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
return value of the function call operator applied to an object of type
<tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
if the first argument of the call</ins> is less than the second, and
<tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
will not apply any non-constant function through the dereferenced iterator.
</p></blockquote>
</blockquote>
</blockquote>

<p><i>[
2010-01-17:
]</i></p>


<blockquote>
<p>
Howard expresses concern that the current direction of the proposed
wording outlaws expressions such as:
</p>

<blockquote><pre>if (!comp(x, y))
</pre></blockquote>

<p>
Daniel provides wording which addresses that concern.
</p>

<p>
The previous wording is saved here:
</p>

<blockquote>

<p>
Change 25.4 [alg.sorting] p2:
</p>
<blockquote>
<tt>Compare</tt> is used as a function object<ins>. The return value of
the function call operator applied to an object of type Compare, when
converted to type bool, yields true if the first argument of the
call</ins> <del>which returns <tt>true</tt> if the first argument</del>
is less than the second, and <tt>false</tt> otherwise. <tt>Compare
comp</tt> is used throughout for algorithms assuming an ordering
relation. It is assumed that <tt>comp</tt> will not apply any
non-constant function through the dereferenced iterator.
</blockquote>

</blockquote>

</blockquote>

<p><i>[
2010-01-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>

<ol>
<li>
<p>
Change 25.1 [algorithms.general]/7+8 as indicated. <i>[This change is
recommended to bring the return value requirements of <tt>BinaryPredicate</tt>
and <tt>Compare</tt> in sync.]</i>
</p>

<blockquote>
<p>
7 The <tt>Predicate</tt> parameter is used whenever an algorithm expects a
function object that when applied to the result of dereferencing the
corresponding iterator returns a value testable as <tt>true</tt>. In other
words, if an algorithm takes <tt>Predicate pred</tt> as its argument and
<tt>first</tt> as its iterator argument, it should work correctly in the
construct <del>if <tt>(pred(*first)){...}</tt></del> <ins><tt>pred(*first)</tt>
contextually converted to <tt>bool</tt> (4 [conv])</ins>. The
function object <tt>pred</tt> shall not apply any nonconstant function through
the dereferenced iterator. This function object may be a pointer to function, or
an object of a type with an appropriate function call operator.
</p>

<p>
8 The <tt>BinaryPredicate</tt> parameter is used whenever an algorithm expects a
function object that when applied to the result of dereferencing two
corresponding iterators or to dereferencing an iterator and type <tt>T</tt> when
<tt>T</tt> is part of the signature returns a value testable as <tt>true</tt>.
In other words, if an algorithm takes <tt>BinaryPredicate</tt>
<tt>binary_pred</tt> as its argument and <tt>first1</tt> and <tt>first2</tt> as
its iterator arguments, it should work correctly in the construct <del><tt>if
(binary_pred(*first1, *first2)){...}</tt></del> <ins><tt>binary_pred(*first1,
*first2)</tt> contextually converted to <tt>bool</tt> (4 [conv])</ins>. <tt>BinaryPredicate</tt> always takes the first iterator
type as its first argument, that is, in those cases when <tt>T value</tt> is
part of the signature, it should work correctly in the <del>context of <tt>if
(binary_pred(*first1, value)){...}</tt></del> <ins>construct
<tt>binary_pred(*first1, value)</tt> contextually converted to <tt>bool</tt>
(4 [conv])</ins>. <tt>binary_pred</tt> shall not apply any
non-constant function through the dereferenced iterators.
</p>
</blockquote>
</li>

<li>
<p>
Change 25.4 [alg.sorting]/2 as indicated:
</p>

<blockquote>
2 <tt>Compare</tt> is <del>used as</del> a function object <ins>type (20.8 [function.objects]). The return value of the function call operation
applied to an object of type <tt>Compare</tt>, when contextually converted to
type <tt>bool</tt> (4 [conv]), yields <tt>true</tt> if the first
argument of the call</ins><del> which returns <tt>true</tt> if the first
argument</del> is less than the second, and <tt>false</tt> otherwise.
<tt>Compare comp</tt> is used throughout for algorithms assuming an ordering
relation. It is assumed that <tt>comp</tt> will not apply any non-constant
function through the dereferenced iterator.
</blockquote>
</li>

</ol>






<hr>
<h3><a name="559"></a>559. numeric_limits&lt;const T&gt;</h3>
<p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-19 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

18.3.1 [limits], p2 requires implementations  to provide specializations of the
<code>numeric_limits</code> template for  each scalar type. While this
could be interepreted to include cv-qualified forms of such types such
an  interepretation   is  not  reflected   in  the  synopsis   of  the
<code>&lt;limits&gt;</code> header.

        </p>
        <p>

The absence  of specializations of the template  on cv-qualified forms
of  fundamental types  makes <code>numeric_limits</code>  difficult to
use in generic  code where the constness (or volatility)  of a type is
not  always  immediately  apparent.  In  such  contexts,  the  primary
template  ends   up  being   instantiated  instead  of   the  provided
specialization, typically yielding unexpected behavior.

        </p>
        <p>

Require   that  specializations   of   <code>numeric_limits</code>  on
cv-qualified fundamental types have the same semantics as those on the
unqualifed forms of the same types.

        </p>


<p><b>Proposed resolution:</b></p>
        <p>

Add  to  the   synopsis  of  the  <code>&lt;limits&gt;</code>  header,
immediately  below  the  declaration  of  the  primary  template,  the
following:
</p>

<pre>
template &lt;class T&gt; class numeric_limits&lt;const T&gt;;
template &lt;class T&gt; class numeric_limits&lt;volatile T&gt;;
template &lt;class T&gt; class numeric_limits&lt;const volatile T&gt;;

</pre>

        <p>

Add  a new paragraph  to the  end of  18.3.1.1 [numeric.limits], with  the following
text:

        </p>
        <p>

-new-para- The  value of each member  of a <code>numeric_limits</code>
specialization on a  cv-qualified T is equal to the  value of the same
member of <code>numeric_limits&lt;T&gt;</code>.

        </p>

<p><i>[
Portland: Martin will clarify that user-defined types get cv-specializations
automatically.
]</i></p>







<hr>
<h3><a name="561"></a>561. inserter overly generic</h3>
<p><b>Section:</b> 24.5.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The declaration of <tt>std::inserter</tt> is:
</p>

<blockquote><pre>template &lt;class Container, class Iterator&gt;
insert_iterator&lt;Container&gt;
inserter(Container&amp; x, Iterator i);
</pre></blockquote>

<p>
The template parameter <tt>Iterator</tt> in this function is completely unrelated
to the template parameter <tt>Container</tt> when it doesn't need to be.  This
causes the code to be overly generic.  That is, any type at all can be deduced
as <tt>Iterator</tt>, whether or not it makes sense.  Now the same is true of
<tt>Container</tt>.  However, for every free (unconstrained) template parameter
one has in a signature, the opportunity for a mistaken binding grows geometrically.
</p>

<p>
It would be much better if <tt>inserter</tt> had the following signature instead:
</p>

<blockquote><pre>template &lt;class Container&gt;
insert_iterator&lt;Container&gt;
inserter(Container&amp; x, typename Container::iterator i);
</pre></blockquote>

<p>
Now there is only one free template parameter.  And the second argument to
<tt>inserter</tt> must be implicitly convertible to the container's iterator,
else the call will not be a viable overload (allowing other functions in the
overload set to take precedence).  Furthermore, the first parameter must have a
nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt>
is not viable.  Contrast this with the current situation
where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those
types need not be anything closely related to containers or iterators.
</p>

<p>
This can adversely impact well written code.  Consider:
</p>

<blockquote><pre>#include &lt;iterator&gt;
#include &lt;string&gt;

namespace my
{

template &lt;class String&gt;
struct my_type {};

struct my_container
{
template &lt;class String&gt;
void push_back(const my_type&lt;String&gt;&amp;);
};

template &lt;class String&gt;
void inserter(const my_type&lt;String&gt;&amp; m, my_container&amp; c) {c.push_back(m);}

}  // my

int main()
{
    my::my_container c;
    my::my_type&lt;std::string&gt; m;
    inserter(m, c);
}
</pre></blockquote>

<p>
Today this code fails because the call to <tt>inserter</tt> binds to
<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>.  However with the
proposed change <tt>std::inserter</tt> will no longer be a viable function which
leaves only <tt>my::inserter</tt> in the overload resolution set.  Everything
works as the client intends.
</p>

<p>
To make matters a little more insidious, the above example works today if you
simply change the first argument to an rvalue:
</p>

<blockquote><pre>    inserter(my::my_type(), c);
</pre></blockquote>

<p>
It will also work if instantiated with some string type other than
<tt>std::string</tt> (or any other <tt>std</tt> type).  It will also work if
<tt>&lt;iterator&gt;</tt> happens to not get included.
</p>

<p>
And it will fail again for such inocuous reaons as <tt>my_type</tt> or
<tt>my_container</tt> privately deriving from any <tt>std</tt> type.
</p>

<p>
It seems unfortunate that such simple changes in the client's code can result
in such radically differing behavior.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change 24.2:
</p>

<blockquote><p>
<b>24.2 Header</b> <tt>&lt;iterator&gt;</tt> <b>synopsis</b>
</p>
<blockquote><pre>...
template &lt;class Container<del>, class Iterator</del>&gt;
   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
...
</pre></blockquote>
</blockquote>

<p>
Change 24.4.2.5:
</p>

<blockquote><p>
<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p>
<blockquote><pre>...
template &lt;class Container<del>, class Iterator</del>&gt;
   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
...
</pre></blockquote>
</blockquote>

<p>
Change 24.4.2.6.5:
</p>

<blockquote>
<p>
<b>24.4.2.6.5</b> <tt>inserter</tt>
</p>
<pre>template &lt;class Container<del>, class Inserter</del>&gt;
   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Inserter</del> <ins>typename Container::iterator</ins> i);
</pre>
<blockquote><p>
-1- <i>Returns:</i> <tt>insert_iterator&lt;Container&gt;(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>.
</p></blockquote>
</blockquote>



<p><i>[
Kona (2007): This issue will probably be addressed as a part of the concepts overhaul of the library anyway, but the proposed resolution is correct in the absence of concepts. 
Proposed Disposition: Ready
]</i></p>





<hr>
<h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
<p><b>Section:</b> 27.8 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

For  better efficiency,  the requirement  on the  stringbuf  ctor that
takes  a  string  argument  should  be  loosened  up  to  let  it  set
<code>epptr()</code>  beyond  just   one  past  the  last  initialized
character  just like  <code>overflow()</code> has  been changed  to be
allowed  to  do   (see  issue  432).  That  way   the  first  call  to
<code>sputc()</code> on  an object won't  necessarily cause a  call to
<code>overflow</code>. The corresponding change  should be made to the
string overload of the <code>str()</code> member function.

        </p>


<p><b>Proposed resolution:</b></p>
        <p>

Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:

        </p>

<blockquote><pre>explicit basic_stringbuf(const basic_string&lt;charT,traits,Allocator&gt;&amp; <i>s<del>tr</del></i>,
               ios_base::openmode <i>which</i> = ios_base::in | ios_base::out);
</pre>

<p>
-3- <i>Effects:</i>  Constructs an object of class <tt>basic_stringbuf</tt>,
initializing the base class with <tt>basic_streambuf()</tt>
(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>.
Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of
<i>str</i> into the <tt>basic_stringbuf</tt> underlying character
sequence. If <tt><i>which</i> &amp; ios_base::out</tt> is true, initializes the
output sequence such that <tt>pbase()</tt> points to the first underlying
character, <tt>epptr()</tt> points one past the last underlying character, and
<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> &amp; ios_base::ate</tt>
is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
<tt>which &amp; ios_base::in</tt> is true, initializes the input sequence such
that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying 
character and <tt>egptr()</tt> points one past the last underlying character.</del>
</p>
</blockquote>

        <p>

Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to
read:

        </p>
<blockquote>
<p>
-2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the
<tt>basic_stringbuf</tt> underlying character sequence <ins>and
initializes the input and output sequences according to <tt><i>mode</i></tt></ins>.
<del>If
<tt><i>mode</i> &amp; ios_base::out</tt> is true, initializes the output
sequence such that <tt>pbase()</tt> points to the first underlying character, 
<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt>
is equal to <tt>epptr()</tt> if <tt><i>mode</i> &amp; ios_base::in</tt>
is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
<tt>mode &amp; ios_base::in</tt> is true, initializes the input sequence 
such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
character and <tt>egptr()</tt> points one past the last underlying character.</del>
</p>

        <p>

<ins>-3- <i>Postconditions:</i>  If  <code>mode  &amp; ios_base::out</code>  is  true,
<code>pbase()</code>  points  to the  first  underlying character  and
<code>(epptr() &gt;= pbase() + s.size())</code> holds; in addition, if
<code>mode &amp; ios_base::in</code> is true, <code>(pptr() == pbase()
+ s.data())</code>  holds, otherwise <code>(pptr()  == pbase())</code>
is   true.    If  <code>mode   &amp;   ios_base::in</code>  is   true,
<code>eback()</code>  points to  the first  underlying  character, and
<code>(gptr()  ==  eback())</code>  and  <code>(egptr() ==  eback()  +
s.size())</code> hold.</ins>

        </p>
</blockquote>


<p><i>[
Kona (2007) Moved to Ready.
]</i></p>





<hr>
<h3><a name="563"></a>563. stringbuf seeking from end</h3>
<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to  Table 92  (unchanged by issue  432), when  <code>(way ==
end)</code> the  <code>newoff</code> value in out mode  is computed as
the difference between <code>epptr()</code> and <code>pbase()</code>.
</p>
        <p>

This value  isn't meaningful unless the  value of <code>epptr()</code>
can be  precisely controlled by a  program.  That used  to be possible
until  we accepted the  resolution of  issue 432,  but since  then the
requirements on <code>overflow()</code> have  been relaxed to allow it
to  make  more than  1  write  position  available (i.e.,  by  setting
<code>epptr()</code>     to     some     unspecified    value     past
<code>pptr()</code>).      So    after     the    first     call    to
<code>overflow()</code>  positioning the  output sequence  relative to
end will have unspecified results.

        </p>
        <p>

In  addition,  in <code>in|out</code>  mode,  since <code>(egptr()  ==
epptr())</code> need not hold, there are two different possible values
for   <code>newoff</code>:    <code>epptr()   -   pbase()</code>   and
<code>egptr() - eback()</code>.

        </p>


<p><b>Proposed resolution:</b></p>
        <p>

Change the <code>newoff</code>  column in the last row  of Table 94 to
read:

        </p>
<blockquote><p>

the <del>end</del> <ins>high mark</ins> pointer minus the beginning 
pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).

</p></blockquote>


<p><i>[
Kona (2007) Moved to Ready.
]</i></p>





<hr>
<h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
<p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The   effects  of  the   <code>seekpos()</code>  member   function  of
<code>basic_stringbuf</code>  simply say  that the  function positions
the  input and/or  output  sequences  but fail  to  spell out  exactly
how. This is in contrast  to the detail in which <code>seekoff()</code>
is described.
</p>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
        <p>

Change 27.7.1.3, p13 to read:

        </p>
<blockquote>
<p>
-13- <i>Effects:</i> <ins>Equivalent to <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
<i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
(as described below).</del>
</p>
<ul>
<li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
<li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
<li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
has not been obtained by a previous successful call to one of the positioning
functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
the effect is undefined.</del></li>
</ul>
</blockquote>


<p><i>[
Kona (2007): A <tt>pos_type</tt> is a position in a stream by
definition, so there is no ambiguity as to what it means. Proposed
Disposition: NAD
]</i></p>


<p><i>[
Post-Kona Martin adds:
I'm afraid I disagree
with the Kona '07 rationale for marking it NAD. The only text
that describes precisely what it means to position the input
or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
clause is inadequate in comparison and the proposed resolution
plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
]</i></p>





<hr>
<h3><a name="565"></a>565. xsputn inefficient</h3>
<p><b>Section:</b> 27.6.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

<tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
"writing up to  <tt>n</tt> characters to the output  sequence as if by
repeated calls to <tt>sputc(c)</tt>."

        </p>
        <p>

Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
<tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
<tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
suboptimal in  some interesting cases,  such as in unbuffered  mode or
when the buffer is <tt>basic_stringbuf</tt>.

        </p>
        <p>

Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
required  and the  wording is  simply  meant to  describe the  general
effect of appending to the end  of the sequence it would be worthwhile
to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
required to cause a call to <tt>overflow()</tt>.

        </p>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
        <p>

Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
27.5.2.4.5, p1 (N1804):

        </p>
        <blockquote>    
            <p>
-1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters 
written are obtained from successive elements of the array whose first element
is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
<tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
<tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
it achieves the same effects by other means.</ins>
            </p>
        </blockquote>    
        <p>

In addition,  I suggest to  add a footnote  to this function  with the
same text as Footnote 292 to  make it extra clear that derived classes
are permitted to override <tt>xsputn()</tt> for efficiency.

        </p>


<p><i>[
Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
has always been the intention of the committee. We believe that the
proposed wording doesn't accomplish that. Proposed Disposition: Open
]</i></p>





<hr>
<h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3>
<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

The array forms of unformatted input functions don't have well-defined
semantics for zero-element  arrays in a couple of  cases. The affected
ones (<tt>istream::get()</tt> and  <tt>getline()</tt>) are supposed to
terminate when <tt>(n - 1)</tt> characters are stored, which obviously
can never be true when <tt>(n == 0)</tt> to start with.

        </p>


<p><b>Proposed resolution:</b></p>
        <p>

I  propose  the following  changes  (references  are  relative to  the
Working Draft (document N1804).

        </p>
        <p>

Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:

        </p>
        <blockquote>
            <p>

<ins>if  <tt>(n  &lt; 1)</tt>  is  true  or  </ins> <tt>(n  -  1)</tt>
characters are stored;

            </p>
        </blockquote>
        <p>

Similarly, change  27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
3 as follows:

        </p>
        <blockquote>
            <p>

<ins><tt>(n &lt; 1)</tt> is  true or </ins><tt>(n - 1)</tt> characters
are     stored     (in    which     case     the    function     calls
<tt>setstate(failbit)</tt>).

            </p>
        </blockquote>
        <p>

Finally, change p21 as follows:

        </p>
        <blockquote>
            <p>

In any  case, <ins>provided  <tt>(n &gt; 0)</tt>  is true,  </ins>it then
stores  a null  character  (using charT())  into  the next  successive
location of the array.

            </p>
        </blockquote>





<hr>
<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3>
<p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

Issue  60 explicitly made  the extractor  and inserter  operators that
take a  <tt>basic_streambuf*</tt> argument formatted  input and output
functions,  respectively.  I  believe that's  wrong, certainly  in the
case of  the extractor, since formatted functions  begin by extracting
and  discarding  whitespace.  The  extractor  should  not discard  any
characters.

        </p>


<p><b>Proposed resolution:</b></p>
        <p>

I propose to  change each operator to behave  as unformatted input and
output function,  respectively. The changes below are  relative to the
working draft document number N1804.

        </p>
        <p>

Specifically, change 27.6.1.2.3, p14 as follows:

        </p>

            <blockquote>
        <p>

<i>Effects</i>:  Behaves as  a<ins>n un</ins>formatted  input function
(as   described   in   <del>27.6.1.2.1</del><ins>27.6.1.3,   paragraph
1</ins>).

        </p>
            </blockquote>
        <p>

And change 27.6.2.5.3, p7 as follows:

        </p>

            <blockquote>
        <p>

<i>Effects</i>: Behaves  as a<ins>n un</ins>formatted  output function
(as   described   in   <del>27.6.2.5.1</del><ins>27.6.2.6,   paragraph
1</ins>).

        </p>
            </blockquote>


<p><i>[
Kona (2007): Proposed Disposition: Ready
]</i></p>





<hr>
<h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
<p><b>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2006-04-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
lib.iostream.objects requires that the standard stream objects are never
destroyed, and it requires that they be destroyed.
</p>
<p>
DR 369 adds words to say that we really mean for ios_base::Init objects to force
construction of standard stream objects. It ends, though, with the phrase "these
stream objects shall be destroyed after the destruction of dynamically ...".
However, the rule for destruction is stated in the standard: "The objects are
not destroyed during program execution."
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 27.4 [iostream.objects]/1:
</p>

<blockquote>
<p>
-2- The objects are constructed and the associations are established at
some time prior to or during the first time an object of class
<tt>ios_base::Init</tt> is constructed, and in any case before the body of main
begins execution.<sup>290)</sup> The objects are not destroyed during program
execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</tt> or explicitly
constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
constructed before dynamic initialization of non-local objects defined
later in that translation unit<del>, and these stream objects shall be
destroyed after the destruction of dynamically initialized non-local
objects defined later in that translation unit</del>.
</p>
</blockquote>


<p><i>[
Kona (2007): From 27.4 [iostream.objects]/2, strike the words "...and these stream objects
shall be destroyed after the destruction of dynamically initialized
non-local objects defined later in that translation unit." Proposed
Disposition: Review
]</i></p>





<hr>
<h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
<p><b>Section:</b> 20.9.10.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-04-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
[tr.util.smartptr.shared.dest] says in its second bullet:
</p>

<p>
"If *this shares ownership with another shared_ptr instance (use_count() &gt; 1),
decrements that instance's use count."
</p>

<p>
The problem with this formulation is that it presupposes the existence of an
"use count" variable that can be decremented and that is part of the state of a
shared_ptr instance (because of the "that instance's use count".)
</p>

<p>
This is contrary to the spirit of the rest of the specification that carefully
avoids to require an use count variable. Instead, use_count() is specified to
return a value, a number of instances.
</p>

<p>
In multithreaded code, the usual implicit assumption is that a shared variable
should not be accessed by more than one thread without explicit synchronization,
and by introducing the concept of an "use count" variable, the current wording
implies that two shared_ptr instances that share ownership cannot be destroyed
simultaneously.
</p>

<p>
In addition, if we allow the interpretation that an use count variable is part
of shared_ptr's state, this would lead to other undesirable consequences WRT
multiple threads. For example,
</p>

<blockquote><pre>p1 = p2;
</pre></blockquote>

<p>
would now visibly modify the state of p2, a "write" operation, requiring a lock.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
</p>

<blockquote>
<ul>
<li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
<tt>shared_ptr</tt> instance (<tt>use_count() &gt; 1</tt>)</ins>, there are no side effects.</li>
<li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
(<tt>use_count() &gt; 1</tt>), decrements that instance's use count.</del></li>
</ul>
</blockquote>

<p>
Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
</p>

<blockquote><p>
[<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
<tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
after <tt>*this</tt> is destroyed. <i>--end note</i>]
</p></blockquote>





<hr>
<h3><a name="576"></a>576. find_first_of is overconstrained</h3>
<p><b>Section:</b> 25.2.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2006-04-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
find_first_of are specified to require Forward Iterators, as follows:
</p>

<blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator1
  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
                        ForwardIterator2 first2, ForwardIterator2 last2);
template&lt;class ForwardIterator1, class ForwardIterator2,
                  class BinaryPredicate&gt;
ForwardIterator1
  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
                         ForwardIterator2 first2, ForwardIterator2 last2,
                        BinaryPredicate pred);
</pre></blockquote>

<p>
However, ForwardIterator1 need not actually be a Forward Iterator; an Input
Iterator suffices, because we do not need the multi-pass property of the Forward
Iterator or a true reference.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the declarations of <tt>find_first_of</tt> to:
</p>

<blockquote><pre>template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2&gt;
  <del>ForwardIterator1</del><ins>InputIterator1</ins>
  find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
                        ForwardIterator2 first2, ForwardIterator2 last2);
template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
                  class BinaryPredicate&gt;
<del>ForwardIterator1</del><ins>InputIterator1</ins>
  find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
                         ForwardIterator2 first2, ForwardIterator2 last2,
                        BinaryPredicate pred);
</pre></blockquote>






<hr>
<h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
<p><b>Section:</b> 25.4.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-05-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
ISO/IEC 14882:2003 says:
</p>

<blockquote>
<p>
25.3.3.2 upper_bound
</p>
<p>
<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
<tt>[<i>first</i>, <i>last</i>)</tt> such that
for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
</p>
</blockquote>

<p>
From the description above, upper_bound cannot return last, since it's
not in the interval [first, last). This seems to be a typo, because if
value is greater than or equal to any other values in the range, or if
the range is empty, returning last seems to be the intended behaviour.
The corresponding interval for lower_bound is also [first, last].
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change [lib.upper.bound]:
</p>

<blockquote>
<p>
<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
</p>
</blockquote>






<hr>
<h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
<p><b>Section:</b> 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

The     description    of     the     allocator    member     function
<code>allocate()</code>  requires  that  the <i>hint</i>  argument  be
either 0 or a  value previously returned from <code>allocate()</code>.
Footnote 227 further suggests that  containers may pass the address of
an adjacent element as this argument.

        </p>
        <p>

I  believe  that  either  the  footnote  is  wrong  or  the  normative
requirement that  the argument be  a value previously returned  from a
call to  <code>allocate()</code> is wrong. The latter  is supported by
the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
Myers. In addition,  the <i>hint</i> is an ordinary  void* and not the
<code>pointer</code>  type returned  by  <code>allocate()</code>, with
the  two  types potentially  being  incompatible  and the  requirement
impossible to satisfy.

        </p>
        <p>

See also c++std-lib-14323 for some  more context on where this came up
(again).

        </p>
    

    <p><b>Proposed resolution:</b></p>
        <p>

Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
previously returned from <code>allocate()</code>. Specifically, change
the paragraph as follows:

        </p>
<p>
<del><i>Requires</i>: <i>hint</i> either 0 or previously obtained  from  member
<code>allocate</code>  and  not  yet passed  to member  <code>deallocate</code>.
The value hint may be used by an implementation to help improve performance
<sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
implementation to help improve performance. -- <i>end note</i>]</ins>
</p>
<blockquote><p>
<del>[Footnote: <sup>223)</sup>In a container member function, the address of an
adjacent element is often a good choice to pass for this argument.</del>
</p></blockquote>
    



<hr>
<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
<p><b>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

The resolution of issue 60 changed <code>basic_ostream::flush()</code>
so as not  to require it to behave as  an unformatted output function.
That has at least two in my opinion problematic consequences:

        </p>
        <p>

First, <code>flush()</code>  now calls <code>rdbuf()-&gt;pubsync()</code>
unconditionally, without  regard to the  state of the stream.  I can't
think of any reason why <code>flush()</code> should behave differently
from the vast majority of stream functions in this respect.

        </p>
        <p>

Second, <code>flush()</code> is not  required to catch exceptions from
<code>pubsync()</code> or set  <code>badbit</code> in response to such
events. That doesn't seem right either, as most other stream functions
do so.

        </p>
    

    <p><b>Proposed resolution:</b></p>
        <p>

I  propose  to revert  the  resolution of  issue  60  with respect  to
<code>flush()</code>. Specifically,  I propose to  change 27.6.2.6, p7
as follows:

        </p>

<p>
Effects: <ins>Behaves as an  unformatted output function (as described
in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null
pointer,  <ins>constructs a  sentry  object.  If  this object  returns
<code>true</code> when converted to a  value of type bool the function
</ins>calls <code>rdbuf()-&gt;pubsync()</code>.  If that function returns
-1    calls    <code>setstate(badbit)</code>    (which    may    throw
<code>ios_base::failure</code>  (27.4.4.3)).   <ins>Otherwise, if  the
sentry object returns <code>false</code>, does nothing.</ins><del>Does
not  behave  as  an  unformatted  output  function  (as  described  in
27.6.2.6, paragraph 1).</del>
</p>

    

<p><i>[
Kona (2007): Proposed Disposition: Ready
]</i></p>





<hr>
<h3><a name="586"></a>586. string inserter not a formatted function</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

Section  and paragraph  numbers  in  this paper  are  relative to  the
working draft document number N2009 from 4/21/2006.

        </p>

        <p>

The  <code>basic_string</code> extractor  in 21.3.7.9,  p1  is clearly
required  to  behave  as  a   formatted  input  function,  as  is  the
<code>std::getline()</code> overload for string described in p7.

        </p>
        <p>

However, the <code>basic_string</code> inserter described in p5 of the
same section has no such requirement. This has implications on how the
operator  responds  to  exceptions thrown  from  <code>xsputn()</code>
(formatted  output functions are  required to  set <code>badbit</code>
and swallow  the exception unless  <code>badbit</code> is also  set in
<code>exceptions()</code>; the  string inserter doesn't  have any such
requirement).

        </p>
        <p>

I don't  see anything in the  spec for the string  inserter that would
justify requiring  it to treat  exceptions differently from  all other
similar operators. (If it did, I think it should be made this explicit
by saying  that the  operator "does not  behave as a  formatted output
function" as has been made customary by the adoption of the resolution
of issue 60).

        </p>
    

    <p><b>Proposed resolution:</b></p>
        <p>

I propose to change the Effects clause in 21.3.7.9, p5, as follows:

        </p>
            <blockquote>
        <p>

<i>Effects</i>: <del>Begins by constructing a  sentry object k as if k
were    constructed    by    typename    <code>basic_ostream&lt;charT,
traits&gt;::sentry   k   (os)</code>.    If  <code>bool(k)</code>   is
<code>true</code>, </del><ins>Behaves  as a formatted  output function
(27.6.2.5.1).   After constructing  a  <code>sentry</code> object,  if
this  object returns <code>true</code>  when converted  to a  value of
type   <code>bool</code>,   determines   padding   as   described   in
22.2.2.2.2</ins>,  then inserts the  resulting sequence  of characters
<code><i>seq</i></code> as if by calling <code>os.rdbuf()-&gt;sputn(seq ,
n)</code>,    where   <code><i>n</i></code>    is   the    larger   of
<code>os.width()</code>   and   <code>str.size()</code>;  then   calls
<code>os.width(0)</code>.  <del>If  the  call  to sputn  fails,  calls
<code>os.setstate(ios_base::failbit)</code>.</del>

        </p>
            </blockquote>
        <p>

This proposed  resilution assumes the  resolution of issue  394 (i.e.,
that   all   formatted   output   functions  are   required   to   set
<code>ios_base::badbit</code>  in response  to any  kind  of streambuf
failure),   and   implicitly   assumes   that  a   return   value   of
<code>sputn(seq,  <i>n</i>)</code>  other  than  <code><i>n</i></code>
indicates a failure.

        </p>
    



<hr>
<h3><a name="589"></a>589. Requirements on iterators of member template functions of containers</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-08-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
<p><b>Discussion:</b></p>
<p>
There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
(requires InputIterator::value_type be the same type as the container's value_type).
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 23.1.1 p3:
</p>

<blockquote><p>
In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
iterator requirements <ins>and refer to elements <ins>implicitly
convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
</p></blockquote>

<p>
Change 23.1.2 p7:
</p>

<blockquote><p>
In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
refer to elements <del>of</del> <ins>implicitly convertible to</ins>
<tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
<tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
</p></blockquote>



<p><b>Rationale:</b></p>
<p>
Concepts will probably come in and rewrite this section anyway.  But just in case it is
easy to fix this up as a safety net and as a clear statement of intent.
</p>





<hr>
<h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
<p><b>Section:</b> 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2006-08-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
&lt;cstdint&gt; and &lt;stdint.h&gt;.  These are of course based on the C99 header
&lt;stdint.h&gt;, and were part of TR1.
</p>

<p>
Per 18.3.1/1, these headers define a number of macros and function macros. 
While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
header defines all ... macros the same as C99 subclause 7.18."
</p>

<p>
Therefore, if I wish to have the above-referenced macros and function macros
defined, must I #define __STDC_CONSTANT_MACROS before I #include &lt;cstdint&gt;, or
does the C++ header define these macros/function macros unconditionally?
</p>


<p><b>Proposed resolution:</b></p>
<p>
To put this issue to rest for C++0X, I propose the following addition to 
18.3.1/2 of the Working Paper N2009:
</p>

<blockquote><p>
[Note: The macros defined by &lt;cstdint&gt; are provided unconditionally: in
particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
</p></blockquote>





<hr>
<h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>

<p>
It seems undesirable to define the Swappable requirement in terms of
CopyConstructible and Assignable requirements. And likewise, once the
MoveConstructible and MoveAssignable requirements (N1860) have made it
into the Working Draft, it seems undesirable to define the Swappable
requirement in terms of those requirements. Instead, it appears
preferable to have the Swappable requirement defined exclusively in
terms of the existence of an appropriate swap function.
</p>

<p>
Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
says:
</p>

<blockquote><p>
The Swappable requirement is met by satisfying one or more of the
following conditions:</p>
<ul>
<li>
T is Swappable if T satisfies the CopyConstructible requirements
(20.1.3) and the Assignable requirements (23.1);
</li>
<li>
T is Swappable if a namespace scope function named swap exists in the
same namespace as the definition of T, such that the expression
swap(t,u) is valid and has the semantics described in Table 33.
</li>
</ul>
</blockquote>

<p>
I can think of three disadvantages of this definition:
</p>

<ol>
<li>
<p>
If a client's type T satisfies the first condition (T is both
CopyConstructible and Assignable), the client cannot stop T from
satisfying the Swappable requirement without stopping T from
satisfying the first condition.
</p>
<p>
A client might want to stop T from satisfying the Swappable
requirement, because swapping by means of copy construction and
assignment might throw an exception, and she might find a throwing
swap unacceptable for her type. On the other hand, she might not feel
the need to fully implement her own swap function for this type. In
this case she would want to be able to simply prevent algorithms that
would swap objects of type T from being used, e.g., by declaring a
swap function for T, and leaving this function purposely undefined.
This would trigger a link error, if an attempt would be made to use
such an algorithm for this type. For most standard library
implementations, this practice would indeed have the effect of
stopping T from satisfying the Swappable requirement.
</p>
</li>
<li>
<p>
A client's type T that does not satisfy the first condition can not be
made Swappable by providing a specialization of std::swap for T.
</p>
<p>
While I'm aware about the fact that people have mixed feelings about
providing a specialization of std::swap, it is well-defined to do so.
It sounds rather counter-intuitive to say that T is not Swappable, if
it has a valid and semantically correct specialization of std::swap.
Also in practice, providing such a specialization will have the same
effect as satisfying the Swappable requirement.
</p>
</li>
<li>
<p>
For a client's type T that satisfies both conditions of the Swappable
requirement, it is not specified which of the two conditions prevails.
After reading section 20.1.4 [lib.swappable], one might wonder whether
objects of T will be swapped by doing copy construction and
assignments, or by calling the swap function of T.
</p>
<p>
I'm aware that the intention of the Draft is to prefer calling the
swap function of T over doing copy construction and assignments. Still
in my opinion, it would be better to make this clear in the wording of
the definition of Swappable. 
</p>
</li>
</ol>

<p>
I would like to have the Swappable requirement defined in such a way
that the following code fragment will correctly swap two objects of a
type T, if and only if T is Swappable:
</p>

<pre>   using std::swap;
   swap(t, u);  // t and u are of type T.
</pre>

<p>
This is also the way Scott Meyers recommends calling a swap function,
in Effective C++, Third Edition, item 25.
</p>

<p>
Most aspects of this issue have been dealt with in a discussion on
comp.std.c++ about the Swappable requirement, from 13 September to 4
October 2006, including valuable input by David Abrahams, Pete Becker,
Greg Herlihy, Howard Hinnant and others.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Recommend NAD.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved to Open.  Waiting for non-concepts draft.
</blockquote>

<p><i>[
2009-11-08 Howard adds:
]</i></p>


<blockquote>
This issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>.
</blockquote>

<p><i>[
2010-02-03 Sean Hunt adds:
]</i></p>


<blockquote>
<p>
While reading N3000, I independently came across Issue 594. Having seen that
it's an issue under discussion, I think the proposed wording needs fixing to
something more like "...function call swap(t,u) that includes std::swap in its
overload set is valid...", because "...is valid within the namespace std..."
does not allow other libraries to simply use the Swappable requirement by
referring to the standard's definition, since they cannot actually perform any
calls within std.
</p>

<p>
This wording I suggested would also make overloads visible in the same scope as
the `using std::swap` valid for Swappable requirements; a more complex wording
limiting the non-ADL overload set to std::swap might be required.
</p>
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to NAD Editorial.  Rationale added.
</blockquote>



<p><b>Rationale:</b></p>
<p>
Solved by N3048.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change section 20.1.4 [lib.swappable] as follows:
</p>
<blockquote><p>
The Swappable requirement is met by satisfying
<del>one or more of the following conditions:</del>
<ins>the following condition:</ins></p>
<ul>

<li>
<del>T is Swappable if T satisfies the CopyConstructible requirements
(20.1.3) and the Assignable requirements (23.1);</del>
</li>
<li>
<del>
T is Swappable if a namespace scope function named swap exists in the
same namespace as the definition of T, such that the expression
swap(t,u) is valid and has the semantics described in Table 33.
</del>
T is Swappable if an unqualified function call swap(t,u) is valid
within the namespace std, and has the semantics described in Table 33.
</li>
</ul>
</blockquote>





<hr>
<h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
<p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Stefan Gro�e Pawig <b>Opened:</b> 2006-09-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
TR1 introduced, in the C compatibility chapter, the function
fabs(complex&lt;T&gt;):
</p>
<blockquote><pre>----- SNIP -----
8.1.1 Synopsis                                [tr.c99.cmplx.syn]

  namespace std {
  namespace tr1 {
[...]
  template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; x);
  } // namespace tr1
  } // namespace std

[...]

8.1.8 Function fabs                          [tr.c99.cmplx.fabs]

1 Effects: Behaves the same as C99 function cabs, defined in
  subclause 7.3.8.1.
----- SNIP -----
</pre></blockquote>

<p>
The current C++0X draft document (n2009.pdf) adopted this
definition in chapter 26.3.1 (under the comment // 26.3.7 values)
and 26.3.7/7.
</p>
<p>
But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
n1124), the referenced subclause reads
</p>

<blockquote><pre>----- SNIP -----
7.3.8.1 The cabs functions

  Synopsis

1 #include &lt;complex.h&gt;
  double cabs(double complex z);
  float cabsf(float complex z);
  long double cabsl(long double z);

  Description

2 The cabs functions compute the complex absolute value (also called
  norm, modulus, or magnitude) of z.

  Returns

3 The cabs functions return the complex absolute value.
----- SNIP -----
</pre></blockquote>

<p>
Note that the return type of the cabs*() functions is not a complex
type.  Thus, they are equivalent to the already well established
  template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
document n2009.pdf).
</p>
<p>
So either the return value of fabs() is specified wrongly, or fabs()
does not behave the same as C99's cabs*().
</p>

<b>Possible Resolutions</b>

<p>
This depends on the intention behind the introduction of fabs().
</p>
<p>
If the intention was to provide a /complex/ valued function that
calculates the magnitude of its argument, this should be
explicitly specified.  In TR1, the categorization under "C
compatibility" is definitely wrong, since C99 does not provide
such a complex valued function.
</p>
<p>
Also, it remains questionable if such a complex valued function
is really needed, since complex&lt;T&gt; supports construction and
assignment from real valued arguments.  There is no difference
in observable behaviour between
</p>
<blockquote><pre>  complex&lt;double&gt; x, y;
  y = fabs(x);
  complex&lt;double&gt; z(fabs(x));
</pre></blockquote>
<p>
and
</p>
<blockquote><pre>  complex&lt;double&gt; x, y;
  y = abs(x);
  complex&lt;double&gt; z(abs(x));
</pre></blockquote>
<p>
If on the other hand the intention was to provide the intended
functionality of C99, fabs() should be either declared deprecated
or (for C++0X) removed from the standard, since the functionality
is already provided by the corresponding overloads of abs().
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
Bill believes that abs() is a suitable overload. We should remove fabs().
</blockquote>


<p><b>Proposed resolution:</b></p>

<p>
Change the synopsis in 26.4.1 [complex.syn]:
</p>

<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);</del>
</pre></blockquote>

<p>
Remove 26.4.7 [complex.value.ops], p7:
</p>

<blockquote>
<pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; <i>x</i>);</del>
</pre>
<blockquote>
<p>
<del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
</p>
</blockquote>
</blockquote>



<p><i>[
Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>. 
Proposed Disposition: Ready
]</i></p>





<hr>
<h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
<p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2006-09-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In testing 27.9.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
</p>
<blockquote><pre>   ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
</pre></blockquote>
<p>
and we expect the open to fail, because out|in|app is not listed in
Table 92, and just before the table we see very specific words:
</p>
<blockquote><p>
  If mode is not some combination of flags shown in the table 
  then the open fails.
</p></blockquote>
<p>
But the corresponding table in the C standard, 7.19.5.3, provides two
modes "a+" and "a+b", to which the C++ modes out|in|app and
out|in|app|binary would presumably apply.
</p>
<p>
We would like to argue that the intent of Table 112 was to match the
semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
unintentional.  (Otherwise there would be valid and useful behaviors
available in C file I/O which are unavailable using C++, for no
valid functional reason.)
</p>
<p>
We further request that the missing modes be explicitly restored to
the WP, for inclusion in C++0x.
</p>

<p><i>[
Martin adds:
]</i></p>


<p>
...besides "a+" and "a+b" the C++ table is also missing a row
for a lone app bit which in at least two current implementation
as well as in Classic Iostreams corresponds to the C stdio "a"
mode and has been traditionally documented as implying ios::out.
Which means the table should also have a row for in|app meaning
the same thing as "a+" already proposed in the issue.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add to the table "File open modes" in 27.9.1.4 [filebuf.members]:
</p>

<blockquote>
<table border="1">
<caption> File open modes</caption>
<tbody><tr>
<th colspan="5"><tt>ios_base</tt> Flag combination</th>
<th><tt>stdio</tt> equivalent</th>
</tr>
<tr>
<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt>&nbsp;</tt></th>
</tr>

<tr>
<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
</tr>
<tr>
<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
</tr>
<tr>
<td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
</tr>
<tr>
<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
</tr>
<tr>
<td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
</tr>
<tr>
<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
</tr>
<tr>
<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
</tr>
<tr>
<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
</tr>
<tr>
<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
</tr>

<tr>
<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
</tr>
<tr>
<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
</tr>
<tr>
<td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
</tr>
<tr>
<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
</tr>
<tr>
<td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
</tr>
<tr>
<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
</tr>
<tr>
<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+b"</tt></td>
</tr><tr>
<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
</tr>
<tr>
<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
</tr>


</tbody></table>
</blockquote>



<p><i>[
Kona (2007) Added proposed wording and moved to Review.
]</i></p>





<hr>
<h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In a private email, Daniel writes:
</p>
<blockquote>
<p>
I would like to 
ask, what where the reason for the decision to 
define the semantics of the integral conversion of the decimal types, namely
</p>
<pre>"operator long long() const;

     Returns: Returns the result of the 
conversion of *this to the type long long, as if 
performed by the expression llrounddXX(*this)."
</pre>
<p>
where XX stands for either 32, 64, or 128, 
corresponding to the proper decimal type. The 
exact meaning of llrounddXX is not given in that 
paper, so I compared it to the corresponding 
definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
</p>
<p>
"The lround and llround functions round their 
argument to the nearest integer value,
rounding halfway cases away from zero, regardless 
of the current rounding direction. [..]"
</p>
<p>
Now considering the fact that integral conversion 
of the usual floating-point types ("4.9 
Floating-integral conversions") has truncation 
semantic I wonder why this conversion behaviour 
has not been transferred for the decimal types. 
</p>
</blockquote>
<p>
Robert comments:
</p>
<p>
Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>.  It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change the <b>Returns:</b> clause in 3.2.2.4 to:
</p>
<blockquote><p>
<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
</p></blockquote>
<p>
Change the <b>Returns:</b> clause in 3.2.3.4 to:
</p>
<blockquote><p>
<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
</p></blockquote>
<p>
Change the <b>Returns:</b> clause in 3.2.4.4 to:
</p>
<blockquote><p>
<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
</p></blockquote>






<hr>
<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
<p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Daniel writes in a private email:
</p>

<blockquote>
<p>
- 3.1 'Decimal type encodings' says in its note:
</p>
<pre>"this implies that 
sizeof(std::decimal::decimal32) == 4, 
sizeof(std::decimal::decimal64) == 8, and 
sizeof(std::decimal::decimal128) == 16."
</pre>
<p>
This is a wrong assertion, because the definition 
of 'byte' in 1.7 'The C+ + memory model' of ISO 
14882 (2nd edition) does not specify that a byte 
must be necessarily 8 bits large, which would be 
necessary to compare with the specified bit sizes 
of the types decimal32, decimal64, and decimal128.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 3.1 as follows:
</p>
<blockquote>
<p>
The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
</p>
<ul>
<li>
decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
</li>
<li>
decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)

</li>
<li>
decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
</li>
</ul>
<p>
<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>.  <i>--end note</i>]</del>
</p>
</blockquote>




<hr>
<h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
<p><b>Section:</b> TRDecimal 3.9 [trdec.types.cwchar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Daniel writes:
</p>
<blockquote><p>
- 3.9.1 'Additions to &lt;cwchar&gt;' provides wrong 
signatures to the wcstod32, wcstod64, and 
wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
</p></blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change "3.9.1 Additions to <code>&lt;cwchar&gt;</code> synopsis" to:
</p>
<pre>       namespace std {
       namespace decimal {
         // 3.9.2 wcstod functions:
         decimal32  wcstod32  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
         decimal64  wcstod64  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
         decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
       }
       }
</pre>




<hr>
<h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
<p><b>Section:</b> TRDecimal 3.3 [trdec.types.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Daniel writes in a private email:
</p>

<blockquote>
<p>
- 3.3 'Additions to header &lt;limits&gt;' contains two 
errors in the specialisation of numeric_limits&lt;decimal::decimal128&gt;:
</p>
<ol>
<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
<li>The static member digits is assigned to 384,
this should be 34 (Probably mixed up with the
max. exponent for decimal::decimal64).</li>
</ol>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In "3.3 Additions to header <code>&lt;limits&gt;</code>" change numeric_limits&lt;decimal::decimal128&gt; as follows:
</p>
<pre>        template&lt;&gt; class numeric_limits&lt;decimal::decimal128&gt; {
          public:
            static const bool is_specialized = true;

            static decimal::decimal128 min() throw() { return DEC128_MIN; }
            static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }

            static const int digits       = <del>384</del> <ins>34</ins>;
            /* ... */
</pre>




<hr>
<h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The document uses the term "generic floating types," but defines it nowhere.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the first paragraph of "3 Decimal floating-point types" as follows:
</p>
<blockquote><p>
This Technical Report introduces three decimal floating-point types, named
decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
subset of the set of values of type decimal64; the set of values of the type
decimal64 is a subset of the set of values of the type decimal128. Support for
decimal128 is optional.  <ins>These types supplement the Standard C++ types
<code>float</code>, <code>double</code>, and <code>long double</code>, which are
collectively described as the <i>basic floating types</i></ins>.
</p></blockquote>




<hr>
<h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
<p><b>Discussion:</b></p>
<p>In c++std-lib-17198, Martin writes:</p>

<blockquote><p>
Each of the three classes proposed in the paper (decimal32, decimal64,
and decimal128) explicitly declares and specifies the semantics of its
copy constructor, copy assignment operator, and destructor. Since the
semantics of all three functions are identical to the trivial versions
implicitly generated by the compiler in the absence of any declarations
it is safe to drop them from the spec. This change would make the
proposed classes consistent with other similar classes already in the
standard (e.g., std::complex).
</p></blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change "3.2.2 Class <code>decimal32</code>" as follows:
</p>
<pre>      namespace std {
      namespace decimal {
        class decimal32 {
          public:
            // 3.2.2.1 construct/copy/destroy:
            decimal32();
            <del>decimal32(const decimal32 &amp; d32);</del>
            <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
            <del>~decimal32();</del>
            /* ... */
</pre>
<p>
Change "3.2.2.1 construct/copy/destroy" as follows:
</p>
<pre>        decimal32();

    Effects: Constructs an object of type decimal32 with the value 0;

        <del>decimal32(const decimal32 &amp; d32);</del>
        <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>

    <del>Effects: Copies an object of type decimal32.</del>

        <del>~decimal32();</del>

    <del>Effects: Destroys an object of type decimal32.</del>

</pre>
<p>
Change "3.2.3 Class <code>decimal64</code>" as follows:
</p>
<pre>      namespace std {
      namespace decimal {
        class decimal64 {
          public:
            // 3.2.3.1 construct/copy/destroy:
            decimal64();
            <del>decimal64(const decimal64 &amp; d64);</del>
            <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
            <del>~decimal64();</del>
            /* ... */
</pre>
<p>
Change "3.2.3.1 construct/copy/destroy" as follows:
</p>
<pre>        decimal64();

    Effects: Constructs an object of type decimal64 with the value 0;

        <del>decimal64(const decimal64 &amp; d64);</del>
        <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>

    <del>Effects: Copies an object of type decimal64.</del>

        <del>~decimal64();</del>

    <del>Effects: Destroys an object of type decimal64.</del>

</pre>
<p>
Change "3.2.4 Class <code>decimal128</code>" as follows:
</p>
<pre>      namespace std {
      namespace decimal {
        class decimal128 {
          public:
            // 3.2.4.1 construct/copy/destroy:
            decimal128();
            <del>decimal128(const decimal128 &amp; d128);</del>
            <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
            <del>~decimal128();</del>
            /* ... */
</pre>
<p>
Change "3.2.4.1 construct/copy/destroy" as follows:
</p>
<pre>        decimal128();

    Effects: Constructs an object of type decimal128 with the value 0;

        <del>decimal128(const decimal128 &amp; d128);</del>
        <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>

    <del>Effects: Copies an object of type decimal128.</del>

        <del>~decimal128();</del>

    <del>Effects: Destroys an object of type decimal128.</del>

</pre>




<hr>
<h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In c++std-lib-17197, Martin writes:
</p>
<blockquote><p>
The extended_num_get and extended_num_put facets are designed
to store a reference to a num_get or num_put facet which the
extended facets delegate the parsing and formatting of types
other than decimal. One form of the extended facet's ctor (the
default ctor and the size_t overload) obtains the reference
from the global C++ locale while the other form takes this
reference as an argument.
</p></blockquote>
<blockquote><p>
The problem with storing a reference to a facet in another
object (as opposed to storing the locale object in which the
facet is installed) is that doing so bypasses the reference
counting mechanism designed to prevent a facet that is still
being referenced (i.e., one that is still installed in some
locale) from being destroyed when another locale that contains
it is destroyed. Separating a facet reference from the locale
it comes from van make it cumbersome (and in some cases might
even make it impossible) for programs to prevent invalidating
the reference. (The danger of this design is highlighted in
the paper.)
</p></blockquote>
<blockquote><p>
This problem could be easily avoided by having the extended
facets store a copy of the locale from which they would extract
the base facet either at construction time or when needed. To
make it possible, the forms of ctors of the extended facets that
take a reference to the base facet would need to be changed to
take a locale argument instead.
</p></blockquote>


<p><b>Proposed resolution:</b></p>
<p>
1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
</p>
<pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);

            /* ... */

            <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>;        <i><b>exposition only</b></i></del>
            <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
</pre>
<p>
2. Change the description of the above constructor in 3.10.2.1:
</p>
<pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);

</pre>
<blockquote>
<p>
<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
</p>
<pre>       extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
                : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
                { /* ... */ }

</pre>
<p>
<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
</p>
</blockquote>
<p>
3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
</p>
<blockquote><p>
<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>. 
</p></blockquote>
<p>
4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
</p>
<pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);

            /* ... */

            <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>;       <i><b>exposition only</b></i></del>
            <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
</pre>
<p>
5. Change the description of the above constructor in 3.10.3.1:
</p>
<pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
</pre>
<blockquote>
<p>
<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
</p>
<pre>       extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
                : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
                { /* ... */ }

</pre>
<p>
<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
</p>
</blockquote>
<p>
6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
</p>
<blockquote><p>
<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>. 
</p></blockquote>

<p><i>[
Redmond:  We would prefer to rename "extended" to "decimal".
]</i></p>






<hr>
<h3><a name="605"></a>605. Decimal: &lt;decfloat.h&gt; doesn't live here anymore.</h3>
<p><b>Section:</b> TRDecimal 3.4 [trdec.types.cdecfloat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2006-10-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header.  The contents of that header have been moved into &lt;float.h&gt;.  For the sake of C compatibility, we should make corresponding changes.
</p>


<p><b>Proposed resolution:</b></p>
<p>
1. Change the heading of subclause 3.4, "Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code>" to "Additions to headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code>."
</p>
<p>
2. Change the text of subclause 3.4 as follows:
</p>
<blockquote>
<p>
<del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>.  Their contents remain unchanged by this Technical Report.</del>
</p>
<p>
<del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
</p>
<p>
<ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat].  The header <code>&lt;float.h&gt;</code> is described in [tr.c99.floath]. These headers are extended by this Technical Report to define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
</p>
</blockquote>
<p>
3. Change the heading of subclause 3.4.1, "Header <code>&lt;cdecfloat&gt;</code> synopsis"  to "Additions to header <code>&lt;cfloat&gt;</code> synopsis."
</p>
<p>
4. Change the heading of subclause 3.4.2, "Header <code>&lt;decfloat.h&gt;</code> synopsis" to "Additions to header <code>&lt;float.h&gt;</code> synopsis."
</p>
<p>
5. Change the contents of 3.4.2 as follows:
</p>
<pre>      <del>#include &lt;cdecfloat&gt;</del>

      // <i>C-compatibility convenience typedefs:</i>

      typedef std::decimal::decimal32  _Decimal32;
      typedef std::decimal::decimal64  _Decimal64;
      typedef std::decimal::decimal128 _Decimal128;
</pre>





<hr>
<h3><a name="607"></a>607. Concern about short seed vectors</h3>
<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Short seed vectors of 32-bit quantities all result in different states. However
this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
these two seeds
</p>

<blockquote><pre>unsigned short seed = {1, 2, 3};
unsigned short seed = {1, 2, 3, 0};
</pre></blockquote>

<p>
both pack to
</p>

<blockquote><pre>unsigned seed = {0x20001, 0x3};
</pre></blockquote>

<p>
yielding the same state.
</p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
treatment of signed quantities is unclear. Better to spell it out.
</p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="609"></a>609. missing static const</h3>
<p><b>Section:</b> 26.5.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Walter E. Brown <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In preparing N2111, an error on my part resulted in the omission of the
following line from the template synopsis in the cited section:
</p>

<blockquote><pre>static const size_t word_size = w;
</pre></blockquote>

<p>
(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
</p>

<blockquote><pre>// engine characteristics
<ins>static const size_t word_size = w;</ins>
</pre></blockquote>

<p>
and accept my apologies for the oversight.
</p>





<hr>
<h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
<p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Scott Meyers <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
My suggestion is that implementers of both tr1::function and its 
official C++0x successor be explicitly encouraged (but not required) to 
optimize for the cases mentioned above, i.e., function pointers and 
small function objects.  They could do this by using a small internal 
buffer akin to the buffer used by implementations of the small string 
optimization.  (That would make this the small functor optimization -- 
SFO :-})  The form of this encouragement could be a note in the standard 
akin to footnote 214 of the current standard.
</p>

<p>
Dave Abrahams notes:
</p>

<p>
"shall not throw exceptions" should really be "nothing," both to be more
grammatical and to be consistent with existing wording in the standard.
</p>

<p>
Doug Gregor comments: I think this is a good idea. Currently, implementations of
tr1::function are required to have non-throwing constructors and assignment
operators when the target function object is a function pointer or a
reference_wrapper. The common case, however, is for a tr1::function to store
either an empty function object or a member pointer + an object pointer.
</p>
<p>
The function implementation in the upcoming Boost 1.34.0 uses the
"SFO", so that the function objects for typical bind expressions like
</p>
<blockquote><pre>bind(&amp;X::f, this, _1, _2, _3)
</pre></blockquote>

<p>
do not require heap allocation when stored in a boost::function. I
believe Dinkumware's implementation also performs this optimization.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
</p>

<blockquote>
<p>
<i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
the stored function object.
</p>
<p>
<ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
is an object holding only a pointer or reference to an object and a member
function pointer (a "bound member function").</ins>
</p>
</blockquote>





<hr>
<h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
<p><b>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Nicola Musatti <b>Opened:</b> 2006-11-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the latest available draft standard 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
� 17.4.3.6 [res.on.functions] states:
</p>

<blockquote>
<p>
-1- In certain cases (replacement functions, handler functions, operations on
types used to instantiate standard library template components), the C++
Standard Library depends on components supplied by a C++ program. If these
components do not meet their requirements, the Standard places no requirements
on the implementation.
</p>

<p>
-2- In particular, the effects are undefined in the following cases:
</p>
<p>
[...]
</p>
<ul>
<li>if an incomplete type (3.9) is used as a template argument when
instantiating a template component. </li>
</ul>
</blockquote>

<p>
This is contradicted by � 20.6.6.2/2 [util.smartptr.shared] which
states:
</p>

<blockquote>
<p>
[...]
</p>

<p>
The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Modify the last bullet of � 17.4.3.6/2 [res.on.functions] to allow for
exceptions:
</p>

<blockquote>
<ul>
<li>if an incomplete type (3.9) is used as a template argument when
instantiating a template component<ins>, unless specifically allowed for the
component</ins>. </li>
</ul>
</blockquote>






<hr>
<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
<p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2006-11-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
18.2.1.2 55 states that "A type is modulo if it is possible to add two
positive numbers together and have a result that wraps around to a
third number that is less".
This seems insufficient for the following reasons:
</p>

<ol>
<li>Doesn't define what that value received is.</li>
<li>Doesn't state the result is repeatable</li>
<li> Doesn't require that doing addition, subtraction and other
operations on all values is defined behaviour.</li>
</ol>

<p><i>[
Batavia: Related to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
]</i></p>


<p><i>[
Bellevue:  accept resolution, move to ready status.
Does this mandate that is_modulo be true on platforms for which int
happens to b modulo? A: the standard already seems to require that.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Suggest 18.3.1.2 [numeric.limits.members], paragraph 57 is amended to:
</p>

<blockquote><p>
A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
and have a result that wraps around to a third number that is less.</del>
<ins>given any operation involving +,- or * on values of that type whose value
would fall outside the range <tt>[min(), max()]</tt>, then the value returned
differs from the true value by an integer multiple of <tt>(max() - min() +
1)</tt>.</ins>
</p></blockquote>






<hr>
<h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
<p><b>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-11-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 18.3.1.5 [numeric.special] starts out by saying that "All members shall be provided 
for all specializations."
</p>
<p>
Then it goes on to show specializations for float and bool, where one member 
is missing (max_digits10).
</p>

<p>
Maarten Kronenburg adds:
</p>

<p>
I agree, just adding the comment that the exact number of decimal digits
is digits * ln(radix) / ln(10), where probably this real number is
rounded downward for digits10, and rounded upward for max_digits10
(when radix=10, then digits10=max_digits10).
Why not add this exact definition also to the standard, so the user
knows what these numbers exactly mean.
</p>

<p>
Howard adds:
</p>

<p>
For reference, here are the correct formulas from
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
</p>

<blockquote><pre>digits10 = floor((digits-1) * log10(2))
max_digits10 = ceil((1 + digits) * log10(2))
</pre></blockquote>

<p>
We are also missing a statement regarding for what specializations this member has meaning.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change and add after 18.3.1.2 [numeric.limits.members], p11:
</p>

<blockquote>
<pre>static const int max_digits10;</pre>
<blockquote>
<p>
-11- Number of base 10 digits required to ensure that values which
differ <del>by only one epsilon</del> are always differentiated.
</p>
<p><ins>
-12- Meaningful for all floating point types.
</ins></p>
</blockquote>
</blockquote>

<p>
Change 18.3.1.5 [numeric.special], p2:
</p>

<blockquote><pre>template&lt;&gt; class numeric_limits&lt;float&gt; { 
public: 
  static const bool is_specialized = true; 
  ...
  static const int digits10 = 6;
  <ins>static const int max_digits10 = 9</ins>;
  ...
</pre></blockquote>

<p>
Change 18.3.1.5 [numeric.special], p3:
</p>

<blockquote><pre>template&lt;&gt; class numeric_limits&lt;bool&gt; { 
public: 
  static const bool is_specialized = true; 
  ...
  static const int digits10 = 0;
  <ins>static const int max_digits10 = 0</ins>;
  ...
</pre></blockquote>







<hr>
<h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
<p><b>Section:</b> 22.4.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 22.2.1.2 defines the ctype_byname class template. It contains the 
line
</p>

<blockquote><pre>typedef ctype&lt;charT&gt;::mask   mask;
</pre></blockquote>



<p><b>Proposed resolution:</b></p>
<p>
as this is a dependent type, it should obviously be
</p>

<blockquote><pre>typedef <ins>typename</ins> ctype&lt;charT&gt;::mask   mask;
</pre></blockquote>





<hr>
<h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
<p><b>Section:</b> 26.6.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I would respectfully request an issue be opened with the intention to
clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 26.6.2.7 [valarray.members], paragraph 10:
</p>

<blockquote>

<pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
</pre>

<blockquote>
<p>
This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
<tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
the leftmost element, a positive value of <i>n</i> shifts the elements
circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
element zero is taken as the leftmost element, a non-negative value of
<i>n</i> shifts the elements circularly left <i>n</i> places and a
negative value of <i>n</i> shifts the elements circularly right
-<i>n</i> places.</ins>
</p>
</blockquote>
</blockquote>



<p><b>Rationale:</b></p>
<p>
We do not believe that there is any real ambiguity about what happens
when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
expression causes more trouble that it solves. The expression is
certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
is implementation defined.
</p>


<p><i>[
Kona (2007) Changed proposed wording, added rationale and set to Review.
]</i></p>





<hr>
<h3><a name="619"></a>619. Longjmp wording problem</h3>
<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2007-01-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The wording for <tt>longjmp</tt> is confusing.
</p>
<p>
18.10 [support.runtime] -4- Other runtime support
</p>
<blockquote><p>
The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
behavior in this International Standard.  If any automatic objects would
be destroyed by a thrown exception transferring control to another
(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
the throw point that transfers control to the same (destination) point has
undefined behavior.
</p></blockquote>
<p>
Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
*at* the throw point that transfers control".
</p>
<p>
Bill Gibbons thinks it should say something like "If any automatic objects
would be destroyed by an exception thrown at the point of the longjmp and
caught only at the point of the setjmp, the behavior is undefined."
</p>


<p><b>Proposed resolution:</b></p>
<p>
In general, accept Bill Gibbons' recommendation,
but add "call" to indicate that the undefined behavior
comes from the dynamic call, not from its presence in the code.
In 18.10 [support.runtime] paragraph 4, change
</p>

<blockquote><p>
The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
restricted behavior in this International Standard.  <del>If any automatic
objects would be destroyed by a thrown exception transferring control to another
(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
that the throw point that transfers control to the same (destination) point has
undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
<tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
</p></blockquote>





<hr>
<h3><a name="620"></a>620. valid uses of empty valarrays</h3>
<p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

The <i>Effects</i>  clause for the  default <code>valarray</code> ctor
suggests  that  it  is possible  to  increase  the  size of  an  empty
<code>valarray</code>  object   by  calling  other   non-const  member
functions of the class besides <code>resize()</code>. However, such an
interpretation would  be contradicted by  the requirement on  the copy
assignment  operator  (and  apparently   also  that  on  the  computed
assignments)  that the  assigned arrays  be  the same  size.  See  the
reflector discussion starting with c++std-lib-17871.

        </p>
        <p>

In  addition,  <i>Footnote</i> 280  uses  some questionable  normative
language.

        </p>


<p><b>Proposed resolution:</b></p>
        <p>

Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.6.2.1 [valarray.cons]):

        </p>
        <blockquote>
            <p>

<code>valarray();</code>

            </p>
            <p>

<i>Effects</i>:      Constructs      an      object      of      class
<code>valarray&lt;T&gt;</code>,<sup>279)</sup>    which    has    zero
length<del> until it is passed into a library function as a modifiable
lvalue or through a non-constant this pointer</del>.<sup>280)</sup>

            </p>
            <p>

<ins><i>Postcondition</i>: <code>size() == 0</code>.</ins>

            </p>
            <p>

<i>Footnote  280</i>:  This default  constructor  is essential,  since
arrays  of  <code>valarray</code>  <del>are  likely to  prove  useful.
There  shall also  be  a way  to change  the  size of  an array  after
initialization;  this  is  supplied  by the  semantics</del>  <ins>may be
useful.   The  length  of  an  empty  array  can  be  increased  after
initialization  by  means</ins>  of the  <code>resize()</code>  member
function.

            </p>
        </blockquote>





<hr>
<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
<p><b>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

The computed and  "fill" assignment operators of <code>valarray</code>
helper     array     class    templates     (<code>slice_array</code>,
<code>gslice_array</code>,         <code>mask_array</code>,        and
<code>indirect_array</code>) are const  member functions of each class
template     (the     latter    by     the     resolution    of  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>
since  they have reference  semantics and thus do  not affect
the state of  the object on which they are  called.  However, the copy
assignment  operators  of  these  class  templates,  which  also  have
reference semantics,  are non-const.   The absence of  constness opens
the door to speculation about whether they really are intended to have
reference semantics (existing implementations vary widely).

        </p>

<p>
Pre-Kona, Martin adds:
</p>

<p>
I realized that adding the const qualifier to the
functions as I suggested would break the const correctness of the
classes. A few possible solutions come to mind:
</p>

<ol>
<li>Add the const qualifier to the return types of these functions.</li>
<li>Change the return type of all the functions to void to match
the signatures of all the other assignment operators these classes
define.</li>
<li>Prohibit the copy assignment of these classes by declaring the
copy assignment operators private (as is done and documented by
some implementations).</li>
</ol>



<p><b>Proposed resolution:</b></p>
        <p>

Declare  the  copy  assignment  operators  of all  four  helper  array
class templates const.

        </p>
        <p>

Specifically,  make the following edits:

        </p>
        <p>

Change     the    signature     in     26.6.5 [template.slice.array]    and
26.6.5.1 [slice.arr.assign] as follows:

        </p>
        <blockquote><pre>
<code><ins>const</ins> slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>

        </pre></blockquote>
        <p>

Change     the     signature     in    26.6.7 [template.gslice.array]     and
26.6.7.1 [gslice.array.assign] as follows:

        </p>
        <blockquote><pre>
<code><ins>const</ins> gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>

        </pre></blockquote>
        <p>

Change the  signature in 26.6.8 [template.mask.array]  and 26.6.8.1 [mask.array.assign] as
follows:

        </p>
        <blockquote><pre>
<code><ins>const</ins> mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>

        </pre></blockquote>
        <p>

Change     the     signature     in    26.6.9 [template.indirect.array] and
26.6.9.1 [indirect.array.assign] as follows:

        </p>
        <blockquote><pre>
<code><ins>const</ins> indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>

        </pre></blockquote>


<p><i>[
Kona (2007) Added const qualification to the return types and set to Ready.
]</i></p>





<hr>
<h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
<p><b>Section:</b> 27.9.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

<code>basic_filebuf</code>  dtor is  specified to  have  the following
straightforward effects:

        </p>
        <blockquote><p>

<i>Effects</i>:       Destroys      an      object       of      class
<code>basic_filebuf</code>. Calls <code>close()</code>.

        </p></blockquote>
        <p>

<code>close()</code> does a lot of potentially complicated processing,
including calling <code>overflow()</code> to write out the termination
sequence  (to   bring  the  output  sequence  to   its  initial  shift
state). Since  any of the  functions called during the  processing can
throw an exception, what should the  effects of an exception be on the
dtor? Should the  dtor catch and swallow it or  should it propagate it
to the caller?  The text doesn't  seem to provide any guidance in this
regard  other  than  the  general  restriction on  throwing  (but  not
propagating)  exceptions  from   destructors  of  library  classes  in
17.6.4.12 [res.on.exception.handling].

        </p>
        <p>

Further,  the last thing  <code>close()</code> is  specified to  do is
call <code>fclose()</code> to close the <code>FILE</code> pointer. The
last sentence of the <i>Effects</i> clause reads:

        </p>
        <blockquote><p>

...   If    any   of    the   calls   to    <code>overflow</code>   or
<code>std::fclose</code> fails then <code>close</code> fails.

        </p></blockquote>
        <p>

This  suggests that  <code>close()</code>  might be  required to  call
<code>fclose()</code>   if  and  only   if  none   of  the   calls  to
<code>overflow()</code> fails, and avoid closing the <code>FILE</code>
otherwise. This  way, if  <code>overflow()</code> failed to  flush out
the data, the caller  would have  the opportunity to  try to  flush it
again (perhaps  after trying  to deal with  whatever problem  may have
caused the failure), rather than losing it outright.

        </p>
        <p>

On the other hand,  the function's <i>Postcondition</i> specifies that
<code>is_open() ==  false</code>, which  suggests that it  should call
<code>fclose()</code>       unconditionally.       However,      since
<i>Postcondition</i> clauses  are specified for many  functions in the
standard,  including constructors  where they  obviously  cannot apply
after an  exception, it's not clear  whether this <i>Postcondition</i>
clause is intended to apply even after an exception.

        </p>
        <p>

It  might  be worth  noting  that  the  traditional behavior  (Classic
Iostreams  <code>fstream::close()</code> and  C <code>fclose()</code>)
is  to  close  the  <code>FILE</code> unconditionally,  regardless  of
errors.

        </p>

<p><i>[
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a> for related issues.
]</i></p>




<p><b>Proposed resolution:</b></p>
        <p>

After discussing this  on the reflector (see the  thread starting with
c++std-lib-17650) we propose that <code>close()</code> be clarified to
match the traditional behavior, that is to close the <code>FILE</code>
unconditionally,  even after  errors or  exceptions.  In  addition, we
propose the dtor description be amended so as to explicitly require it
to catch and swallow any exceptions thrown by <code>close()</code>.

        </p>
        <p>

Specifically,   we   propose   to   make  the   following   edits   in
27.9.1.4 [filebuf.members]:

        </p>
        <blockquote>
            <pre>
<code>basic_filebuf&lt;charT,traits&gt;* close();</code>

            </pre>
            <p>

<i>Effects</i>:  If <code>is_open()  == false</code>,  returns  a null
pointer.        If      a       put      area       exists,      calls
<code>overflow(traits::eof())</code> to flush  characters. If the last
virtual   member  function   called  on   <code>*this</code>  (between
<code>underflow</code>,  <code>overflow</code>,  <code>seekoff</code>,
and   <code>seekpos</code>)  was   <code>overflow</code>   then  calls
<code>a_codecvt.unshift</code> (possibly several times) to determine a
termination   sequence,    inserts   those   characters    and   calls
<code>overflow(traits::eof())</code>  again.  Finally<ins>, regardless
of whether  any of the preceding  calls fails or  throws an exception,
the  function</ins> <del>it</del>  closes   the  file   ("as   if"  by   calling
<code>std::fclose(file)</code>).<sup>334)</sup>  If any  of  the calls
<ins>made    by   the    function</ins><del>to   <code>overflow</code>
or</del><ins>,  including  </ins><code>std::fclose</code><ins>, </ins>
fails then <code>close</code> fails<ins>  by returning a null pointer.
If one of these calls throws an exception, the exception is caught and
rethrown after closing the file.</ins>

            </p>
        </blockquote>
        <p>

And to make the following edits in 27.9.1.2 [filebuf.cons].

        </p>
        <blockquote>
            <pre>
<code>virtual ~basic_filebuf();</code>

            </pre>
            <p>

<i>Effects</i>:       Destroys      an      object       of      class
<code>basic_filebuf&lt;charT,traits&gt;</code>.                   Calls
<code>close()</code>.    <ins>If  an   exception  occurs   during  the
destruction of the object, including the call to <code>close()</code>,
the     exception    is     caught    but     not     rethrown    (see
17.6.4.12 [res.on.exception.handling]).</ins>

            </p>
        </blockquote>





<hr>
<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
<p><b>Section:</b> 27.2.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

27.2.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
clause 27 except  for <code>ios_base::imbue</code> causes any instance
of                   <code>basic_ios::imbue</code>                  or
<code>basic_streambuf::imbue</code> to be called."

        </p>
        <p>

That      contradicts      the      <i>Effects</i>     clause      for
<code>basic_streambuf::pubimbue()</code>  which requires  the function
to do just that: call <code>basic_streambuf::imbue()</code>.

        </p>


<p><b>Proposed resolution:</b></p>
        <p>

To    fix   this,    rephrase    the   sentence    above   to    allow
<code>pubimbue</code> to do what  it was designed to do. Specifically.
change 27.2.1 [iostream.limits.imbue], p1 to read:

        </p>
        <blockquote><p>

No     function    described     in    clause     27     except    for
<code>ios_base::imbue</code>  <ins>and <code>basic_filebuf::pubimbue</code></ins>
causes    any    instance    of    <code>basic_ios::imbue</code>    or
<code>basic_streambuf::imbue</code> to be called. ...

        </p></blockquote>





<hr>
<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
<p><b>Section:</b> 26.6.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

The behavior of the  <code>valarray</code> copy assignment operator is
defined only when both sides have  the same number of elements and the
spec is explicit about assignments of arrays of unequal lengths having
undefined behavior.

        </p>
        <p>

However, the generalized  subscripting assignment operators overloaded
on <code>slice_array</code>  et al (26.6.2.2 [valarray.assign])  don't have any
such restriction, leading  the reader to believe that  the behavior of
these  overloads is  well defined  regardless  of the  lengths of  the
arguments.

        </p>
        <p>

For example,  based on  the reading  of the spec  the behavior  of the
snippet below can be expected to be well-defined:

        </p>
        <pre>    const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
    const std::valarray&lt;int&gt; a (1, 3);        // a = { 1, 1, 1 }
    std::valarray&lt;int&gt;       b (2, 4);        // b = { 2, 2, 2, 2 }

    b = a [from_0_to_3];
        </pre>
        <p>

In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>,
<code>{  1,  1, 1,  2  }</code>,  or  anything else,  indicating  that
existing implementations vary.

        </p>

<p>
Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
Proposal for Standard C++ Array Classes (see c++std-lib-704;
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>):
</p>
<blockquote><p>
  ...if the size of the array on the right hand side of the equal
  sign differs from the size of the array on the left, a run time
  error occurs. How this error is handled is implementation
  dependent; for compilers which support it, throwing an exception
  would be reasonable.
</p></blockquote>

<p>
And see more history in
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
</p>

        <p>

It has  been argued in  discussions on the committee's  reflector that
the semantics of all <code>valarray</code> assignment operators should
be permitted to be undefined unless  the  length  of the arrays  being
assigned is the same as the length of the one being assigned from. See
the thread starting at c++std-lib-17786.

        </p>
        <p>

In order  to reflect  such views, the  standard must specify  that the
size of the  array referred to by the argument  of the assignment must
match the size of the array  under assignment, for example by adding a
<i>Requires</i> clause to 26.6.2.2 [valarray.assign] as follows:

        </p>
        <blockquote><p>

<i>Requires</i>: The length of the  array to which the argument refers
equals <code>size()</code>.

        </p></blockquote>

        <p>

Note that it's  far from clear that such leeway  is necessary in order
to implement <code>valarray</code> efficiently.

        </p>


<p><b>Proposed resolution:</b></p>
<p>
Insert new paragraph into 26.6.2.2 [valarray.assign]:
</p>

<blockquote>
<pre>valarray&lt;T&gt;&amp; operator=(const slice_array&lt;T&gt;&amp;); 
valarray&lt;T&gt;&amp; operator=(const gslice_array&lt;T&gt;&amp;); 
valarray&lt;T&gt;&amp; operator=(const mask_array&lt;T&gt;&amp;); 
valarray&lt;T&gt;&amp; operator=(const indirect_array&lt;T&gt;&amp;);
</pre>
<blockquote>
<p><ins>
<i>Requires</i>: The length of the  array to which the argument refers
equals <code>size()</code>.
</ins></p>
<p>
These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2010-11-19</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a></p>
<p><b>Discussion:</b></p>
 <p>

Many member functions of <code>basic_string</code> are overloaded,
with some of the overloads taking a <code>string</code> argument,
others <code>value_type*</code>, others <code>size_type</code>, and
others still <code>iterators</code>. Often, the requirements on one of
the overloads are expressed in the form of <i>Effects</i>,
<i>Throws</i>, and in the Working Paper
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
also <i>Remark</i> clauses, while those on the rest of the overloads
via a reference to this overload and using a <i>Returns</i> clause.
</p>

<p>
The difference between the two forms of specification is that per
17.5.1.4 [structure.specifications], p3, an <i>Effects</i> clause specifies
<i>"actions performed by the functions,"</i> i.e., its observable
effects, while a <i>Returns</i> clause is <i>"a description of the
return value(s) of a function"</i> that does not impose any
requirements on the function's observable effects.
</p>

<p>
Since only <i>Notes</i> are explicitly defined to be informative and
all other paragraphs are explicitly defined to be normative, like
<i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also
impose normative requirements.
</p>

<p>
So by this strict reading of the standard there are some member
functions of <code>basic_string</code> that are required to throw an
exception under some conditions or use specific traits members while
many other otherwise equivalent overloads, while obliged to return the
same values, aren't required to follow the exact same requirements
with regards to the observable effects.
</p>

<p>
Here's an example of this problem that was precipitated by the change
from informative Notes to normative <i>Remark</i>s (presumably made to
address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>):
</p>

<p>
In the Working Paper, <code>find(string, size_type)</code> contains a
<i>Remark</i> clause (which is just a <i>Note</i> in the current
standard) requiring it to use <code>traits::eq()</code>.
</p>

<p>
<code>find(const charT *s, size_type pos)</code> is specified to
return <code>find(string(s), pos)</code> by a <i>Returns</i> clause
and so it is not required to use <code>traits::eq()</code>. However,
the Working Paper has replaced the original informative <i>Note</i>
about the function using <code>traits::length()</code> with a
normative requirement in the form of a <i>Remark</i>. Calling
<code>traits::length()</code> may be suboptimal, for example when the
argument is a very long array whose initial substring doesn't appear
anywhere in <code>*this</code>.
</p>

<p>
Here's another similar example, one that existed even prior to the
introduction of <i>Remark</i>s:
</p>

<p>
<code> insert(size_type pos, string, size_type, size_type)</code> is
required to throw <code>out_of_range</code> if <code>pos &gt;
size()</code>.
</p>

<p>
<code>insert(size_type pos, string str)</code> is specified to return
<code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and
so its effects when <code>pos &gt; size()</code> are strictly speaking
unspecified.
</p><p>

</p>
I believe a careful review of the current <i>Effects</i> and
<i>Returns</i> clauses is needed in order to identify all such
problematic cases. In addition, a review of the Working Paper should
be done to make sure that the newly introduced normative <i>Remark</i>
clauses do not impose any undesirable normative requirements in place
of the original informative <i>Notes</i>.
<p></p>

<p><i>[
Batavia: Alan and Pete to work.
]</i></p>


<p><i>[
Bellevue: Marked as NAD Editorial.
]</i></p>


<p><i>[
Post-Sophia Antipolis:
Martin indicates there is still work to be done on this issue.
Reopened.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Tom proposes we say that, unless specified otherwise,
it is always the caller's responsibility to verify that supplied arguments
meet the called function's requirements.
If further semantics are specified
(e.g., that the function throws under certain conditions),
then it is up to the implementer to check those conditions.
Alan feels strongly that our current use of Requires in this context
is confusing, especially now that <tt>requires</tt> is a new keyword.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Move to Tentatively NAD.
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to Open.  Martin will work on proposed wording.
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to NAD Editorial, solved by revision to N3021.
</blockquote>




<p><b>Rationale:</b></p>
<p>
Solved by revision to N3021.
</p>


<p><b>Proposed resolution:</b></p>
<p>
</p>





<hr>
<h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</h3>
<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-01-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 28.8 [re.regex] lists a constructor
</p>

<blockquote><pre>template&lt;class InputIterator&gt;
basic_regex(InputIterator first, InputIterator last,
                       flag_type f = regex_constants::ECMAScript);
</pre></blockquote>

<p>
However, in section 28.8.2 [re.regex.construct], this constructor takes a 
pair of <tt>ForwardIterator</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 28.8.2 [re.regex.construct]:
</p>

<blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
  basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last, 
              flag_type f = regex_constants::ECMAScript);
</pre></blockquote>






<hr>
<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
<p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
is there an issue opened for (0,3) as complex number with
the French local?  With the English local, the above parses as an
imaginery complex number.  With the French locale it parses as a
real complex number.
</p>

<p>
Further notes/ideas from the lib-reflector, messages 17982-17984:
</p>

<blockquote>
<p>
Add additional entries in num_punct to cover the complex separator (French would be ';').
</p>
<p>
Insert a space before the comma, which should eliminate the ambiguity.
</p>
<p>
Solve the problem for ordered sequences in general, perhaps with a
dedicated facet.  Then complex should use that solution.
</p>
</blockquote>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
After much discussion, we agreed on the following: Add a footnote:
</p>
<p>
[In a locale in which comma is being used as a decimal point character,
inserting "showbase" into the output stream forces all outputs to show
an explicit decimal point character; then all inserted complex sequences
will extract unambiguously.]
</p>
<p>
And move this to READY status.
</p>
</blockquote>

<p><i>[
Pre-Sophia Antipolis, Howard adds:
]</i></p>


<blockquote>
Changed "showbase" to "showpoint" and changed from Ready to Review.
</blockquote>

<p><i>[
Post-Sophia Antipolis:
]</i></p>


<blockquote>
<p>
I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready.  We subsequently
voted the footnote into the WP with "showbase".
</p>
<p>
I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add a footnote to 26.4.6 [complex.ops] p16:
</p>

<blockquote>
[In a locale in which comma is being used as a decimal point character,
inserting <tt>showpoint</tt> into the output stream forces all outputs to show
an explicit decimal point character; then all inserted complex sequences
will extract unambiguously.]
</blockquote>





<hr>
<h3><a name="630"></a>630. arrays of valarray</h3>
<p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
        <p>

Section 26.2 [numeric.requirements], p1     suggests     that     a
<code>valarray</code>  specialization on  a  type <code>T</code>  that
satisfies  the requirements enumerated  in the  paragraph is  itself a
valid  type   on  which  <code>valarray</code>   may  be  instantiated
(Footnote       269        makes       this       clear).        I.e.,
<code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
<code>T</code>   is   valid.    However,  since   implementations   of
<code>valarray</code> are permitted to initialize storage allocated by
the class by  invoking the default ctor of  <code>T</code> followed by
the    copy    assignment    operator,   such    implementations    of
<code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
specializations of <code>valarray</code> whose assignment operator had
undefined behavior when the size of its argument didn't match the size
of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
be  impossible  to resize  such  an array  of  arrays  by calling  the
<code>resize()</code> member  function on it if the  function used the
copy  assignment operator  after constructing  all elements  using the
default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
obtain default-initialized storage) as it's permitted to do.

        </p>
        <p>

Stated      more     generally,      the      problem     is      that
<code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
required or  guaranteed to have well-defined semantics  for every type
<code>T</code>     that      satisfies     all     requirements     in
26.2 [numeric.requirements].

        </p>
        <p>

I  believe  this  problem  was  introduced  by  the  adoption  of  the
resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
<i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
operator  of  the original  numerical  array  classes  proposed in  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
(both  from 1993), had  well-defined semantics  for arrays  of unequal
size (the  latter explicitly  only when <code>*this</code>  was empty;
assignment of non empty arrays of unequal size was a runtime error).

        </p>
        <p>

The  justification for  the  change given  in  N0857 was the "loss  of
performance [deemed]  only significant  for very simple  operations on
small arrays or for architectures with very few registers."

        </p>
        <p>

Since tiny  arrays on a  limited subset of hardware  architectures are
likely  to  be  an   exceedingly  rare  case  (despite  the  continued
popularity of  x86) I  propose to revert  the resolution and  make the
behavior    of   all   <code>valarray</code>    assignment   operators
well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
size).   I have implemented  this change  and measured  no significant
degradation  in performance in  the common  case (non-empty  arrays of
equal size).  I  have measured a 50% (and in  some cases even greater)
speedup  in the  case of  assignments to  empty arrays  versus calling
<code>resize()</code>  first followed  by  an invocation  of the  copy
assignment operator.

        </p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
If no proposed wording by June meeting, this issue should be closed NAD.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Move resolution 1 to Ready.
</p>
<p>
Howard: second resolution has been commented out (made invisible).
Can be brought back on demand.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
        <p>

Change 26.6.2.2 [valarray.assign], p1 as follows:

        </p>
        <blockquote>
            <p>
                <code>

valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);

                </code>
            </p>
            <p>

-1- Each element of the <code>*this</code> array is assigned the value
of  the  corresponding  element   of  the  argument  array.   <del>The
resulting behavior is undefined if </del><ins>When </ins>the length of
the  argument  array  is  not   equal  to  the  length  of  the  *this
array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
arrays     the      same     length,     as      if     by     calling
<code>resize(x.size())</code>, before performing the assignment.</ins>

            </p>
        </blockquote>
        <p>

And  add a new  paragraph just  below paragraph  1 with  the following
text:

        </p>
        <blockquote>
            <p>

<ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>

            </p>
        </blockquote>
        <p>

Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:

        </p>
        <blockquote>
            <p>

<ins>-?- When the length,  <i><code>N</code></i> of the array referred
to by the  argument is not equal to  the length of <code>*this</code>,
the  operator resizes <code>*this</code>  to make  the two  arrays the
same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
performing the assignment.</ins>

            </p>
        </blockquote>

<p><i>[
pre-Sophia Antipolis, Martin adds the following compromise wording, but
prefers the original proposed resolution:
]</i></p>






<p><i>[
Kona (2007): Gaby to propose wording for an alternative resolution in
which you can assign to a <tt>valarray</tt> of size 0, but not to any other
<tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
]</i></p>





<hr>
<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
<p><b>Section:</b> 20.9.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
<p><b>Discussion:</b></p>

<p>
20.9.5.1 [allocator.members] says:
</p>
<blockquote>
<pre>pointer address(reference <i>x</i>) const;</pre>
<blockquote>
<p>
-1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
</p>
</blockquote>
</blockquote>

<p>
20.9.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
only defines the semantics of copy construction, but also restricts what an overloaded
<tt>operator&amp;</tt> may do.  I believe proposals are in the works (such as concepts
and rvalue reference) to decouple these two requirements.  Indeed it is not evident
that we should disallow overloading <tt>operator&amp;</tt> to return something other
than the address of <tt>*this</tt>.
</p>

<p>
An example of when you want to overload <tt>operator&amp;</tt> to return something
other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
(or its replacement, currently code-named <tt>bit_vector</tt>).  Taking the address of
such a proxy reference should logically yield a proxy pointer, which when dereferenced,
yields a copy of the original proxy reference again.
</p>

<p>
On the other hand, some code truly needs the address of an object, and not a proxy
(typically for determining the identity of an object compared to a reference object).
<a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with 
<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
It appears to me that this would be useful functionality for the default allocator.  Adopting
this definition for <tt>allocator::address</tt> would free the standard of requiring
anything special from types which overload <tt>operator&amp;</tt>.  Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>
is expected to make use of <tt>allocator::address</tt> mandatory for containers.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.5.1 [allocator.members]:
</p>

<blockquote>
<pre>pointer address(reference <i>x</i>) const;</pre>
<blockquote>
<p>
-1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
</p>
</blockquote>

<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
<blockquote>
<p>
-2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
</p>
</blockquote>
</blockquote>

<p><i>[
post Oxford:  This would be rendered NAD Editorial by acceptance of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
]</i></p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
was subsequently split out into a separate paper N2436 for the purposes of voting.
The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
issue to Ready status to be voted into the WP at Kona.
]</i></p>







<hr>
<h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
<p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-08 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The table of allocator requirements in 20.2.5 [allocator.requirements] describes
<tt>allocator::address</tt> as:
</p>
<blockquote><pre>a.address(r)
a.address(s)
</pre></blockquote>
<p>
where <tt>r</tt> and <tt>s</tt> are described as:
</p>
<blockquote><p>
a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>. 
</p></blockquote>

<p>
and <tt>p</tt> is 
</p>

<blockquote><p>
a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>, 
where <tt>a1 == a</tt>
</p></blockquote>

<p>
This all implies that to get the address of some value of type <tt>T</tt> that
value must have been allocated by this allocator or a copy of it.
</p>

<p>
However sometimes container code needs to compare the address of an external value of
type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
may want to compare the address of the external value <tt>t</tt> with that of a value
stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
want to make similar comparisons (to check for self-referencing calls).
</p>

<p>
Mandating that <tt>allocator::address</tt> can only be called for values which the
allocator allocated seems overly restrictive.
</p>

<p><i>[
post San Francisco:
]</i></p>


<blockquote>
Pablo recommends NAD Editorial, solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
</blockquote>

<p><i>[
2009-04-28 Pablo adds:
]</i></p>


<blockquote>
Tentatively-ready NAD Editorial as fixed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Fixed by N2768.
</blockquote>

<p><i>[
2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Addressed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.2.5 [allocator.requirements]:
</p>

<blockquote>
<p>
<tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
</p>
<p>
<tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the 
expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
</p>
</blockquote>

<p><i>[
post Oxford:  This would be rendered NAD Editorial by acceptance of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
]</i></p>


<p><i>[
Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
no resolution to this issue was recorded.  Moved to Open.
]</i></p>







<hr>
<h3><a name="638"></a>638. deque end invalidation during erase</h3>
<p><b>Section:</b> 23.3.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Steve LoBasso <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard states at 23.3.2.3 [deque.modifiers]/4:
</p>
<blockquote><pre>deque erase(...)
</pre>
 <p>
<i>Effects:</i> ... An erase at either end of the deque invalidates only
the iterators and the references to the erased elements.
</p>
</blockquote>
<p>
This does not state that iterators to end will be invalidated.
It needs to be amended in such a way as to account for end invalidation.
</p>
<p>
Something like:
</p>
<blockquote><p>
Any time the last element is erased, iterators to end are invalidated.
</p></blockquote>

<p>
This would handle situations like:
</p>
<blockquote><pre>erase(begin(), end())
erase(end() - 1)
pop_back()
resize(n, ...) where n &lt; size()
pop_front() with size() == 1

</pre></blockquote>

<p><i>[
Post Kona, Steve LoBasso notes:
]</i></p>


<blockquote>
My only issue with the proposed resolution is that it might not be clear
that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
iterators.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 23.3.2.3 [deque.modifiers], p4:
</p>

<blockquote>
<pre>iterator erase(const_iterator position); 
iterator erase(const_iterator first, const_iterator last);
</pre>

<blockquote>
<p>
-4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
invalidates all the iterators and references to elements of the
<tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
either end of the <tt>deque</tt> invalidates only the iterators and the
references to the erased elements<ins>, except that erasing at the end
also invalidates the past-the-end iterator</ins>.
</p>
</blockquote>
</blockquote>



<p><i>[
Kona (2007): Proposed wording added and moved to Review.
]</i></p>


<p><i>[
Bellevue:
]</i></p>


<blockquote>
Note that there is existing code that relies on iterators not being
invalidated, but there are also existing implementations that do
invalidate iterators. Thus, such code is not portable in any case. There
is a pop_front() note, which should possibly be a separate issue. Mike
Spertus to evaluate and, if need be, file an issue.
</blockquote>




<hr>
<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
<p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The arithmetic inserters are described in 27.7.2.6.2 [ostream.inserters.arithmetic].
Although the section starts with a listing of the inserters including
the new ones:
</p>

<blockquote><pre>operator&lt;&lt;(long long val );
operator&lt;&lt;(unsigned long long val );
</pre></blockquote>

<p>
the text in paragraph 1, which describes the corresponding effects
of the inserters, depending on the actual type of val, does not
handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
</p>

<p><i>[
Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
misses any reference to extended integral types supplied by the
implementation - one of the additions by core a couple of working papers
back.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
In 27.7.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
</p>

<blockquote>
When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
<tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
occurs as if it performed the following code fragment:
</blockquote>





<hr>
<h3><a name="643"></a>643. Impossible "as if" clauses</h3>
<p><b>Section:</b> 27.9.1.1 [filebuf], 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current standard 14882:2003(E) as well as N2134 have the
following
defects:
</p>

<p>
27.9.1.1 [filebuf]/5 says:
</p>

<blockquote>
<p>
In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a 
facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
</p>
<blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
  use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
</pre></blockquote>
</blockquote>

<p>
<tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
copyconstructible, so the codecvt construction should fail to compile.
</p>

<p>
A similar issue arises in 22.4.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 27.9.1.1 [filebuf]/5 change the "as if" code
</p>

<blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
  use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
</pre></blockquote>

<p>
In 22.4.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
</p>

<blockquote>
<p>
A local variable <tt><i>punct</i></tt> is initialized via
</p>
<blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
</pre></blockquote>
</blockquote>

<p>
(Please note also the additional provided trailing semicolon)
</p>






<hr>
<h3><a name="646"></a>646. const incorrect match_result members</h3>
<p><b>Section:</b> 28.10.5 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
28.10.5 [re.results.form] (root and para 3) in N2134 defines the two function template
members format as non-const functions, although they are declared
as const in 28.10 [re.results]/3.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
in section 28.10.5 [re.results.form].
</p>





<hr>
<h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Both the class definition of regex_token_iterator (28.12.2 [re.tokiter]/6) and the latter member specifications (28.12.2.2 [re.tokiter.comp]/1+2) declare both comparison operators as
non-const functions. Furtheron, both dereference operators are
unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
</p>


<p><b>Proposed resolution:</b></p>
<p>
1) In (28.12.2 [re.tokiter]/6) change the current declarations
</p>

<blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
const value_type&amp; operator*() <ins>const</ins>;
const value_type* operator-&gt;() <ins>const</ins>;
</pre></blockquote>

<p>
2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
</p>

<blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
</pre></blockquote>

<p>
3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
</p>

<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
const value_type* operator-&gt;() <ins>const</ins>;
</pre></blockquote>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
is to adopt the proposed wording in this issue).
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
the effects of the three non-default constructors of class
template regex_token_iterator but is does not clarify which values
are legal values for submatch/submatches. This becomes
an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
the notion of a "current match" by saying:
</p>

<blockquote><p>
The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
== -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
<tt>subs[N]</tt>.
</p></blockquote>

<p>
It's not clear to me, whether other negative values except -1
are legal arguments or not - it seems they are not.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the following precondition paragraph just before the current
28.12.2.1 [re.tokiter.cnstr]/2:
</p>

<blockquote><p>
<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
</p></blockquote>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
is to adopt the proposed wording in this issue).
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="652"></a>652. regex_iterator and const correctness</h3>
<p><b>Section:</b> 28.12.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Both the class definition of regex_iterator (28.12.1 [re.regiter]/1) and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2) declare both comparison operators as
non-const functions. Furtheron, both dereference operators are
unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
as well as in (28.12.1.3 [re.regiter.deref]/1+2).
</p>


<p><b>Proposed resolution:</b></p>
<p>
1) In (28.12.1 [re.regiter]/1) change the current declarations
</p>

<blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
const value_type&amp; operator*() <ins>const</ins>;
const value_type* operator-&gt;() <ins>const</ins>;
</pre></blockquote>

<p>
2) In 28.12.1.3 [re.regiter.deref] change the following declarations
</p>

<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
const value_type* operator-&gt;() <ins>const</ins>;
</pre></blockquote>

<p>
3) In 28.12.1.2 [re.regiter.comp] change the following declarations
</p>

<blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
</pre></blockquote>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
is to adopt the proposed wording in this issue).
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
<p><b>Section:</b> 26.5.1.4 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 98 and para 5 in 26.5.1.4 [rand.req.eng] specify
the IO insertion and extraction semantic of random
number engines. It can be shown, v.i., that the specification
of the extractor cannot guarantee to fulfill the requirement
from para 5:
</p>

<blockquote><p>
If a textual representation written via os &lt;&lt; x was
subsequently read via is &gt;&gt; v, then x == v provided that
there have been no intervening invocations of x or of v.
</p></blockquote>

<p>
The problem is, that the extraction process described in
table 98 misses to specify that it will initially set the
if.fmtflags to ios_base::dec, see table 104:
</p>

<blockquote><p>
dec: converts integer input or generates integer output
in decimal base
</p></blockquote>

<p>
Proof: The following small program demonstrates the violation
of requirements (exception safety not fulfilled):
</p>

<blockquote><pre>#include &lt;cassert&gt;
#include &lt;ostream&gt;
#include &lt;iostream&gt;
#include &lt;iomanip&gt;
#include &lt;sstream&gt;

class RanNumEngine {
  int state;
public:
  RanNumEngine() : state(42) {}

  bool operator==(RanNumEngine other) const {
      return state == other.state;
  }

  template &lt;typename Ch, typename Tr&gt;
  friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
    Ch old = os.fill(os.widen(' ')); // Sets space character
    std::ios_base::fmtflags f = os.flags();
    os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
    os.fill(old); // Undo
    os.flags(f);
    return os;
  }

  template &lt;typename Ch, typename Tr&gt;
  friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
       // Uncomment only for the fix.

    //std::ios_base::fmtflags f = is.flags();
    //is &gt;&gt; std::dec;
    is &gt;&gt; engine.state;
    //is.flags(f);
    return is;
  }
};

int main() {
    std::stringstream s;
    s &lt;&lt; std::setfill('#'); // No problem
        s &lt;&lt; std::oct; // Yikes!
        // Here starts para 5 requirements:
    RanNumEngine x;
    s &lt;&lt; x;
    RanNumEngine v;
    s &gt;&gt; v;
    assert(x == v); // Fails: 42 == 34
}
</pre></blockquote>

<p>
A second, minor issue seems to be, that the insertion
description from table 98 unnecessarily requires the
addition of ios_base::fixed (which only influences floating-point
numbers). Its not entirely clear to me whether the proposed
standard does require that the state of random number engines
is stored in integral types or not, but I have the impression
that this is the indent, see e.g. p. 3
</p>

<blockquote><p>
The specification of each random number engine defines the
size of its state in multiples of the size of its result_type.
</p></blockquote>

<p>
If other types than integrals are supported, then I wonder why
no requirements are specified for the precision of the stream.
</p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
<p><b>Section:</b> 26.5.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 26.5.2 [rand.synopsis] we have the declaration
</p>

<blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
  size_t bits&gt;
result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
</pre></blockquote>

<p>
Besides the "result_type" issue (already recognized by Bo Persson
at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
the template parameter order is not reasonably choosen: Obviously
one always needs to specify all three parameters, although usually
only two are required, namely the result type RealType and the
wanted bits, because UniformRandomNumberGenerator can usually
be deduced.
</p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
<p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-19 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The header <tt>&lt;functional&gt;</tt> synopsis in 20.8 [function.objects]
contains the following two free comparison operator templates
for the <tt>function</tt> class template
</p>

<blockquote><pre>template&lt;class Function1, class Function2&gt;
void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
template&lt;class Function1, class Function2&gt;
void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
</pre></blockquote>

<p>
which are nowhere described. I assume that they are relicts before the
corresponding two private and undefined member templates in the function
template (see 20.8.14.2 [func.wrap.func] and  [func.wrap.func.undef]) have been introduced. The original free
function templates should be removed, because using an undefined entity
would lead to an ODR violation of the user.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Remove the above mentioned two function templates from
the header <tt>&lt;functional&gt;</tt> synopsis (20.8 [function.objects])
</p>

<blockquote><pre><del>template&lt;class Function1, class Function2&gt;
void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
template&lt;class Function1, class Function2&gt;
void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);</del>
</pre></blockquote>



<p><b>Rationale:</b></p>
Fixed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
Standard Library Applications for Deleted Functions.





<hr>
<h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
<p><b>Section:</b> 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-03-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Greg Herlihy has clearly demonstrated that a user defined input
iterator should have an operator-&gt;(), even if its
value type is a built-in type (comp.std.c++, "Re: Should any iterator
have an operator-&gt;() in C++0x?", March 2007).  And as Howard
Hinnant remarked in the same thread that the input iterator
<tt>istreambuf_iterator</tt> doesn't have one, this must be a
defect!
</p>
<p>
Based on Greg's example, the following code demonstrates the issue:
</p><pre> #include &lt;iostream&gt; 
 #include &lt;fstream&gt;
 #include &lt;streambuf&gt; 

 typedef char C;
 int main ()
 {
   std::ifstream s("filename", std::ios::in);
   std::istreambuf_iterator&lt;char&gt; i(s);

   (*i).~C();  // This is well-formed...
   i-&gt;~C();  // ... so this should be supported!
 }
</pre>
<p></p>
<p>
Of course, operator-&gt; is also needed when the value_type of
istreambuf_iterator is a class.
</p>
<p>
The operator-&gt; could be implemented in various ways.  For instance,
by storing the current value inside the iterator, and returning its
address.  Or by returning a proxy, like operator_arrow_proxy, from
<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
</p>
<p>
I hope that the resolution of this issue will contribute to getting a
clear and consistent definition of iterator concepts.
</p>

<p><i>[
Kona (2007): The proposed resolution is inconsistent because the return
type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
]</i></p>


<p><i>[
Niels Dekker (mailed to Howard Hinnant):
]</i></p>

<blockquote>
<p>
The proposed resolution does
not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
may in fact be a proxy.
</p>
<p>
AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
unspecified for some iterator categories") implies that for any iterator
class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
definition.  I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
</p>
<p>
Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
be removed from the resolution. I think it's up to the library
implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>.  As
longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>.  The main issue
is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
</p>
</blockquote>

<p><i>[
2009-04-30 Alisdair adds:
]</i></p>


<blockquote>
Note that operator-&gt; is now a requirement in the <tt>InputIterator</tt> concept, so
this issue cannot be ignored or existing valid programs will break when
compiled with an 0x library.
</blockquote>

<p><i>[
2009-05-29 Alisdair adds:
]</i></p>


<blockquote>
<p>
I agree with the observation that in principle the type 'pointer' may be a
proxy, and the words highlighting this are redundant.
</p>
<p>
However, in the current draught <tt>pointer</tt> is required to be exactly '<tt>charT *</tt>'
by the derivation from <tt>std::iterator</tt>.  At a minimum, the 4th parameter of
this base class template should become unspecified.  That permits the
introduction of a proxy as a nested class in some further undocumented (not
even exposition-only) base.
</p>
<p>
It also permits the <tt>istream_iterator</tt> approach where the cached value is
stored in the iterator itself, and the iterator serves as its own proxy for
post-increment <tt>operator++</tt> - removing the need for the existing
exposition-only nested class <tt>proxy</tt>.
</p>
<p>
Note that the current <tt>proxy</tt> class also has exactly the right properties to
serve as the pointer <tt>proxy</tt> too.  This is likely to be a common case where an
<tt>InputIterator</tt> does not hold internal state but delegates to another class.
</p>
<p>
Proposed Resolution:
</p>
<p>
In addition to the current proposal:
</p>
<p>
24.6.3 [istreambuf.iterator]
</p>
<blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
class istreambuf_iterator
  : public iterator&lt;input_iterator_tag, charT,
                    typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
</pre></blockquote>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Move the additional part into the proposed resolution, and wrap the
descriptive text in a Note.
</p>
<p><i>[Howard: done.]</i></p>

<p>
Move to Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add to the synopsis in 24.6.3 [istreambuf.iterator]:
</p>

<blockquote><pre>charT operator*() const;
<ins>pointer operator-&gt;() const;</ins>
istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
</pre></blockquote>

<p>
24.6.3 [istreambuf.iterator]
</p>

<blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
class istreambuf_iterator
  : public iterator&lt;input_iterator_tag, charT,
                    typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
</pre></blockquote>

<p>
Change 24.6.3 [istreambuf.iterator], p1:
</p>

<blockquote><p>
The class template <tt>istreambuf_iterator</tt> reads successive
characters from the <tt>streambuf</tt> for which it was constructed.
<tt>operator*</tt> provides access to the current input character, if
any. <ins>[<i>Note:</i> <tt>operator-&gt;</tt> may return a proxy. �
<i>end note</i>]</ins> Each time
<tt>operator++</tt> is evaluated, the iterator advances to the next
input character. If the end of stream is reached
(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
iterator becomes equal to the end of stream iterator value. The default
constructor <tt>istreambuf_iterator()</tt> and the constructor
<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
object suitable for use as an end-of-range.
</p></blockquote>







<hr>
<h3><a name="660"></a>660. Missing Bitwise Operations</h3>
<p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-04-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Section 20.8 [function.objects] provides <span id="st" name="st" class="st">function</span>
<span id="st" name="st" class="st">objects</span> for some unary and binary 
operations, but others are missing. In a LWG reflector discussion, beginning 
with c++std-lib-18078, pros and cons of adding some of the missing operations 
were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
Yes, I see the chicken and egg problems here, but it would be nice to see a 
couple of genuine uses before making additions."</p>
<p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
already added these functions, either publicly or for internal use. For example, 
Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we 
need those <span id="st" name="st" class="st">function</span>
<span id="st" name="st" class="st">objects</span> to represent various parallel 
collective operations (reductions, prefix reductions, etc.) in the new Message 
Passing Interface (MPI) library."</p>
<p>Because the bitwise operators have the strongest use cases, the proposed 
resolution is limited to them.</p>


<p><b>Proposed resolution:</b></p>
<p>To 20.8 [function.objects], Function objects, paragraph 2, add to the header 
&lt;functional&gt; synopsis:</p>
<blockquote>
  <pre>template &lt;class T&gt; struct bit_and;
template &lt;class T&gt; struct bit_or;
template &lt;class T&gt; struct bit_xor;</pre>
</blockquote>
<p>At a location in clause 20 to be determined by the Project Editor, add:</p>
<blockquote>
  <p>The library provides basic function object classes for all of the bitwise 
  operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
  <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
  T operator()(const T&amp; x , const T&amp; y ) const;
};</pre>
  <blockquote>
    <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
  </blockquote>
  <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
  T operator()(const T&amp; x , const T&amp; y ) const;
};</pre>
  <blockquote>
    <p><code>operator()</code> returns <code>x | y</code> .</p>
  </blockquote>
  <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
  T operator()(const T&amp; x , const T&amp; y ) const;
};</pre>
  <blockquote>
    <p><code>operator()</code> returns <code>x ^ y</code> .</p>
  </blockquote>
</blockquote>





<hr>
<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3>
<p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-04-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
To the more drastic changes of 27.7.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
the explicit description of the extraction of the types short and int in
terms of as-if code fragments.
</p>

<ol>
<li>
The corresponding as-if extractions in paragraph 2 and 3 will never
result in a change of the operator&gt;&gt; argument val, because the
contents of the local variable lval is in no case written into val.
Furtheron both fragments need a currently missing parentheses in the
beginning of the if-statement to be valid C++.
</li>
<li>
I would like to ask whether the omission of a similar explicit
extraction of unsigned short and unsigned int in terms of long -
compared to their corresponding new insertions, as described in 27.7.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or an
oversight.
</li>
</ol>


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
In 27.7.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
</p>
<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
iostate err = 0;
long lval;
use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
if (err == 0) <ins>{</ins>
  <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval)<del>)</del>
      err = ios_base::failbit;
  <ins>else
    val = static_cast&lt;short&gt;(lval);
}</ins>
setstate(err);
</pre></blockquote>

<p>
Similarily in 27.7.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
</p>

<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
iostate err = 0;
long lval;
use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
if (err == 0) <ins>{</ins>
  <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval)<del>)</del>
      err = ios_base::failbit;
  <ins>else
    val = static_cast&lt;int&gt;(lval);
}</ins>
setstate(err);
</pre></blockquote>
</li>
<li>
---
</li>
</ol>


<p><i>[
Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
is incorrectly italicized in the code fragments corresponding to
<tt>operator&gt;&gt;(short &amp;)</tt> and <tt>operator &gt;&gt;(int &amp;)</tt>. Also, val -- which appears
twice on the line with the <tt>static_cast</tt> in the proposed resolution --
should be italicized. Also, in response to part two of the issue: this
is deliberate.
]</i></p>





<hr>
<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt&lt;char, char, mbstate_t&gt;</tt></h3>
<p><b>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
22.4.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
</p>

<blockquote><p>
<i>Effects:</i> Places characters starting at to that should be appended to
terminate a sequence when the current <tt>stateT</tt> is given by
<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
pointer pointing one beyond the last element successfully stored.
<em><tt>codecvt&lt;char, char, mbstate_t&gt;</tt> stores no characters.</em>
</p></blockquote>

<p>
The following objection has been raised:
</p>

<blockquote><p>
Since the C++ Standard permits a nontrivial conversion for the required
instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
</p></blockquote>

<p>
[Plum ref _222152Y50]
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 22.4.1.4.2 [locale.codecvt.virtuals], p7:
</p>

<blockquote>
<p>
<i>Effects:</i> Places characters starting at <i>to</i> that should be
appended to terminate a sequence when the current <tt>stateT</tt> is
given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
destination elements, and leaves the <i>to_next</i> pointer pointing one
beyond the last element successfully stored. <del><tt>codecvt&lt;char, char,
mbstate_t&gt;</tt> stores no characters.</del>
</p>
</blockquote>





<hr>
<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
<p><b>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
22.4.1.4.2 [locale.codecvt.virtuals], para 8 says:
</p>

<blockquote><p>
<tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.
</p></blockquote>

<p>
The following objection has been raised:
</p>

<blockquote><p>
Despite what the C++ Standard 
says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since 
they can be nontrivial. At least one implementation does whatever the 
C functions do.
</p></blockquote>

<p>
[Plum ref _222152Y62]
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 22.4.1.4.2 [locale.codecvt.virtuals], p8:
</p>

<blockquote>
<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
<p>...</p>
<p>
<del><tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.</del>
</p>
</blockquote>






<hr>
<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
<p><b>Section:</b> 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
22.4.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
</p>

<blockquote><p>
<sup>257)</sup> For international 
specializations (second template parameter <tt>true</tt>) this is always four 
characters long, usually three letters and a space.
</p></blockquote>

<p>
The following objection has been raised:
</p>

<blockquote><p>
The international currency 
symbol is whatever the underlying locale says it is, not necessarily 
four characters long.
</p></blockquote>

<p>
[Plum ref _222632Y41]
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change footnote 253 in 22.4.6.3.2 [locale.moneypunct.virtuals]:
</p>

<blockquote>
<p>
<sup>253)</sup> For international specializations (second template
parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
four characters long, usually three letters and a space.
</p>
</blockquote>





<hr>
<h3><a name="671"></a>671. precision of hexfloat</h3>
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> John Salmon <b>Opened:</b> 2007-04-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I am trying to understand how TR1 supports hex float (%a) output.
</p>
<p>
As far as I can tell, it does so via the following:
</p>
<p>
8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
</p>
<p>
In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
the line:
floatfield == ios_base::scientific %E
</p>
<p>
add the two lines:
</p>
<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
floatfield == ios_base::fixed | ios_base::scientific %A 2
</pre></blockquote>
<p>
[Note: The additional requirements on print and scan functions, later
in this clause, ensure that the print functions generate hexadecimal
floating-point fields with a %a or %A conversion specifier, and that
the scan functions match hexadecimal floating-point fields with a %g
conversion specifier.  end note]
</p>
<p>
Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
</p>
<p>
For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
if str.precision() &gt; 0, then str.precision() is specified in the
conversion specification.
</p>
<p>
This would seem to imply that when floatfield == fixed|scientific, the
precision of the conversion specifier is to be taken from
str.precision().  Is this really what's intended?  I sincerely hope
that I'm either missing something or this is an oversight.  Please
tell me that the committee did not intend to mandate that hex floats
(and doubles) should by default be printed as if by %.6a.
</p>

<p><i>[
Howard: I think the fundamental issue we overlooked was that with %f,
%e, %g, the default precision was always 6.  With %a the default
precision is not 6, it is infinity.  So for the first time, we need to
distinguish between the default value of precision, and the precision
value 6.
]</i></p>


<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Leave this open for Robert and Daniel to work on.
</p>
<p>
Straw poll: Disposition?
</p>
<ul>
<li>Default is %.6a (i.e. NAD): 2</li>
<li>Always %a (no precision): 6</li>
<li>precision(-1) == %a: 3</li>
</ul>
<p>
Daniel and Robert have direction to write up wording for the "always %a" solution.
</p>

<p><i>[
2009-07-15 Robert provided wording.
]</i></p>

</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 22.4.2.2.2 [facet.num.put.virtuals], Stage 1, under p5 (near the end
of Stage 1):
</p>

<blockquote>
For conversion from a floating-point type, <tt>str.precision()</tt> is specified
<ins>as precision</ins> in the conversion specification
<ins>if <tt>floatfield != (ios_base::fixed | ios_base::scientific)</tt>, else no
precision is specified</ins>.
</blockquote>



<p><i>[
Kona (2007): Robert volunteers to propose wording.
]</i></p>





<hr>
<h3><a name="672"></a>672. Swappable requirements need updating</h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current <tt>Swappable</tt> is:
</p>

<blockquote>
<table border="1">
<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td><td><tt>t</tt> has the value originally held by <tt>u</tt>, and <tt>u</tt> has the value originally 
held by <tt>t</tt></td></tr>
<tr><td colspan="3">
<p>
The Swappable requirement is met by satisfying one or more of the following conditions:
</p>
<ul>
<li>
<tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34) 
and the <tt>CopyAssignable</tt> requirements (Table 36);
</li>
<li>
<tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same 
namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid 
and has the semantics described in this table.
</li>
</ul>
</td></tr>
</tbody></table>
</blockquote>

<p>
With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.  This is a minimum.
</p>

<p>
Additionally we may want to support proxy references such that the following code is acceptable:
</p>

<blockquote><pre>namespace Mine {

template &lt;class T&gt;
struct proxy {...};

template &lt;class T&gt;
struct proxied_iterator
{
   typedef T value_type;
   typedef proxy&lt;T&gt; reference;
   reference operator*() const;
   ...
};

struct A
{
   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
   void swap(A&amp;);
   ...
};

void swap(A&amp;, A&amp;);
void swap(proxy&lt;A&gt;, A&amp;);
void swap(A&amp;, proxy&lt;A&gt;);
void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);

}  // Mine

...

Mine::proxied_iterator&lt;Mine::A&gt; i(...)
Mine::A a;
swap(*i1, a);
</pre></blockquote>

<p>
I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
itself.  We do not need to anything in terms of implementation except not block their way with overly
constrained concepts.  That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
</p>



<p><b>Proposed resolution:</b></p>

<p>
Change 20.2.1 [utility.arg.requirements]:
</p>

<blockquote>

<p>
-1- The template definitions in the C++ Standard Library refer to various
named requirements whose details are set out in tables 31-38. In these
tables, <tt>T</tt> is a type to be supplied by a C++ program
instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
<tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
rvalue of type <tt>T</tt>.
</p>

<table border="1">
<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
<td><tt>t</tt> has the value originally
held by <tt>u</tt>, and
<tt>u</tt> has the value originally held
by <tt>t</tt></td></tr>
<tr><td colspan="3">
<p>
The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
</p>
<ul>
<li>
<tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
<del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
requirements (Table <del>36</del> <ins>35</ins>);
</li>
<li>
<tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
<tt>swap</tt> exists in the same namespace as the definition of
<tt>T</tt>, such that the expression
<tt>swap(t,u)</tt> is valid and has the
semantics described in this table.
</li>
</ul>
</td></tr>
</tbody></table>
</blockquote>



<p><i>[
Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
move semantics. The issue relating to the support of proxies is
separable from the one relating to move semantics, and it's bigger than
just swap. We'd like to address only the move semantics changes under
this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#742">742</a>) to handle proxies. Also, there
may be a third issue, in that the current definition of <tt>Swappable</tt> does
not permit rvalues to be operands to a swap operation, and Howard's
proposed resolution would allow the right-most operand to be an rvalue,
but it would not allow the left-most operand to be an rvalue (some swap
functions in the library have been overloaded to permit left operands to
swap to be rvalues).
]</i></p>





<hr>
<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
<p><b>Section:</b> 20.9.9 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Since the publication of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
there have been a few small but significant advances which should be included into
<tt>unique_ptr</tt>.  There exists a
<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
for all of these changes.
</p>

<ul>

<li>
<p>
Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
even if it is never used.  For example see
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
happened to <tt>auto_ptr</tt>.  I believe the most robust way to protect <tt>unique_ptr</tt> against this
type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
<tt>add_lvalue_reference&lt;T&gt;::type</tt>.  This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
This is simpler than creating a <tt>unique_ptr&lt;void&gt;</tt> specialization which isn't robust in the
face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
</p>

<p>
This resolution also supports instantiations such as <tt>unique_ptr&lt;void, free_deleter&gt;</tt>
which could be very useful to the client.
</p>

</li>

<li>
<p>
Efforts have been made to better support containers and smart pointers in shared
memory contexts.  One of the key hurdles in such support is not assuming that a
pointer type is actually a <tt>T*</tt>.  This can easily be accomplished
for <tt>unique_ptr</tt> by having the deleter define the pointer type:
<tt>D::pointer</tt>.  Furthermore this type can easily be defaulted to
<tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
type (example implementation
<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
This change has no run time overhead.  It has no interface overhead on
authors of custom delter types.  It simply allows (but not requires)
authors of custom deleter types to define a smart pointer for the
storage type of <tt>unique_ptr</tt> if they find such functionality
useful.  <tt>std::default_delete</tt> is an example of a deleter which
defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
and not including a <tt>pointer typedef</tt>.
</p>
</li>

<li>
<p>
When the deleter type is a function pointer then it is unsafe to construct
a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
This case is easy to check for with a <tt>static_assert</tt> assuring that the
deleter is not a pointer type in those constructors which do not accept deleters.
</p>

<blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A);  // error, no function given to delete the pointer!
</pre></blockquote>

</li>

</ul>

<p><i>[
Kona (2007): We don't like the solution given to the first bullet in
light of concepts. The second bullet solves the problem of supporting
fancy pointers for one library component only. The full LWG needs to
decide whether to solve the problem of supporting fancy pointers
piecemeal, or whether a paper addressing the whole library is needed. We
think that the third bullet is correct.
]</i></p>


<p><i>[
Post Kona: Howard adds example user code related to the first bullet:
]</i></p>


<blockquote>
<pre>void legacy_code(void*, std::size_t);

void foo(std::size_t N)
{
    std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
    legacy_code(ptr.get(), N);
}   // unique_ptr used for exception safety purposes
</pre>
</blockquote>

<p>
I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
to disable with concepts.  The only part of <tt>unique_ptr&lt;void&gt;</tt> we
want to disable (with concepts or by other means) are the two member functions:
</p>

<blockquote><pre>T&amp; operator*() const;
T* operator-&gt;() const;
</pre></blockquote>



<p><b>Proposed resolution:</b></p>

<p><i>[
I am grateful for the generous aid of Peter Dimov and Ion Gazta�aga in helping formulate and review
the proposed resolutions below.
]</i></p>


<ul>
<li>

<p>
Change 20.9.9.2 [unique.ptr.single]:
</p>

<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
   ...
   <del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
   ...
};
</pre></blockquote>

<p>
Change 20.9.9.2.4 [unique.ptr.single.observers]:
</p>

<blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
</pre></blockquote>

</li>

<li>
<p>
Change 20.9.9.2 [unique.ptr.single]:
</p>

<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
public:
  <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
   ...
   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
   ...
   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
   ...
   <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
   <del>T*</del> <ins>pointer</ins> get() const;
   ...
   <del>T*</del> <ins>pointer</ins> release();
   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
};
</pre></blockquote>

<p>
<ins>
-3- If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt>
exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to
<tt>remove_reference&lt;D&gt;::type::pointer</tt>.  Otherwise
<tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to <tt>T*</tt>.
The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be <tt>CopyConstructible</tt>
and <tt>CopyAssignable</tt>.
</ins>
</p>

<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]:
</p>

<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
...
unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
...
unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
...
unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp; d); 
unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
...
unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d); 
unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp;&amp; d);
...
</pre></blockquote>

<p>
-23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
<del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
<ins>pointer</ins>.
</p>

<p>
-25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
the construction, modulo any required offset adjustments resulting from
the cast from <del><tt>U*</tt></del>
<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> to <del><tt>T*</tt></del>
<ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
internally stored deleter which was constructed from
<tt>u.get_deleter()</tt>.
</p>

<p>
Change 20.9.9.2.3 [unique.ptr.single.asgn]:
</p>

<blockquote>
<p>
-8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
<tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
</p>
</blockquote>

<p>
Change 20.9.9.2.4 [unique.ptr.single.observers]:
</p>

<blockquote>
<pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
...
<pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
</blockquote>

<p>
Change 20.9.9.2.5 [unique.ptr.single.modifiers]:
</p>

<blockquote>
<pre><del>T*</del> <ins>pointer</ins> release();</pre>
...
<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
</blockquote>

<p>
Change 20.9.9.3 [unique.ptr.runtime]:
</p>

<blockquote><pre>template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
public:
  <ins>typedef <i>implementation</i> pointer;</ins>
   ...
   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
   ...
   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
   ...
   <del>T*</del> <ins>pointer</ins> get() const;
   ...
   <del>T*</del> <ins>pointer</ins> release();
   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
};
</pre></blockquote>

<p>
Change 20.9.9.3.1 [unique.ptr.runtime.ctor]:
</p>

<blockquote>
<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
</pre>

<p>
These constructors behave the same as in the primary template except
that they do not accept pointer types which are convertible to
<del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
implementation technique is to create private templated overloads of
these members. <i>-- end note</i>]
</p>
</blockquote>

<p>
Change 20.9.9.3.3 [unique.ptr.runtime.modifiers]:
</p>

<blockquote>
<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
</pre>

<p>
-1- <i>Requires:</i> Does not accept pointer types which are convertible
to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
required). [<i>Note:</i> One implementation technique is to create a private
templated overload. <i>-- end note</i>]
</p>
</blockquote>

</li>

<li>

<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]:
</p>

<blockquote>
<pre>unique_ptr();</pre>
<blockquote>
<p>
<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
reference type <ins>or pointer type (diagnostic required)</ins>.
</p>
</blockquote>
<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
<blockquote>
<p>
<i>Requires:</i>  The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
required)</ins>.
</p>
</blockquote>
</blockquote>

</li>

</ul>






<hr>
<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
<p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
</p>


<p><b>Proposed resolution:</b></p>

<p>
Change 20.9.10.2 [util.smartptr.shared] as follows:
</p>

<blockquote>
<pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
<ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
...
template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
<ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
</blockquote>

<p>
Change 20.9.10.2.1 [util.smartptr.shared.const] as follows:
</p>

<blockquote>
<pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
</blockquote>

<p>
Add to 20.9.10.2.1 [util.smartptr.shared.const]:
</p>

<blockquote>
<pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
<blockquote>

<p><ins>
<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
          not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
          otherwise.
</ins></p>

<p><ins>
<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
</ins></p>
</blockquote>

</blockquote>

<p>
Change 20.9.10.2.3 [util.smartptr.shared.assign] as follows:
</p>

<blockquote>
<pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
</blockquote>

<p>
Add to 20.9.10.2.3 [util.smartptr.shared.assign]:
</p>

<blockquote>
<pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>

<blockquote>
<p><ins>
-4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
</ins></p>
<p><ins>
-5- <i>Returns:</i> <tt>*this</tt>.
</ins></p>
</blockquote>

</blockquote>



<p><i>[
Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>) to deal with the question of
whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
]</i></p>





<hr>
<h3><a name="675"></a>675. Move assignment of containers</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
(just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
the wrong semantics under move assignment when the source is not truly an rvalue, but a
moved-from lvalue (destructors could run late).
</p>

<blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
<tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
...
v1 = v2;               // #1
v1 = std::move(v2);    // #2
</pre></blockquote>

<p>
Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
It doesn't mean not caring what happens to the target (<tt>v1</tt>).  In the above example
both assignments should have the same effect on <tt>v1</tt>.  Any non-shared <tt>ostream</tt>'s
<tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
copy assignment or move assignment.
</p>

<p>
This implies that the semantics of move assignment of a generic container should be
<tt>clear, swap</tt> instead of just swap.  An alternative which could achieve the same
effect would be to move assign each element.  In either case, the complexity of move
assignment needs to be relaxed to <tt>O(v1.size())</tt>.
</p>

<p>
The performance hit of this change is not nearly as drastic as it sounds. 
In practice, the target of a move assignment has always just been move constructed
or move assigned <i>from</i>.  Therefore under <tt>clear, swap</tt> semantics (in
this common use case) we are still achieving O(1) complexity.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change 23.2 [container.requirements]:
</p>

<blockquote>
<table border="1">
<caption>Table 89: Container requirements</caption>
<tbody><tr>
<th>expression</th><th>return type</th><th>operational semantics</th>
<th>assertion/note pre/post-condition</th><th>complexity</th>
</tr>
<tr>
<td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
<td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
<td><tt>a</tt> shall be equal to the 
value that <tt>rv</tt> had 
before this construction
</td>
<td><del>(Note C)</del> <ins>linear</ins></td>
</tr>
</tbody></table>

<p>
Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
<tt>lexicographical_compare()</tt> are defined in clause 25. Those
entries marked "(Note A)" should have constant complexity. Those entries
marked "(Note B)" have constant complexity unless
<tt>allocator_propagate_never&lt;X::allocator_type&gt;::value</tt> is
<tt>true</tt>, in which case they have linear complexity.
<del>Those entries
marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
rv.get_allocator()</tt> or if either
<tt>allocator_propagate_on_move_assignment&lt;X::allocator_type&gt;::value</tt>
is <tt>true</tt> or
<tt>allocator_propagate_on_copy_assignment&lt;X::allocator_type&gt;::value</tt>
is <tt>true</tt> and linear complexity otherwise.</del>
</p>
</blockquote>



<p><i>[
post Bellevue Howard adds:
]</i></p>


<blockquote>
<p>
This issue was voted to WP in Bellevue, but accidently got stepped on by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
the wording right.  The intent of this issue and N2525 are not in conflict.
</p>
</blockquote>

<p><i>[
post Sophia Antipolis Howard updated proposed wording:
]</i></p>





<hr>
<h3><a name="676"></a>676. Moving the unordered containers</h3>
<p><b>Section:</b> 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
resolution below adds move-support consistent with
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
and the current working draft.
</p>

<p>
The current proposed resolution simply lists the requirements for each function.
These might better be hoisted into the requirements table for unordered associative containers.
Futhermore a mild reorganization of the container requirements could well be in order.
This defect report is purposefully ignoring these larger issues and just focusing
on getting the unordered containers "moved".
</p>

<p><i>[
2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
]</i></p>


<p><i>[
2009-10-17 Removed rvalue-swaps from wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Review. Alisdair will review proposed wording.
</blockquote>

<p><i>[
2009-10-29 Daniel updates wording.
]</i></p>


<p><i>[
2010-01-26 Alisdair updates wording.
]</i></p>


<p><i>[
2010-02-10 Howard updates wording to reference the unordered container
requirements table (modified by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>) as much as possible.
]</i></p>


<p><i>[
Voted to WP in Bellevue.
]</i></p>


<p><i>[
post Bellevue, Pete notes:
]</i></p>


<blockquote>
<p>
Please remind people who are reviewing issues to check that the text
modifications match the current draft. Issue 676, for example, adds two
overloads for unordered_map::insert taking a hint. One takes a
const_iterator and returns a const_iterator, and the other takes an
iterator and returns an iterator. This was correct at the time the issue
was written, but was changed in Toronto so there is only one hint
overload, taking a const_iterator and returning an iterator.
</p>
<p>
This issue is not ready. In addition to the relatively minor signature
problem I mentioned earlier, it puts requirements in the wrong places.
Instead of duplicating requirements throughout the template
specifications, it should put them in the front matter that talks about
requirements for unordered containers in general. This presentation
problem is editorial, but I'm not willing to do the extensive rewrite
that it requires. Please put it back into Open status.
</p>
</blockquote>

<p><i>[
2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-02-24 Pete moved to Open:
]</i></p>


<blockquote>
The descriptions of the semantics of the added <tt>insert</tt> functions belong
in the requirements table. That's where the rest of the <tt>insert</tt>
functions are.
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Move issue 676 to Ready for Pittsburgh. Nico to send Howard an issue for
the broader problem.
</blockquote>



<p><b>Rationale:</b></p>
<p><i>[
San Francisco:
]</i></p>


<blockquote>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
</blockquote>

<p><i>[
Rationale is obsolete.
]</i></p>





<p><b>Proposed resolution:</b></p>

<p><b><tt>unordered_map</tt></b></p>

<p>
Change 23.7.1 [unord.map]:
</p>

<blockquote><pre>class unordered_map
{
    ...
    unordered_map(const unordered_map&amp;);
    <ins>unordered_map(unordered_map&amp;&amp;);</ins>
    unordered_map(const Allocator&amp;);
    unordered_map(const unordered_map&amp;, const Allocator&amp;);
    unordered_map(unordered_map&amp;&amp;, const Allocator&amp;);
    ...
    unordered_map&amp; operator=(const unordered_map&amp;);
    <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
    ...
    // modifiers
    ...
    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
    <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
    iterator       insert(const_iterator hint, const value_type&amp; obj);
    <ins>template &lt;class P&gt; iterator       insert(const_iterator hint, P&amp;&amp; obj);</ins>
    ...
    mapped_type&amp; operator[](const key_type&amp; k);
    <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
    ...
};

</pre></blockquote>

<p>
Add to 23.7.1.2 [unord.map.elem]:
</p>

<blockquote>

<pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>

<blockquote>
<p>...</p>
<p><ins>
<i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
</ins></p>

<p><ins>
<i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
</ins></p>

</blockquote>

<pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>

<blockquote>
<p><ins>
<i>Requires:</i> <tt>key_type</tt> shall be <tt>MoveConstructible</tt> and
<tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
</ins></p>

<p><ins>
<i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
element whose key is equivalent to <tt>k</tt> , inserts the value
<tt>value_type(std::move(k), mapped_type())</tt>.
</ins></p>

<p><ins>
<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
(unique) element whose key is equivalent to <tt>k</tt>.
</ins></p>

<p><ins>
<i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
</ins></p>

</blockquote>

</blockquote>

<p>
Add new section [unord.map.modifiers]:
</p>

<blockquote>
<pre><ins>template &lt;class P&gt;
  pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
</pre>

<blockquote>

<p><ins>
<i>Requires:</i> <tt>value_type</tt> is constructible from
<tt>std::forward&lt;P&gt;(x)</tt>.
</ins></p>

<p><ins>
<i>Effects:</i>  Inserts <tt>x</tt> converted to <tt>value_type</tt> if and only
if there is no element in the container with key equivalent to the key of
<tt>value_type(x)</tt>.
</ins></p>

<p><ins>
<i>Returns:</i> The <tt>bool</tt> component of the returned
<tt>pair</tt> indicates whether the insertion takes place, and the iterator
component points to the element with key equivalent to the key of
<tt>value_type(x)</tt>.
</ins></p>

<p><ins>
<i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
</ins></p>

<p><ins>
<i>Remarks:</i> <tt>P</tt> shall be implicitly convertible to
<tt>value_type</tt>, else this signature shall not participate in overload
resolution.
</ins></p>

</blockquote>


<pre><ins>template &lt;class P&gt;
  iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
</pre>

<blockquote>

<p><ins>
<i>Requires:</i> <tt>value_type</tt> is constructible from
<tt>std::forward&lt;P&gt;(x)</tt>.
</ins></p>

<p><ins>
<i>Effects:</i>  Inserts <tt>x</tt> converted to <tt>value_type</tt> if and only
if there is no element in the container with key equivalent to the key of
<tt>value_type(x)</tt>.  The iterator <tt>hint</tt> is a hint pointing to where
the search should start. Implementations are permitted to ignore the hint.
</ins></p>

<p><ins>
<i>Returns:</i> An iterator pointing to the element with key equivalent to the
key of <tt>value_type(x)</tt>.
</ins></p>

<p><ins>
<i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
</ins></p>

<p><ins>
<i>Remarks:</i> <tt>P</tt> shall be implicitly convertible to
<tt>value_type</tt>, else this signature shall not participate in overload
resolution.
</ins></p>

</blockquote>

</blockquote>

<p><b><tt>unordered_multimap</tt></b></p>

<p>
Change 23.7.2 [unord.multimap]:
</p>

<blockquote><pre>class unordered_multimap
{
    ...
    unordered_multimap(const unordered_multimap&amp;);
    <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
    unordered_multimap(const Allocator&amp;);
    unordered_multimap(const unordered_multimap&amp;, const Allocator&amp;);
    unordered_multimap(unordered_multimap&amp;&amp;, const Allocator&amp;);
    ...
    unordered_multimap&amp; operator=(const unordered_multimap&amp;);
    <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
    ...
    // modifiers
    ...
    iterator insert(const value_type&amp; obj); 
    <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
    iterator       insert(const_iterator hint, const value_type&amp; obj);
    <ins>template &lt;class P&gt; iterator       insert(const_iterator hint, P&amp;&amp; obj);</ins>
    ...
};

</pre></blockquote>

<p>
Add new section [unord.multimap.modifiers]:
</p>

<blockquote>
<pre><ins>template &lt;class P&gt;
  iterator insert(P&amp;&amp; x);</ins>
</pre>

<blockquote>

<p><ins>
<i>Requires:</i> <tt>value_type</tt> is constructible from
<tt>std::forward&lt;P&gt;(x)</tt>.
</ins></p>

<p><ins>
<i>Effects:</i>  Inserts <tt>x</tt> converted to <tt>value_type</tt>.
</ins></p>

<p><ins>
<i>Returns:</i> An iterator pointing to the element with key equivalent to the
key of <tt>value_type(x)</tt>.
</ins></p>

<p><ins>
<i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
</ins></p>

<p><ins>
<i>Remarks:</i> <tt>P</tt> shall be implicitly convertible to
<tt>value_type</tt>, else this signature shall not participate in overload
resolution.
</ins></p>

</blockquote>

<pre><ins>template &lt;class P&gt;
  iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
</pre>

<blockquote>

<p><ins>
<i>Requires:</i> <tt>value_type</tt> is constructible from
<tt>std::forward&lt;P&gt;(x)</tt>.
</ins></p>

<p><ins>
<i>Effects:</i>  Inserts <tt>x</tt> converted to <tt>value_type</tt> if and only
if there is no element in the container with key equivalent to the key of
<tt>value_type(x)</tt>.  The iterator <tt>hint</tt> is a hint pointing to where
the search should start. Implementations are permitted to ignore the hint.
</ins></p>

<p><ins>
<i>Returns:</i> An iterator pointing to the element with key equivalent to the
key of <tt>value_type(x)</tt>.
</ins></p>

<p><ins>
<i>Complexity:</i> Average case <tt>O(1)</tt>, worst case <tt>O(size())</tt>.
</ins></p>

<p><ins>
<i>Remarks:</i> <tt>P</tt> shall be implicitly convertible to
<tt>value_type</tt>, else this signature shall not participate in overload
resolution.
</ins></p>

</blockquote>

</blockquote>

<p><b><tt>unordered_set</tt></b></p>

<p>
Change 23.7.3 [unord.set]:
</p>

<blockquote><pre>class unordered_set
{
    ...
    unordered_set(const unordered_set&amp;);
    <ins>unordered_set(unordered_set&amp;&amp;);</ins>
    unordered_set(const Allocator&amp;);
    unordered_set(const unordered_set&amp;, const Allocator&amp;);
    unordered_set(unordered_set&amp;&amp;, const Allocator&amp;);
    ...
    unordered_set&amp; operator=(const unordered_set&amp;);
    <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
    ...
    // modifiers 
    ...
    <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj); 
    <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
    iterator       insert(const_iterator hint, const value_type&amp; obj);
    <ins>iterator       insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
    ...
};
</pre></blockquote>

<p><b><tt>unordered_multiset</tt></b></p>

<p>
Change 23.7.4 [unord.multiset]:
</p>

<blockquote><pre>class unordered_multiset
{
    ...
    unordered_multiset(const unordered_multiset&amp;);
    <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
    unordered_multiset(const Allocator&amp;);
    unordered_multiset(const unordered_multiset&amp;, const Allocator&amp;);
    unordered_multiset(unordered_multiset&amp;&amp;, const Allocator&amp;);
    ...
    unordered_multiset&amp; operator=(const unordered_multiset&amp;);
    <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
    ...
    // modifiers
    ...
    iterator insert(const value_type&amp; obj); 
    <ins>iterator insert(value_type&amp;&amp; obj);</ins>
    iterator       insert(const_iterator hint, const value_type&amp; obj);
    <ins>iterator       insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
    ...
};

</pre></blockquote>






<hr>
<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
engines which ideally would yield "distant" states when given "close"
seeds.  The algorithm for <tt>seed_seq::randomize</tt> given in the current
Working Draft for C++,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
(2007-05-08), has 3 weaknesses
</p>

<ol>
<li>
<p> Collisions in state.  Because of the way the state is initialized,
    seeds of different lengths may result in the same state.  The
    current version of seed_seq has the following properties:</p>
<ul>
<li>  For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
      distinct state.</li>
</ul>
<p>
    The proposed algorithm (below) has the considerably stronger
    properties:</p>
<ul>
<li>   All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
      result in distinct states.
</li>
<li>  All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
      distinct states.
</li>
</ul>
</li>
<li>
<p> Poor mixing of <tt>v'</tt>s entropy into the state.  Consider <tt>v.size() == n</tt>
    and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
    a total of <tt>2^(16n)</tt> possibilities.  Because of the simple recursion
    used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
    possible states.</p>

<p> The proposed algorithm uses a more complex recursion which results
    in much better mixing.</p>
</li>
<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>.  The proposed
    algorithm remedies this.
</li>
</ol>
<p>
The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
initialization procedure for the Mersenne Twister by Makoto Matsumoto
and Takuji Nishimura.  The weakness (2) given above was communicated to
me by Matsumoto last year.
</p>
<p>
The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
a student of Matsumoto, and is given in the implementation of the
SIMD-oriented Fast Mersenne Twister random number generator SFMT.
<a href="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
<a href="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
</p>
<p>
See
Mutsuo Saito,
An Application of Finite Field: Design and Implementation of 128-bit
Instruction-Based Fast Pseudorandom Number Generator,
Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
<a href="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
</p>
<p>
One change has been made here, namely to treat the case of small <tt>n</tt>
(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
</p>
<p>
Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
in making this incompatible improvement to it.
</p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
<p><b>Section:</b> 26.5.1.4 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Section 26.5.1.4 [rand.req.eng] Random number engine requirements:
</p>

<p>
This change follows naturally from the proposed change to
<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
</p>

<p>
In table 104 the description of <tt>X(q)</tt> contains a special treatment of
the case <tt>q.size() == 0</tt>.  This is undesirable for 4 reasons:
</p>

<ol>
<li>It replicates the functionality provided by <tt>X()</tt>.</li>
<li>It leads to the possibility of a collision in the state provided
    by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
<li>It is inconsistent with the description of the <tt>X(q)</tt> in
paragraphs 26.5.3.1 [rand.eng.lcong] p5, 26.5.3.2 [rand.eng.mers] p8, and 26.5.3.3 [rand.eng.sub] p10 where
there is no special treatment of <tt>q.size() == 0</tt>.</li>
<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
    allows for the case <tt>q.size() == 0</tt>.</li>
</ol>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="679"></a>679. resize parameter by value</h3>
<p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The C++98 standard specifies that one member function alone of the containers
passes its parameter (<tt>T</tt>) by value instead of by const reference:
</p>

<blockquote><pre>void resize(size_type sz, T c = T());
</pre></blockquote>

<p>
This fact has been discussed / debated repeatedly over the years, the first time
being even before C++98 was ratified.  The rationale for passing this parameter by
value has been:
</p>

<blockquote>
<p>
So that self referencing statements are guaranteed to work, for example:
</p>
<blockquote><pre>v.resize(v.size() + 1, v[0]);
</pre></blockquote>
</blockquote>

<p>
However this rationale is not convincing as the signature for <tt>push_back</tt> is:
</p>

<blockquote><pre>void push_back(const T&amp; x);
</pre></blockquote>

<p>
And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
And <tt>push_back</tt> must also work in the self referencing case:
</p>

<blockquote><pre>v.push_back(v[0]);  // must work
</pre></blockquote>

<p>
The problem with passing <tt>T</tt> by value is that it can be significantly more
expensive than passing by reference.  The converse is also true, however when it is
true it is usually far less dramatic (e.g. for scalar types).
</p>

<p>
Even with move semantics available, passing this parameter by value can be expensive.
Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
</p>

<blockquote><pre>std::vector&lt;int&gt; x(1000);
std::vector&lt;std::vector&lt;int&gt;&gt; v;
...
v.resize(v.size()+1, x);
</pre></blockquote>

<p>
In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
<tt>resize</tt>.  And then internally, since the code can not know at compile
time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
within the <tt>vector</tt>.
</p>

<p>
With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
only once.  In this case, <tt>x</tt> has an expensive copy constructor and so any
copies that can be saved represents a significant savings.
</p>

<p>
If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
as well.  The resize taking a reference parameter has been coded and shipped in the
CodeWarrior library with no reports of problems which I am aware of.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change 23.3.2 [deque], p2:
</p>

<blockquote><pre>class deque {
   ...
   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
</pre></blockquote>

<p>
Change 23.3.2.2 [deque.capacity], p3:
</p>

<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
</pre></blockquote>

<p>
Change 23.3.4 [list], p2:
</p>

<blockquote><pre>class list {
   ...
   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
</pre></blockquote>

<p>
Change 23.3.4.2 [list.capacity], p3:
</p>

<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
</pre></blockquote>

<p>
Change 23.4.1 [vector], p2:
</p>

<blockquote><pre>class vector {
   ...
   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
</pre></blockquote>

<p>
Change 23.4.1.2 [vector.capacity], p11:
</p>

<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
</pre></blockquote>






<hr>
<h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
<p><b>Section:</b> 24.5.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#move.iterator">issues</a> in [move.iterator].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
does not consistently match the type which is returned in the description
in 24.5.3.3.5 [move.iter.op.ref].
</p>

<blockquote><pre>template &lt;class Iterator&gt;
class move_iterator {
public:
    ...
    typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
    ...
    pointer operator-&gt;() const {return current;}
    ...
private: 
    Iterator current; // exposition only
};
</pre></blockquote>


<p>
There are two possible fixes.
</p>

<ol>
<li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
<li><tt>typedef Iterator pointer;</tt></li>
</ol>

<p>
The first solution is the one chosen by <tt>reverse_iterator</tt>.  A potential
disadvantage of this is it may not work well with iterators which return a
proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>.  Proxy
references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
pointer.  That proxy pointer may or may not be the same type as the iterator's
<tt>pointer</tt> type.
</p>

<p>
By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
the language forwards calls to <tt>operator-&gt;</tt> automatically until it
finds a non-class type, the second solution avoids the issue of an overloaded
<tt>operator&amp;()</tt> entirely.
</p>

<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis in 24.5.3.1 [move.iterator]:
</p>

<blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
</pre></blockquote>






<hr>
<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Nozomu Katoo <b>Opened:</b> 2007-05-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 28.9.2 [re.submatch.op] of N2284, 
operator functions numbered 31-42 seem impossible to compare. E.g.: 
</p>

<blockquote>
<pre>template &lt;class BiIter&gt;
   bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
                    const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
<blockquote>
<p>
-31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
</p>
</blockquote>
</blockquote>

<p>
When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be 
<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object 
of <tt>std::basic_string&lt;char&gt;</tt>.  However, the behaviour of comparison between 
these two types is not defined in 21.4.8 [string.nonmembers] of N2284.
 This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. 
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2007-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this 
constructor: 
</p>
<blockquote><pre>template &lt;class InputIterator&gt;
     basic_regex(InputIterator first, InputIterator last, 
                 flag_type f = regex_constants::ECMAScript);
</pre></blockquote>

<p>
In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
</p>

<blockquote><pre>template &lt;class ForwardIterator&gt;
     basic_regex(ForwardIterator first, ForwardIterator last, 
                 flag_type f = regex_constants::ECMAScript);
</pre></blockquote>

<p>
<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
</p>

<p><i>[
John adds:
]</i></p>


<blockquote>
<p>
I think either could be implemented?  Although an input iterator would 
probably require an internal copy of the string being made.
</p>
<p>
I have no strong feelings either way, although I think my original intent 
was <tt>InputIterator</tt>. 
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
<p><b>Section:</b> 24.5.1.3.19 [reverse.iter.opdiff], 24.5.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-06-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In C++03 the difference between two <tt>reverse_iterators</tt>
</p>
<blockquote><pre>ri1 - ri2
</pre></blockquote>
<p>
is possible to compute only if both iterators have the same base 
iterator. The result type is the <tt>difference_type</tt> of the base iterator. 
</p>
<p>
In the current draft, the operator is defined as 24.5.1.3.19 [reverse.iter.opdiff] 
</p>
<blockquote><pre>template&lt;class Iterator1, class Iterator2&gt; 
typename reverse_iterator&lt;Iterator&gt;::difference_type 
   operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x, 
                    const reverse_iterator&lt;Iterator2&gt;&amp; y);
</pre></blockquote>
<p>
The return type is the same as the C++03 one, based on the no longer 
present <tt>Iterator</tt> template parameter. 
</p>
<p>
Besides being slightly invalid, should this operator work only when 
<tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the 
implementation choose one of them? Which one? 
</p>
<p>
The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
24.5.3.3.14 [move.iter.nonmember]. 
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis in 24.5.1.1 [reverse.iterator]:
</p>

<blockquote>
<pre>template &lt;class Iterator1, class Iterator2&gt; 
  <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
    const reverse_iterator&lt;Iterator1&gt;&amp; x, 
    const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
</pre>
</blockquote>

<p>
Change 24.5.1.3.19 [reverse.iter.opdiff]:
</p>

<blockquote>
<pre>template &lt;class Iterator1, class Iterator2&gt; 
  <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
    const reverse_iterator&lt;Iterator1&gt;&amp; x, 
    const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>y.current - x.current</tt>.
</p>
</blockquote>
</blockquote>


<p>
Change the synopsis in 24.5.3.1 [move.iterator]:
</p>

<blockquote>
<pre>template &lt;class Iterator1, class Iterator2&gt; 
  <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
    const move_iterator&lt;Iterator1&gt;&amp; x, 
    const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
</pre>
</blockquote>

<p>
Change 24.5.3.3.14 [move.iter.nonmember]:
</p>

<blockquote>
<pre>template &lt;class Iterator1, class Iterator2&gt; 
  <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
    const move_iterator&lt;Iterator1&gt;&amp; x, 
    const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>x.base() - y.base()</tt>.
</p>
</blockquote>
</blockquote>

<p><i>[
Pre Bellevue:  This issue needs to wait until the <tt>auto -&gt; return</tt> language feature
goes in.
]</i></p>







<hr>
<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
<p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const], 20.9.10.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
code that works with raw pointers fails with <tt>shared_ptr</tt>:
</p>

<blockquote><pre>void f( shared_ptr&lt;void&gt; );
void f( shared_ptr&lt;int&gt; );

int main()
{
  f( shared_ptr&lt;double&gt;() ); // ambiguous
}
</pre></blockquote>

<p>
Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
and the corresponding assignment operator to only participate in the
overload resolution when the pointer types are compatible.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 20.9.10.2.1 [util.smartptr.shared.const], change:
</p>

<blockquote><p>
-14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
second constructor shall not participate in the overload resolution
unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
to <tt>T*</tt>.
</p></blockquote>

<p>
In 20.9.10.3.1 [util.smartptr.weak.const], change:
</p>

<blockquote>
<pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
<del>weak_ptr(weak_ptr const&amp; r);</del>
<del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
<ins>weak_ptr(weak_ptr const&amp; r);</ins>
<ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
<ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
</pre>
<blockquote><p>
-4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
third constructors<del>,</del> <ins>shall not participate in the
overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
<ins>is implicitly</ins> convertible to <tt>T*</tt>.
</p></blockquote>
</blockquote>






<hr>
<h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
<p><b>Section:</b> 20.8.4.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
Now that we have a mechanism to detect an rvalue, we can fix them to
disallow this source of undefined behavior.
</p>

<p>
Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
</p>

<p><i>[
2009-05-09 Alisdair adds:
]</i></p>


<blockquote>
<p>
Now that <tt>ref/cref</tt> are constained that <tt>T</tt> must be an <tt>ObjectType</tt>, I do not
believe there is any risk of binding <tt>ref</tt> to a temporary (which would rely on
deducing <tt>T</tt> to be an rvalue reference type)
</p>
<p>
However, the problem for <tt>cref</tt> remains, so I recommend retaining that deleted
overload.
</p>
</blockquote>

<p><i>[
2009-05-10 Howard adds:
]</i></p>


<blockquote>
<p>
Without:
</p>

<blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
</pre></blockquote>
<p>
I believe this program will compile:
</p>

<blockquote><pre>#include &lt;functional&gt;

struct A {};

const A source() {return A();}

int main()
{
   std::reference_wrapper&lt;const A&gt; r = std::ref(source());
}
</pre></blockquote>
<p>
I.e. in:
</p>
<blockquote><pre>template &lt;ObjectType T&gt; reference_wrapper&lt;T&gt; ref(T&amp; t);
</pre></blockquote>

<p>
this:
</p>

<blockquote><pre>ref(source())
</pre></blockquote>
<p>
deduces <tt>T</tt> as <tt>const A</tt>, and so:
</p>

<blockquote><pre>ref(const A&amp; t)
</pre></blockquote>

<p>
will bind to a temporary (tested with a pre-concepts rvalue-ref enabled compiler).
</p>
<p>
Therefore I think we still need the ref-protection.  I respectfully disagree with Alisdair's
comment and am in favor of the proposed wording as it stands.  Also, CWG 606
(noted below) has now been "favorably" resolved.
</p>

</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 20.8 [function.objects], add the following two signatures to the synopsis:
</p>

<blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
template &lt;class T&gt; void cref(const T&amp;&amp; t) = delete;
</pre></blockquote>



<p><i>[
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
addresses the first part of the resolution but not the second.
]</i></p>


<p><i>[
Bellevue:  Doug noticed problems with the current wording.
]</i></p>


<p><i>[
post Bellevue:  Howard and Peter provided revised wording.
]</i></p>


<p><i>[
This resolution depends on a "favorable" resolution of CWG 606:  that is,
the "special deduction rule" is disabled with the const T&amp;&amp; pattern.
]</i></p>





<hr>
<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
<p><b>Section:</b> 20.8.4.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
motivation behind this is the safety problem with respect to rvalues,
which is addressed by the proposed resolution of the previous issue.
Therefore we should consider relaxing the requirements on the
constructor since requests for the implicit conversion keep resurfacing.
</p>
<p>
Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
proposed resolution of the previous issue is accepted, remove the
<tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
</p>





<hr>
<h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
<p><b>Section:</b> 23.7 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Joaqu�n M L�pez Mu�oz <b>Opened:</b> 2007-06-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The last version of TR1 does not include the following member
functions
for unordered containers:
</p>

<blockquote><pre>const_local_iterator cbegin(size_type n) const;
const_local_iterator cend(size_type n) const;
</pre></blockquote>

<p>
which looks like an oversight to me. I've checked th TR1 issues lists
and the latest working draft of the C++0x std (N2284) and haven't
found any mention to these menfuns or to their absence.
</p>
<p>
Is this really an oversight, or am I missing something?
</p>



<p><b>Proposed resolution:</b></p>
<p>
Add the following two rows to table 93 (unordered associative container
requirements) in section 23.2.5 [unord.req]:
</p>

<blockquote>
<table border="1">
<caption>Unordered associative container requirements (in addition to container)</caption>
<tbody><tr>
<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
</tr>
<tr>
<td><ins><tt>b.cbegin(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>. Note: <tt>[b.cbegin(n), b.cend(n))</tt> is a valid range containing all of the elements in the <tt>n</tt><sup><i>th</i></sup> bucket.</ins></td> <td><ins>Constant</ins></td> 
</tr>
<tr>
<td><ins><tt>b.cend(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>.</ins></td> <td><ins>Constant</ins></td> 
</tr>
</tbody></table>
</blockquote>

<p>
Add to the synopsis in 23.7.1 [unord.map]:
</p>

<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
const_local_iterator cend(size_type n) const;</ins>
</pre></blockquote>

<p>
Add to the synopsis in 23.7.2 [unord.multimap]:
</p>

<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
const_local_iterator cend(size_type n) const;</ins>
</pre></blockquote>

<p>
Add to the synopsis in 23.7.3 [unord.set]:
</p>

<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
const_local_iterator cend(size_type n) const;</ins>
</pre></blockquote>

<p>
Add to the synopsis in 23.7.4 [unord.multiset]:
</p>

<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
const_local_iterator cend(size_type n) const;</ins>
</pre></blockquote>






<hr>
<h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
<p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In a private email Bill Plauger notes:
</p>
<blockquote><p>
I  believe that  the function  that  implements <code>get_money</code>
[from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
should behave  as a  formatted input function,  and the  function that
implements <code>put_money</code> should  behave as a formatted output
function. This  has implications regarding the  skipping of whitespace
and the handling of errors, among other things.
</p>
<p>
The words  don't say that  right now and  I'm far from  convinced that
such a change is editorial.
</p></blockquote>
<p>
Martin's response:
</p>
<blockquote><p>
I agree that the manipulators should handle exceptions the same way as
formatted I/O functions do. The text in N2072 assumes so but the
<i>Returns</i> clause explicitly omits exception handling for the sake
of brevity. The spec should be clarified to that effect.
</p>
<p>
As for dealing  with whitespace, I also agree it  would make sense for
the extractors  and inserters involving the new  manipulators to treat
it the same way as formatted I/O.
</p></blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Add  a new  paragraph immediately  above  p4 of 27.7.4 [ext.manip] with  the
following text:
</p>
<blockquote><p>
<i>Effects</i>:  The   expression  <code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
described below behaves as a formatted input function (as
described in 27.7.1.2.1 [istream.formatted.reqmts]).
</p></blockquote>
<p>
Also change p4 of 27.7.4 [ext.manip] as follows:
</p>
<blockquote><p>
<i>Returns</i>: An object <code>s</code> of unspecified type such that
if <code>in</code> is  an object of type <code>basic_istream&lt;charT,
traits&gt;</code>    then    the    expression   <code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
that    calls    </ins><code>f(in, mon, intl)</code><del>    were
called</del>. The function <code>f</code> can be defined as...
</p></blockquote>


<p><i>[
post Bellevue:
]</i></p>


<blockquote>
We recommend moving immediately to Review. We've looked at the issue and
have a consensus that the proposed resolution is correct, but want an
iostream expert to sign off. Alisdair has taken the action item to putt
this up on the reflector for possible movement by Howard to Tenatively
Ready.
</blockquote>




<hr>
<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
<p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The  <code>bitset</code> class template  provides the  member function
<code>any()</code> to determine whether an  object of the type has any
bits  set, and  the member  function <code>none()</code>  to determine
whether all of an object's  bits are clear. However, the template does
not   provide  a   corresponding  function   to  discover   whether  a
<code>bitset</code>  object  has  all  its  bits  set.   While  it  is
possible,  even easy,  to  obtain this  information  by comparing  the
result of <code>count()</code>  with the result of <code>size()</code>
for  equality  (i.e.,  via  <code>b.count()  ==  b.size()</code>)  the
operation  is   less  efficient   than  a  member   function  designed
specifically  for that purpose  could be.   (<code>count()</code> must
count  all non-zero bits  in a  <code>bitset</code> a  word at  a time
while <code>all()</code> could stop counting as soon as it encountered
the first word with a zero bit).
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add  a declaration of the new  member function <code>all()</code> to the
defintion of the <code>bitset</code> template in 20.5 [template.bitset], p1,
right above the declaration of <code>any()</code> as shown below:
</p>

<blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
bool test(size_t pos) const;
<ins>bool all() const;</ins>
bool any() const;
bool none() const;
</pre></blockquote>

<p>
Add a description of the new member function to the end of 20.5.2 [bitset.members] with the following text:
</p>
<blockquote><p>
<code>bool all() const;</code>
</p>
<blockquote>
<i>Returns</i>: <code>count() == size()</code>.
</blockquote>
</blockquote>

<p>
In  addition,   change  the  description   of  <code>any()</code>  and
<code>none()</code>   for  consistency   with   <code>all()</code>  as
follows:
</p>
<blockquote><p>
<code>bool any() const;</code>
</p>
<blockquote>
<p>
<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
is one</del><ins><code>count() != 0</code></ins>.
</p>
</blockquote>
<p>
<code>bool none() const;</code>
</p>
<blockquote>
<p>
<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
is one</del><ins><code>count() == 0</code></ins>.
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
<p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Objects of the  <code>bitset</code> class template specializations can
be constructed from  and explicitly converted to values  of the widest
C++ integer  type, <code>unsigned long</code>.   With the introduction
of  <code>long long</code> into  the language  the template  should be
enhanced to make it possible  to interoperate with values of this type
as well, or  perhaps <code>uintmax_t</code>.  See c++std-lib-18274 for
a brief discussion in support of this change.
</p>


<p><b>Proposed resolution:</b></p>
<p>
For simplicity,  instead of  adding overloads for  <code>unsigned long
long</code> and dealing with possible ambiguities in the spec, replace
the <code>bitset</code> ctor  that takes an <code>unsigned long</code>
argument  with  one  taking  <code>unsigned long  long</code>  in  the
definition  of the  template as  shown below.   (The  standard permits
implementations  to add  overloads on  other integer  types  or employ
template tricks to  achieve the same effect provided  they don't cause
ambiguities or changes in behavior.)
</p>
<blockquote>
<pre>// [bitset.cons] constructors:
bitset();
bitset(unsigned <ins>long</ins> long val);
template&lt;class charT, class traits, class Allocator&gt;
explicit bitset(
                const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
                typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
                typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
                    basic_string&lt;charT,traits,Allocator&gt;::npos);
</pre>
</blockquote>
<p>
Make a corresponding change in 20.5.1 [bitset.cons], p2:
</p>
<blockquote>
<p>
<code>bitset(unsigned <ins>long</ins> long val);</code>
</p>
<blockquote>
<i>Effects</i>:  Constructs   an  object  of   class  bitset&lt;N&gt;,
initializing  the  first <code><i>M</i></code>  bit  positions to  the
corresponding      bit     values      in     <code><i>val</i></code>.
<code><i>M</i></code> is the  smaller of <code><i>N</i></code> and the
number of bits in  the value representation (section [basic.types]) of
<code>unsigned  <ins> long</ins> long</code>.   If  <code><i>M</i> &lt;
<i>N</i></code>  <ins>is  <code>true</code></ins>,  the remaining  bit
positions are initialized to zero.
</blockquote>
</blockquote>

<p>
Additionally, introduce a new member function <code>to_ullong()</code>
to make  it possible to  convert <code>bitset</code> to values  of the
new  type. Add  the following  declaration  to the  definition of  the
template, immediate  after the declaration  of <code>to_ulong()</code>
in 20.5 [template.bitset], p1, as shown below:
</p>
<blockquote>
<pre>// element access:
bool operator[](size_t pos) const; // for b[i];
reference operator[](size_t pos); // for b[i];
unsigned long to_ulong() const;
<ins>unsigned long long to_ullong() const;</ins>
template &lt;class charT, class traits, class Allocator&gt;
basic_string&lt;charT, traits, Allocator&gt; to_string() const;
</pre>
</blockquote>
<p>
And add a description of  the new member function to 20.5.2 [bitset.members],
below  the  description of  the  existing <code>to_ulong()</code>  (if
possible), with the following text:
</p>
<blockquote>
<p>
<code>unsigned long long to_ullong() const;</code>
</p>
<blockquote>
<i>Throws</i>:  <code>overflow_error</code>   if  the  integral  value
<code><i>x</i></code> corresponding to  the bits in <code>*this</code>
cannot be represented as type <code>unsigned long long</code>.
</blockquote>
<blockquote>
<i>Returns:</i> <code><i>x</i></code>.
</blockquote>
</blockquote>





<hr>
<h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
<p><b>Section:</b> 22.4.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The   <code>ctype&lt;char&gt;::classic_table()</code>   static  member
function    returns    a    pointer    to   an    array    of    const
<code>ctype_base::mask</code>    objects    (enums)   that    contains
<code>ctype&lt;char&gt;::table_size</code>    elements.    The   table
describes the properties of the character set in the "C" locale (i.e.,
whether a  character at an index  given by its value  is alpha, digit,
punct,   etc.),   and   is    typically   used   to   initialize   the
<code>ctype&lt;char&gt;</code>  facet in the  classic "C"  locale (the
protected      <code>ctype&lt;char&gt;</code>      member     function
<code>table()</code>    then    returns     the    same    value    as
<code>classic_table()</code>).
</p>
<p>
However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
the   table)    is   a   public    static   const   member    of   the
<code>ctype&lt;char&gt;</code>           specialization,           the
<code>classic_table()</code> static member function is protected. That
makes getting at the classic  data less than convenient (i.e., one has
to create  a whole derived class just  to get at the  masks array). It
makes  little sense  to expose  the size  of the  table in  the public
interface while making the table itself protected, especially when the
table is a constant object.
</p>
<p>
The  same argument  can be  made for  the non-static  protected member
function <code>table()</code>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Make     the    <code>ctype&lt;char&gt;::classic_table()</code>    and
<code>ctype&lt;char&gt;::table()</code>  member  functions  public  by
moving their declarations into the public section of the definition of
specialization in 22.4.1.3 [facet.ctype.special] as shown below:
</p>
<blockquote>
<pre>  static locale::id id;
  static const size_t table_size = IMPLEMENTATION_DEFINED;
<del>protected:</del>
  const mask* table() const throw();
  static const mask* classic_table() throw();
<ins>protected:</ins>

~ctype(); // virtual
virtual char do_toupper(char c) const;
</pre>
</blockquote>





<hr>
<h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
<p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
From message c++std-lib-17897:
</p>
<p>
The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if"
implementation of the two arithmetic extractors that don't have a
corresponding <code>num_get</code> interface (i.e., the
<code>short</code> and <code>int</code> overloads) is subtly buggy in
how it deals with <code>EOF</code>, overflow, and other similar
conditions (in addition to containing a few typos).
</p>
<p>
One problem is that if <code>num_get::get()</code> reaches the EOF
after reading in an otherwise valid value that exceeds the limits of
the narrower type (but not <code>LONG_MIN</code> or
<code>LONG_MAX</code>), it will set <code><i>err</i></code> to
<code>eofbit</code>. Because of the if condition testing for
<code>(<i>err</i> == 0)</code>, the extractor won't set
<code>failbit</code> (and presumably, return a bogus value to the
caller).
</p>
<p>
Another problem with the code is that it never actually sets the
argument to the extracted value. It can't happen after the call to
<code>setstate()</code> since the function may throw, so we need to
show when and how it's done (we can't just punt as say: "it happens
afterwards"). However, it turns out that showing how it's done isn't
quite so easy since the argument is normally left unchanged by the
facet on error except when the error is due to a misplaced thousands
separator, which causes <code>failbit</code> to be set but doesn't
prevent the facet from storing the value.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We believe this part of the Standard has been recently adjusted
and that this issue was addressed during that rewrite.
</p>
<p>
Move to NAD.
</p>
</blockquote>

<p><i>[
2009-05-28 Howard adds:
]</i></p>


<blockquote>
<p>
I've moved this issue from Tentatively NAD to Open.
</p>

<p>
The current wording of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that
in parsing arithmetic types, the value is always set, but sometimes in addition
to setting <tt>failbit</tt>.
</p>

<ul>
<li>
If there is a range error, the value is set to min or max, else
</li>
<li>
if there is a conversion error, the value is set to 0, else
</li>
<li>
if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else
</li>
<li>
the value is set to its error-free result.
</li>
</ul>

<p>
However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1.
</p>

<p>
27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals]
(whatever we decide that behavior is) for
<tt>int</tt> and <tt>short</tt>, and currently does not.  I believe that the
correct code fragment should look like:
</p>

<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
iostate err = ios_base::goodbit;
long lval;
use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
if (lval &lt; numeric_limits&lt;int&gt;::min())
{
  err |= ios_base::failbit;
  val = numeric_limits&lt;int&gt;::min();
}
else if (lval &gt; numeric_limits&lt;int&gt;::max())
{
  err |= ios_base::failbit;
  val = numeric_limits&lt;int&gt;::max();
}
else
  val = static_cast&lt;int&gt;(lval);
setstate(err);
</pre></blockquote>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
</p>

<blockquote>
-1- <i>Effects:</i> Reads characters from <tt>in</tt>, interpreting them
according to <tt>str.flags()</tt>, <tt>use_facet&lt;ctype&lt;charT&gt;
&gt;(loc)</tt>, and <tt>use_facet&lt; numpunct&lt;charT&gt;
&gt;(loc)</tt>, where <tt>loc</tt> is <tt>str.getloc()</tt>. <del>If an error
occurs, <tt>val</tt> is unchanged; otherwise it is set to the resulting value.</del>
</blockquote>

<p>
Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
</p>

<blockquote>
<pre>operator&gt;&gt;(short&amp; val);
</pre>
<blockquote>
<p>
-2- The conversion occurs as if performed by the following code fragment (using the same notation as for 
the preceding code fragment):
</p>

<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
long lval;
use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
<del>if (err != 0)
  ;
else if (lval &lt; numeric_limits&lt;short&gt;::min()
  || numeric_limits&lt;short&gt;::max() &lt; lval)
     err = ios_base::failbit;</del>
<ins>if (lval &lt; numeric_limits&lt;short&gt;::min())
{
  err |= ios_base::failbit;
  val = numeric_limits&lt;short&gt;::min();
}
else if (lval &gt; numeric_limits&lt;short&gt;::max())
{
  err |= ios_base::failbit;
  val = numeric_limits&lt;short&gt;::max();
}</ins>
else
  val = static_cast&lt;short&gt;(lval);
setstate(err);
</pre></blockquote>

</blockquote>

<pre>operator&gt;&gt;(int&amp; val);
</pre>
<blockquote>
<p>
-3- The conversion occurs as if performed by the following code fragment (using the same notation as for 
the preceding code fragment):
</p>

<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
long lval;
use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
<del>if (err != 0)
  ;
else if (lval &lt; numeric_limits&lt;int&gt;::min()
  || numeric_limits&lt;int&gt;::max() &lt; lval)
     err = ios_base::failbit;</del>
<ins>if (lval &lt; numeric_limits&lt;int&gt;::min())
{
  err |= ios_base::failbit;
  val = numeric_limits&lt;int&gt;::min();
}
else if (lval &gt; numeric_limits&lt;int&gt;::max())
{
  err |= ios_base::failbit;
  val = numeric_limits&lt;int&gt;::max();
}</ins>
else
  val = static_cast&lt;int&gt;(lval);
setstate(err);
</pre></blockquote>

</blockquote>

</blockquote>





<hr>
<h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</h3>
<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-06-24 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The most recent state of 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
as well as the current draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
(section 19.5 [syserr], p.2) proposes a
new
enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
<tt>std::invalid_argument</tt>. This name clashes with the exception type
<tt>std::invalid_argument</tt>, see 19.2 [std.exceptions]/p.3. This clash makes
e.g. the following snippet invalid:
</p>

<blockquote><pre>#include &lt;system_error&gt;
#include &lt;stdexcept&gt;

void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
</pre></blockquote>

<p>
I propose that this enumeration type (and probably the remaining parts
of
<tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
due
to the great number of members that <tt>std::posix_errno</tt> already contains
(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
been rejected?). A further clash <em>candidate</em> seems to be
<tt>std::protocol_error</tt>
(a reasonable name for an exception related to a std network library,
I guess).
</p>

<p>
Another possible resolution would rely on the proposed strongly typed
enums,
as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
But maybe the forbidden implicit conversion to integral types would
make
these enumerators less attractive in this special case?
</p>


<p><b>Proposed resolution:</b></p>
<p>
Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue7">issue 7 of N2422</a>.
</p>






<hr>
<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
<p><b>Section:</b> 19.5.6.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-06-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 19.5.6.1 [syserr.syserr.overview] we have the class definition of
<tt>std::system_error</tt>. In contrast to all exception classes, which
are constructible with a <tt>what_arg string</tt> (see 19.2 [std.exceptions],
or <tt>ios_base::failure</tt> in 27.5.2.1.1 [ios::failure]), only overloads with with
<tt>const string&amp;</tt> are possible. For consistency with the re-designed
remaining exception classes this class should also provide
c'tors which accept a const <tt>char* what_arg</tt> string.
</p>
<p>
Please note that this proposed addition makes sense even
considering the given implementation hint for <tt>what()</tt>, because
<tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
<tt>runtime_error</tt>, which now has the additional c'tor overload
accepting a <tt>const char*</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a> has been accepted and applied to the working paper.
</p>

<p>
Change 19.5.6.1 [syserr.syserr.overview] Class system_error overview, as indicated:
</p>

<blockquote><pre>public:
  system_error(error_code ec, const string&amp; what_arg);
  <ins>system_error(error_code ec, const char* what_arg);</ins>
  system_error(error_code ec);
  system_error(int ev, const error_category* ecat,
      const string&amp; what_arg);
  <ins>system_error(int ev, const error_category* ecat,
      const char* what_arg);</ins>
  system_error(int ev, const error_category* ecat);
</pre></blockquote>

<p>
To 19.5.6.2 [syserr.syserr.members] Class system_error members add:
</p>

<blockquote>
<pre>system_error(error_code ec, const char* what_arg);
</pre>
<blockquote>
<p>
<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
</p>
</blockquote>

<pre>system_error(int ev, const error_category* ecat, const char* what_arg);
</pre>

<blockquote>
<p>
<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="699"></a>699. N2111 changes min/max</h3>
<p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
changes <tt>min/max</tt> in several places in random from member
functions to static data members. I believe this introduces
a needless backward compatibility problem between C++0X and
TR1. I'd like us to find new names for the static data members,
or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
</p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
(not standard, but a common extension from old STL). Be nice
if we could avoid this name clash for backward compatibility.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.3.3 [forward]:
</p>

<blockquote>
<pre>template &lt;class T&gt; struct identity
{
    typedef T type;
    <ins>const T&amp; operator()(const T&amp; x) const;</ins>
};
</pre>
<blockquote>
<pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
</pre>
<blockquote>
<p>
<ins><i>Returns:</i> <tt>x</tt>.</ins>
</p>
</blockquote>
</blockquote>

</blockquote>






<hr>
<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
<p><b>Section:</b> 23.6.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-07-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>map::at()</tt> need a complexity specification.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the following to the specification of <tt>map::at()</tt>, 23.6.1.2 [map.access]:
</p>
<blockquote>
<p>
<i>Complexity:</i> logarithmic.
</p>
</blockquote>





<hr>
<h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
most of the member functions of node-based containers.  But the move-related changes
unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
require <tt>CopyAssignable</tt>.
</p>

<p>
We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
from some of the sequence requirements.  Additionally the <i>in-place</i> construction
work may further reduce requirements.  For purposes of an easy reference, here are the
minimum sequence requirements as I currently understand them.  Those items in requirements
table in the working draft which do not appear below have been purposefully omitted for
brevity as they do not have any requirements of this nature.  Some items which do not
have any requirements of this nature are included below just to confirm that they were
not omitted by mistake.
</p>

<table border="1">
<caption>Container Requirements</caption>
<tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
<tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>CopyConstructible</tt></td></tr>
<tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
                               Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>CopyAssignable</tt>.
                                Sequences containers with <tt>propagate_on_container_move_assignment == false</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
                                Associative containers with <tt>propagate_on_container_move_assignment == false</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
</tbody></table>

<p>
</p>

<table border="1">
<caption>Sequence Requirements</caption>
<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
<tr><td><tt>X(i, j)</tt></td><td>Sequences require <tt>value_type</tt> to be constructible from <tt>*i</tt>.  Additionally if input_iterators
                                 are used, <tt>vector</tt> and <tt>deque</tt> require <tt>MoveContructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
<tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
                                        The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
<tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
<tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
<tr><td><tt>a.clear()</tt></td><td></td></tr>
<tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
                                        If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
<tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
                                     The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
</tbody></table>

<p>
</p>

<table border="1">
<caption>Optional Sequence Requirements</caption>
<tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
<tr><td><tt>a.back()</tt></td><td></td></tr>
<tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a.pop_front()</tt></td><td></td></tr>
<tr><td><tt>a.pop_back()</tt></td><td></td></tr>
<tr><td><tt>a[n]</tt></td><td></td></tr>
<tr><td><tt>a.at[n]</tt></td><td></td></tr>
</tbody></table>

<p>
</p>

<table border="1">
<caption>Associative Container Requirements</caption>
<tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
</tbody></table>

<p>
</p>

<table border="1">
<caption>Unordered Associative Container Requirements</caption>
<tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
                                 If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
                                        If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
</tbody></table>

<p>
</p>

<table border="1">
<caption>Miscellaneous Requirements</caption>
<tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
<tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
                                         The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
</tbody></table>

<p><i>[
Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
]</i></p>


<p><i>[
Bellevue: This should be handled as part of the concepts work.
]</i></p>


<p><i>[
2009-07-20 Reopened by Howard:
]</i></p>


<blockquote>
<p>
This is one of the issues that was "solved by concepts" and is now no longer solved.
</p>

<p>
In a nutshell, concepts adopted the "minimum requirements" philosophy outlined
in the discussion of this issue, and enforced it.  My strong suggestion is that
we translate the concepts specification into documentation for the containers.
</p>

<p>
What this means for vendors is that they will have to implement container members
being careful to only use those characteristics of a type that the concepts specification
formally allowed.  Note that I <em>am not</em> talking about <tt>enable_if</tt>'ing
everything.  I am simply suggesting that (for example) we tell the vendor he can't call <tt>T's</tt>
copy constructor or move constructor within the <tt>emplace</tt> member function, etc.
</p>

<p>
What this means for customers is that they will be able to use types within C++03
containers which are sometimes not CopyConstructible, and sometimes not even
MoveConstructible, etc.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave open. Howard to provide wording.
</blockquote>

<p><i>[
2010-02-06 Howard provides wording.
]</i></p>


<p><i>[
2010-02-08 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-02-10 Howard opened.  I neglected to reduce the requirements on value_type
for the insert function of the ordered and unordered associative containers when
the argument is an rvalue.  Fixed it.
]</i></p>


<p><i>[
2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-03-08 Nico opens:
]</i></p>


<blockquote>
<p>
I took the task to see whether <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a> is covered by 704
already.
However, by doing that I have the impression that
704 is a big mistake.
</p>

<p>
Take e.g. the second change of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a>:
</p>

<blockquote>
<p>
Change 23.3.2.1 [deque.cons] para 5:
</p>
<blockquote>
<i>Effects:</i> Constructs a <tt>deque</tt> with <tt>n</tt> default constructed
elements.
</blockquote>
<p>
where "default constructed" should be replaced by "value-initialized".
This is the constructor out of a number of elements:
</p>
<blockquote><pre>ContType c(num)
</pre></blockquote>

<p>
704 says:
</p>

<blockquote>
<p>
Remove the entire section 23.3.2.1 [deque.cons].
</p>
<blockquote>
[ This section is already specified by the requirements tables. ]
</blockquote>
</blockquote>

<p>
BUT, there is no requirement table that lists this constructor at all,
which means that we would lose the entire specification of this function
!!!
</p>

<p>
In fact, I found with further investigation, if we follow
704 to remove 23.3.2.1 we
</p>
<ul>
<li>
have no semantics for
  <tt>ContType c(num)</tt>
</li>
<li>
have no complexity and no allocator specification for
  <tt>ContType c(num,val)</tt>
</li>
<li>
have no semantics for
  <tt>ContType c(num,val,alloc)</tt>
</li>
<li>
- have no complexity and no allocator specification for
  <tt>ContType c(beg,end)</tt>
</li>
<li>
- have no semantics for
  <tt>ContType c(beg,end,alloc)</tt>
</li>
<li>
- have different wording (which might or might not give
 the same guarantees) for the <tt>assign</tt> functions
</li>
</ul>

<p>
because all these guarantees are given in the removed
section but nowhere else (as far as I saw).
</p>
<p>
Looks to me that 704 need a significant review before we
take that change, because chances are high that there
are similar flaws in other proposed changes there
(provided I am not missing anything).
</p>
</blockquote>
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
<p>
Removed the parts from the proposed wording that removed existing sections,
and set to Ready for Pittsburgh.
</p>
</blockquote>



<p><b>Rationale:</b></p>
<p><i>[
post San Francisco:
]</i></p>


<blockquote>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
</blockquote>

<p>
This rationale is obsolete. 
</p>



<p><b>Proposed resolution:</b></p>


 
<p>
Change 23.2.1 [container.requirements.general]/4:
</p>

<blockquote>
4 In Tables 91 and 92, <tt>X</tt> denotes a container class containing objects
of type <tt>T</tt>, <tt>a</tt> and <tt>b</tt> denote values of type <tt>X</tt>,
<tt>u</tt> denotes an identifier, <tt>r</tt> denotes <del>an lvalue or a const
rvalue</del> <ins>a non-const value</ins> of type <tt>X</tt>, and <tt>rv</tt>
denotes a non-const rvalue of type <tt>X</tt>.
</blockquote>

<p>
Change the following rows in Table 91 � Container requirements
23.2.1 [container.requirements.general]:
</p>

<blockquote>
<table border="1">
<caption>Table 91 � Container requirements</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td><tt>X::value_type</tt></td>
<td><tt>T</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> is <tt>Destructible</tt>.</ins></td>
<td>compile time</td>
</tr>

</tbody></table>

</blockquote>

<p>
Change 23.2.1 [container.requirements.general]/10:
</p>

<blockquote>
<p>
Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.2.3, and 23.3.6.4) all
container types defined in this Clause meet the following additional
requirements:
</p>

<ul>
<li>
..
</li>

<li>
no <tt>erase()</tt>, <ins><tt>clear()</tt>,</ins> <tt>pop_back()</tt> or
<tt>pop_front()</tt> function throws an exception.
</li>

<li>
...
</li>
</ul>

</blockquote>

<p>
Insert a new paragraph prior to 23.2.1 [container.requirements.general]/14:
</p>

<blockquote>
<p><ins>
The descriptions of the requirements of the type <tt>T</tt> in this section
use the terms <tt>CopyConstructible</tt>, <tt>MoveConstructible</tt>, <i>constructible
from <tt>*i</tt></i>, and <i>constructible from <tt>args</tt></i>.  These terms
are equivalent to the following expression using the appropriate arguments:
</ins></p>

<blockquote><pre><ins>
allocator_traits&lt;allocator_type&gt;::construct(x.get_allocator(), q, args...);
</ins></pre></blockquote>

<p><ins>
where <tt>x</tt> is a non-const lvalue of some container type <tt>X</tt> and
<tt>q</tt> has type <tt>X::value_type*</tt>.
</ins></p>

<p><ins>
[<i>Example:</i> The container is going to move construct a <tt>T</tt>, so will
call:
</ins></p>

<blockquote><pre><ins>
allocator_traits&lt;allocator_type&gt;::construct(get_allocator(), q, std::move(t));
</ins></pre></blockquote>

<p><ins>
The default implementation of construct will call:
</ins></p>

<blockquote><pre><ins>
::new (q) T(std::forward&lt;T&gt;(t)); // where forward is the same as move here, cast to rvalue
</ins></pre></blockquote>

<p><ins>
But the allocator author may override the above definition of <tt>construct</tt>
and do the construction of <tt>T</tt> by some other means. � <i>end
example</i>]
</ins></p>

<p>
14 ...
</p>
</blockquote>

<p>
Add to 23.2.1 [container.requirements.general]/14:
</p>

<blockquote>
14 In Table 93, <tt>X</tt> denotes an allocator-aware container class with a
<tt>value_type</tt> of <tt>T</tt> using allocator of type <tt>A</tt>, <tt>u</tt>
denotes a variable, <ins><tt>a</tt> and <tt>b</tt> denote non-const lvalues of
type <tt>X</tt>,</ins> <tt>t</tt> denotes an lvalue or a const rvalue of type
<tt>X</tt>, <tt>rv</tt> denotes a non-const rvalue of type <tt>X</tt>,
<tt>m</tt> is a value of type <tt>A</tt>, and <tt>Q</tt> is an allocator type.
</blockquote>

<p>
Change or add the following rows in Table 93 � Allocator-aware container
requirements in 23.2.1 [container.requirements.general]:
</p>

<blockquote>
<table border="1">
<caption>Table 93 � Allocator-aware container requirements</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td><tt>X(t, m)<br>X u(t, m);</tt></td>
<td></td>
<td><ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt>.</ins><br>
post: <tt>u == t</tt>,<br>
<tt>get_allocator() == m</tt></td>
<td>linear</td>
</tr>

<tr>
<td><tt>X(rv, m)<br>X u(rv, m);</tt></td>
<td></td>
<td><ins><i>Requires:</i> <tt>T</tt> is <tt>MoveConstructible</tt>.</ins><br>
post: <tt>u</tt> shall have the same elements, or copies of the elements, that
<tt>rv</tt> had before this construction,<br>
<tt>get_allocator() == m</tt></td>
<td>constant if <tt>m == rv.get_allocator()</tt>, otherwise linear</td>
</tr>

<tr>
<td><ins><tt>a = t</tt></ins></td>
<td><ins><tt>X&amp;</tt></ins></td>
<td><ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt><br>
post: <tt>a == t</tt>.</ins></td>
<td><ins>linear</ins></td>
</tr>

<tr>
<td><ins><tt>a = rv</tt></ins></td>
<td><ins><tt>X&amp;</tt></ins></td>
<td><ins><i>Requires:</i> If <tt>allocator_traits&lt; allocator_type &gt;
::propagate_on_container_move_assignment ::value</tt> is <tt>false</tt>,
<tt>T</tt> is <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.<br>
All existing elements of <tt>a</tt> are either move assigned
<ins>to</ins> or destroyed.<br>
<tt>a</tt> shall be equal to the value that <tt>rv</tt> had before this
assignment</ins></td>
<td><ins>linear</ins></td>
</tr>

<tr>
<td><ins><tt>a.swap(b);</tt></ins></td>
<td><ins><tt>void</tt></ins></td>
<td><ins>exchanges the contents of <tt>a</tt> and <tt>b</tt></ins></td>
<td><ins>constant</ins></td>
</tr>

</tbody></table>

</blockquote>

<p>
Change the following rows in Table 94 � Sequence container requirements
(in addition to container) in 23.2.3 [sequence.reqmts]:
</p>

<blockquote>
<table border="1">
<caption>Table 94 � Sequence container requirements (in addition to
container)</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br>pre-/post-condition</th>
</tr>

<tr>
<td><tt>X(i, j)<br>X a(i, j)</tt></td>
<td></td>
<td><i>Requires:</i> <del>If the iterator's dereference operation returns an
lvalue or a const rvalue, <tt>T</tt> shall be <tt>CopyConstructible</tt>.</del>
<ins><tt>T</tt> shall be constructible from <tt>*i</tt>.</ins><br>
<ins>If the iterator does not meet the forward iterator requirements (24.2.5 [forward.iterators]), then <tt>vector</tt> also requires <tt>T</tt> to
be <tt>MoveConstructible</tt>.</ins><br>
Each iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly
once.<br>
post: <tt>size() ==</tt> distance between <tt>i</tt> and <tt>j</tt><br>
Constructs a sequence container equal to the range <tt>[i, j)</tt></td>
</tr>

<tr>
<td><tt>a = il;</tt></td>
<td><tt>X&amp;</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt>.</ins><br>
<del><tt>a = X(il);</tt></del><br>
<ins>Assigns the range <tt>[il.begin(), il.end())</tt> into <tt>a</tt>.  All
existing elements of <tt>a</tt> are either assigned or destroyed.</ins><br>
<del>r</del><ins>R</ins>eturn<ins>s</ins> <tt>*this;</tt></td>
</tr>

<tr>
<td><tt>a.emplace(p, args);</tt></td>
<td><tt>iterator</tt></td>
<td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T,
Args&gt;</tt>.</del> <ins><tt>T</tt> is constructible from <tt>args</tt>. 
<tt>vector</tt> and <tt>deque</tt> also require <tt>T</tt> to be
<tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</ins> Inserts an object
of type <tt>T</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt> <ins>before <tt>p</tt></ins>.</td>
</tr>

<tr>
<td><tt>a.insert(p, t);</tt></td>
<td><tt>iterator</tt></td>
<td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, Args&gt;</tt> and
<tt>T</tt> shall be <tt>CopyAssignable</tt>.</del> <ins><tt>T</tt> shall be
<tt>CopyConstructible</tt>. <tt>vector</tt> and <tt>deque</tt> also require
<tt>T</tt> to be <tt>CopyAssignable</tt>.</ins> Inserts a copy <tt>t</tt> before
<tt>p</tt>.</td>
</tr>

<tr>
<td><tt>a.insert(p, rv);</tt></td>
<td><tt>iterator</tt></td>
<td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T,
T&amp;&amp;&gt;</tt> and <tt>T</tt> shall be <tt>MoveAssignable</tt>.</del>
<ins><tt>T</tt> shall be <tt>MoveConstructible</tt>. <tt>vector</tt> and
<tt>deque</tt> also require <tt>T</tt> to be <tt>MoveAssignable</tt>.</ins>
Inserts a copy <tt>rv</tt> before <tt>p</tt>.</td>
</tr>

<tr>
<td><tt>a.insert(p, i, j)</tt></td>
<td><tt>iterator</tt></td>
<td><i>Requires:</i> <del>If the iterator's dereference operation returns an
lvalue or a const rvalue, <tt>T</tt> shall be <tt>CopyConstructible</tt>.</del>
<ins><tt>T</tt> shall be constructible from <tt>*i</tt>.</ins><br> <ins>If the
iterator does not meet the forward iterator requirements (24.2.5 [forward.iterators]), then <tt>vector</tt> also requires <tt>T</tt> to
be <tt>MoveConstructible</tt> and  <tt>MoveAssignable</tt>.</ins><br> Each
iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly once.<br>
pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>.<br> Inserts
copies of elements in <tt>[i, j)</tt> before <tt>p</tt></td>
</tr>

<tr>
<td><tt>a.erase(q);</tt></td>
<td><tt>iterator</tt></td>
<td><i>Requires:</i> <del><tt>T</tt> and <tt>T</tt> shall be
<tt>MoveAssignable</tt>.</del> <ins><tt>vector</tt> and <tt>deque</tt> require
<tt>T</tt> to be <tt>MoveAssignable</tt>.</ins> Erases the element pointed to by
<tt>q</tt>.</td>
</tr>

<tr>
<td><tt>a.erase(q1, q2);</tt></td>
<td><tt>iterator</tt></td>
<td><i>Requires:</i> <del><tt>T</tt> and <tt>T</tt> shall be
<tt>MoveAssignable</tt>.</del> <ins><tt>vector</tt> and <tt>deque</tt> require
<tt>T</tt> to be <tt>MoveAssignable</tt>.</ins> Erases the elements in the range
<tt>[q1, q2)</tt>.</td>
</tr>

<tr>
<td><tt>a.clear();</tt></td>
<td><tt>void</tt></td>
<td><del><tt>erase(begin(), end())</tt></del><br>
<ins>Destroys all elements in <tt>a</tt>. <ins>Invalidates all references,
pointers, and iterators referring to the elements of <tt>a</tt> and may
invalidate the past-the-end iterator.</ins><br></ins>
post: <tt><del>size() == 0</del> <ins>a.empty() == true</ins></tt></td>
</tr>

<tr>
<td><tt>a.assign(i, j)</tt></td>
<td><tt>void</tt></td>
<td><i>Requires:</i> <del>If the iterator's dereference operation returns an
lvalue or a const rvalue, <tt>T</tt> shall be <tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt>.</del>
<ins><tt>T</tt> shall be constructible and assignable from <tt>*i</tt>.  If the
iterator does not meet the forward iterator requirements (24.2.5 [forward.iterators]), then <tt>vector</tt> also requires <tt>T</tt> to
be <tt>MoveConstructible</tt>.</ins><br>
Each iterator in the range <tt>[i,j)</tt> shall be dereferenced exactly
once.<br>
pre: <tt>i</tt>, <tt>j</tt> are not iterators into <tt>a</tt>.<br>
Replaces elements in <tt>a</tt> with a copy of <tt>[i, j)</tt>.</td>
</tr>

</tbody></table>

</blockquote>

<p>
Change the following rows in Table 95 � Optional sequence container operations
in 23.2.3 [sequence.reqmts]:
</p>

<blockquote>
<table border="1">
<caption>Table 95 � Optional sequence container operations</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Container</th>
</tr>

<tr>
<td><tt>a.emplace_front(args)</tt></td>
<td><tt>void</tt></td>
<td><del><tt>a.emplace(a.begin(), std::forward&lt;Args&gt;(args)...)</tt></del><br>
<ins>Prepends an object of type <tt>T</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt>.</ins><br>
<i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, Args&gt;</tt></del>
<ins><tt>T</tt> shall be constructible from <tt>args</tt>.</ins></td>
<td><tt>list</tt>, <tt>deque</tt>, <tt>forward_list</tt></td>
</tr>

<tr>
<td><tt>a.emplace_back(args)</tt></td>
<td><tt>void</tt></td>
<td><del><tt>a.emplace(a.end(), std::forward&lt;Args&gt;(args)...)</tt></del><br>
<ins>Appends an object of type <tt>T</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt>.</ins><br>
<i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, Args&gt;</tt></del>
<ins><tt>T</tt> shall be constructible from <tt>args</tt>. <tt>vector</tt> also
requires <tt>T</tt> to be <tt>MoveConstructible</tt>.</ins></td>
<td><tt>list</tt>, <tt>deque</tt>, <tt>vector</tt></td>
</tr>

<tr>
<td><tt>a.push_front(t)</tt></td>
<td><tt>void</tt></td>
<td><del><tt>a.insert(a.begin(), t)</tt></del><br>
<ins>Prepends a copy of <tt>t</tt>.</ins><br>
<i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, T&gt;</tt> and
<tt>T</tt> shall be <tt>CopyAssignable</tt>.</del>
<ins><tt>T</tt> shall be <tt>CopyConstructible</tt>.</ins></td>
<td><tt>list</tt>, <tt>deque</tt>, <tt>forward_list</tt></td>
</tr>

<tr>
<td><tt>a.push_front(rv)</tt></td>
<td><tt>void</tt></td>
<td><del><tt>a.insert(a.begin(), t)</tt></del><br>
<ins>Prepends a copy of <tt>rv</tt>.</ins><br>
<i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, T&amp;&amp;&gt;</tt> and
<tt>T</tt> shall be <tt>MoveAssignable</tt>.</del>
<ins><tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins></td>
<td><tt>list</tt>, <tt>deque</tt>, <tt>forward_list</tt></td>
</tr>

<tr>
<td><tt>a.push_back(t)</tt></td>
<td><tt>void</tt></td>
<td><del><tt>a.insert(a.end(), t)</tt></del><br>
<ins>Appends a copy of <tt>t</tt>.</ins><br>
<i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, T&gt;</tt> and
<tt>T</tt> shall be <tt>CopyAssignable</tt>.</del>
<ins><tt>T</tt> shall be <tt>CopyConstructible</tt>.</ins></td>
<td><tt>vector</tt>, <tt>list</tt>, <tt>deque</tt>, <tt>basic_string</tt></td>
</tr>

<tr>
<td><tt>a.push_back(rv)</tt></td>
<td><tt>void</tt></td>
<td><del><tt>a.insert(a.end(), t)</tt></del><br>
<ins>Appends a copy of <tt>rv</tt>.</ins><br>
<i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, T, T&amp;&amp;&gt;</tt> and
<tt>T</tt> shall be <tt>MoveAssignable</tt>.</del>
<ins><tt>T</tt> shall be <tt>MoveConstructible</tt>.</ins></td>
<td><tt>vector</tt>, <tt>list</tt>, <tt>deque</tt>, <tt>basic_string</tt></td>
</tr>

<tr>
<td><tt>a.pop_front()</tt></td>
<td><tt>void</tt></td>
<td><del><tt>a.erase(a.begin())</tt></del><br>
<ins>Destroys the first element.</ins><br>
<ins><i>Requires:</i> <tt>a.empty()</tt> shall be <tt>false</tt>.</ins></td>
<td><tt>list</tt>, <tt>deque</tt>, <tt>forward_list</tt></td>
</tr>

<tr>
<td><tt>a.pop_back()</tt></td>
<td><tt>void</tt></td>
<td><del><tt>{ iterator tmp = a.end();<br>--tmp;<br>a.erase(tmp); }</tt></del><br>
<ins>Destroys the last element.</ins><br>
<ins><i>Requires:</i> <tt>a.empty()</tt> shall be <tt>false</tt>.</ins></td>
<td><tt>vector</tt>, <tt>list</tt>, <tt>deque</tt>, <tt>basic_string</tt></td>
</tr>

</tbody></table>

</blockquote>

<p>
Insert a new paragraph prior to 23.2.4 [associative.reqmts]/7, and
edit paragraph 7:
</p>

<blockquote>
<p><ins>
The associative containers meet all of the requirements of Allocator-aware
containers (23.2.1 [container.requirements.general]), except for the
containers <tt>map</tt> and <tt>multimap</tt>, the requirements placed on
<tt>value_type</tt> in Table 93 apply instead directly to <tt>key_type</tt> and
<tt>mapped_type</tt>. [<i>Note:</i> For example <tt>key_type</tt> and
<tt>mapped_type</tt> are sometimes required to be <tt>CopyAssignable</tt> even
though the <tt>value_type</tt> (<tt>pair&lt;const key_type,
mapped_type&gt;</tt>) is not <tt>CopyAssignable</tt>. � <i>end note</i>]
</ins></p>

<p>
7 In Table 96, <tt>X</tt> denotes an associative container class, a denotes a
value of <tt>X</tt>, <tt>a_uniq</tt> denotes a value of <tt>X</tt> when
<tt>X</tt> supports unique keys, <tt>a_eq</tt> denotes a value of <tt>X</tt>
when <tt>X</tt> supports multiple keys, <tt>u</tt> denotes an identifier,
<del><tt>r</tt> denotes an lvalue or a const rvalue of type <tt>X</tt>,
<tt>rv</tt> denotes a non-const rvalue of type <tt>X</tt>,</del> <tt>i</tt> and
<tt>j</tt> satisfy input iterator requirements and refer to elements implicitly
convertible to <tt>value_type</tt>, <tt>[i,j)</tt> denotes a valid range,
<tt>p</tt> denotes a valid const iterator to <tt>a</tt>, <tt>q</tt> denotes a
valid dereferenceable const iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a
valid range of const iterators in <tt>a</tt>, <tt>il</tt> designates an object
of type <tt>initializer_list&lt;value_type&gt;</tt>, <tt>t</tt> denotes a value
of <tt>X::value_type</tt>, <tt>k</tt> denotes a value of <tt>X::key_type</tt>
and <tt>c</tt> denotes a value of type <tt>X::key_compare</tt>. <tt>A</tt>
denotes the storage allocator used by <tt>X</tt>, if any, or
<tt>std::allocator&lt;X::value_type&gt;</tt> otherwise, and <tt>m</tt> denotes
an allocator of a type convertible to <tt>A</tt>. </p>
</blockquote>

<p>
Change or add the following rows in Table 96 � Associative container
requirements (in addition to container) in 23.2.4 [associative.reqmts]:
</p>

<blockquote>
<table border="1">
<caption>Table 96 � Associative container requirements (in addition to
container)</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td><tt>X::key_type</tt></td>
<td><tt>Key</tt></td>
<td><ins><i>Requires:</i></ins> <tt>Key</tt> is <del><tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt></del> <ins><tt>Destructible</tt></ins></td>
<td>compile time</td>
</tr>

<tr>
<td><ins><tt>X::mapped_type</tt> (<tt>map</tt> and <tt>multimap</tt> only)</ins></td>
<td><ins><tt>T</tt></ins></td>
<td><ins><i>Requires:</i> <tt>T</tt> is <tt>Destructible</tt></ins></td>
<td><ins>compile time</ins></td>
</tr>

<tr>
<td><tt>X(c)<br>X a(c);</tt></td>
<td></td>
<td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, key_compare,
key_compare&gt;</tt></del>.<br>
<ins><tt>key_compare</tt> is <tt>CopyConstructible</tt>.</ins><br>
Constructs an empty container.<br>
Uses a copy of <tt>c</tt> as a comparison object.</td>
<td>constant</td>
</tr>

<tr>
<td><tt>X()<br>X a;</tt></td>
<td></td>
<td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, key_compare,
key_compare&gt;</tt></del>.<br>
<ins><tt>key_compare</tt> is <tt>DefaultConstructible</tt>.</ins><br>
Constructs an empty container.<br>
Uses <tt>Compare()</tt> as a comparison object.</td>
<td>constant</td>
</tr>

<tr>
<td><tt>X(i, j, c)<br>X a(i, j, c);</tt></td>
<td></td>
<td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, key_compare,
key_compare&gt;</tt></del>.<br>
<ins><tt>key_compare</tt> is <tt>CopyConstructible</tt>. <tt>value_type</tt>
shall be constructible from <tt>*i</tt>.</ins><br>
Constructs an empty container ans inserts elements from the range <tt>[i,
j)</tt> into it; uses <tt>c</tt> as a comparison object.</td>
<td><tt>N</tt> log <tt>N</tt> in general (<tt>N</tt> is the distance from
<tt>i</tt> to <tt>j</tt>); linear if <tt>[i, j)</tt> is sorted with
<tt>value_comp()</tt></td>
</tr>

<tr>
<td><tt>X(i, j)<br>X a(i, j);</tt></td>
<td></td>
<td><i>Requires:</i> <del><tt>ConstructibleAsElement&lt;A, key_compare,
key_compare&gt;</tt></del>.<br> <ins><tt>value_type</tt> shall be constructible
from <tt>*i</tt>. <tt>key_compare</tt> is
<tt>DefaultConstructible</tt>.</ins><br> Same as above, but uses
<tt>Compare()</tt> as a comparison object.</td>
<td>same as above</td>
</tr>

<tr>
<td><tt>a = il</tt></td>
<td><tt>X&amp;</tt></td>
<td><del><tt>a = X(il);<br>
return *this;</tt></del><br>
<ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt>.</ins><br>
<ins>Assigns the range <tt>[il.begin(), il.end())</tt> into <tt>a</tt>.  All
existing elements of <tt>a</tt> are either assigned or destroyed.</ins></td>
<td><del>Same as <tt><tt>a = X(il)</tt></tt>.</del>
<ins><tt>N</tt> log <tt>N</tt> in general (<tt>N</tt> is 
<tt>il.size()</tt> added to the existing size of <tt>a</tt>); linear if
<tt>[il.begin(), il.end())</tt> is sorted with <tt>value_comp()</tt></ins></td>
</tr>

<tr>
<td><tt>a_uniq.emplace(args)</tt></td>
<td><tt>pair&lt;iterator, bool&gt;</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
<tt>args</tt></ins><br>
inserts a <tt>T</tt> object <tt>t</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt> if and only if there is no element in
the container with key equivalent to the key of <tt>t</tt>. The <tt>bool</tt>
component of the returned pair is true if and only if the insertion takes place,
and the iterator component of the pair points to the element with key equivalent
to the key of <tt>t</tt>.</td>
<td>logarithmic</td>
</tr>

<tr>
<td><tt>a_eq.emplace(args)</tt></td>
<td><tt>iterator</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
<tt>args</tt></ins><br>
inserts a <tt>T</tt> object <tt>t</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt> and returns the iterator pointing to
the newly inserted element.</td>
<td>logarithmic</td>
</tr>

<tr>
<td><tt>a_uniq.insert(t)</tt></td>
<td><tt>pair&lt;iterator, bool&gt;</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
<tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
<tt>CopyConstructible</tt>.</ins><br>
inserts <tt>t</tt> if and only if there is no element in the container with key
equivalent to the key of <tt>t</tt>. The <tt>bool</tt> component of the returned
pair is true if and only if the insertion takes place, and the iterator
component of the pair points to the element with key equivalent to the key of
<tt>t</tt>.</td>
<td>logarithmic</td>
</tr>

<tr>
<td><tt>a_eq.insert(t)</tt></td>
<td><tt>iterator</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
<tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
<tt>CopyConstructible</tt>.</ins><br>
inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
element. If a range containing elements equivalent to <tt>t</tt> exists in
<tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</td>
<td>logarithmic</td>
</tr>

<tr>
<td><tt>a.insert(p, t)</tt></td>
<td><tt>iterator</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
<tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
<tt>CopyConstructible</tt>.</ins><br>
inserts <tt>t</tt> if and only if there is no element with key equivalent to the
key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in
containers with equivalent keys; always returns the iterator pointing to the
element with key equivalent to the key of <tt>t</tt>. <tt>t</tt> is inserted as
close as possible to the position just prior to <tt>p</tt>.</td>
<td>logarithmic in general, but amortized constant if <tt>t</tt> is inserted
right before <tt>p</tt>.</td>
</tr>

<tr>
<td><tt>a.insert(i, j)</tt></td>
<td><tt>void</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be
constructible from <tt>*i</tt>.</ins><br>
pre: <tt>i</tt>, <tt>j</tt> are not iterators into <tt>a</tt>. inserts each
element from the range <tt>[i,j)</tt> if and only if there is no element with
key equivalent to the key of that element in containers with unique keys; always
inserts that element in containers with equivalent keys.</td>
<td>N log(size() + N ) (N is the distance from i to j)</td>
</tr>

</tbody></table>

</blockquote>

<p>
Insert a new paragraph prior to 23.2.5 [unord.req]/9:
</p>

<blockquote>
<p><ins>
The unordered associative containers meet all of the requirements of
Allocator-aware containers (23.2.1 [container.requirements.general]),
except for the containers <tt>unordered_map</tt> and <tt>unordered_multimap</tt>,
the requirements placed on <tt>value_type</tt> in Table 93 apply instead
directly to <tt>key_type</tt> and <tt>mapped_type</tt>. [<i>Note:</i> For
example <tt>key_type</tt> and <tt>mapped_type</tt> are sometimes required to be
<tt>CopyAssignable</tt> even though the <tt>value_type</tt> (<tt>pair&lt;const
key_type, mapped_type&gt;</tt>) is not <tt>CopyAssignable</tt>. � <i>end
note</i>]
</ins></p>

<p>
9 ...
</p>
</blockquote>

<p>
Change or add the following rows in Table 98 � Unordered associative
container requirements (in addition to container) in 23.2.5 [unord.req]:
</p>

<blockquote>
<table border="1">
<caption>Table 98 � Unordered associative
container requirements (in addition to container)</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td><tt>X::key_type</tt></td>
<td><tt>Key</tt></td>
<td><ins><i>Requires:</i></ins> <tt>Key</tt> shall be <del><tt>CopyAssignable</tt> and
<tt>CopyConstructible</tt></del> <ins><tt>Destructible</tt></ins></td>
<td>compile time</td>
</tr>

<tr>
<td><ins><tt>X::mapped_type</tt> (<tt>unordered_map</tt> and
<tt>unordered_multimap</tt> only)</ins></td>
<td><ins><tt>T</tt></ins></td>
<td><ins><i>Requires:</i><tt>T</tt> is <tt>Destructible</tt></ins></td>
<td><ins>compile time</ins></td>
</tr>

<tr>
<td><tt>X(n, hf, eq)<br>X a(n, hf, eq)</tt></td>
<td><tt>X</tt></td>
<td><ins><i>Requires:</i> <tt>hasher</tt>  and <tt>key_equal</tt> are
<tt>CopyConstructible</tt>.</ins> Constructs an empty container with at least
<tt>n</tt> buckets, using <tt>hf</tt> as the hash function and <tt>eq</tt> as
the key equality predicate. </td>
<td><tt>O(N)</tt></td>
</tr>

<tr>
<td><tt>X(n, hf)<br>X a(n, hf)</tt></td>
<td><tt>X</tt></td>
<td><ins><i>Requires:</i> <tt>hasher</tt> is <tt>CopyConstructible</tt> and 
<tt>key_equal</tt> is <tt>DefaultConstructible</tt>.</ins> Constructs an empty
container with at least <tt>n</tt> buckets, using <tt>hf</tt> as the hash
function and <tt>key_equal()</tt> as the key equality predicate.</td>
<td><tt>O(N)</tt></td>
</tr>

<tr>
<td><tt>X(n)<br>X a(n)</tt></td>
<td><tt>X</tt></td>
<td><ins><i>Requires:</i> <tt>hasher</tt>  and <tt>key_equal</tt> are
<tt>DefaultConstructible</tt>.</ins> Constructs an empty container with at least
<tt>n</tt> buckets, using <tt>hasher()</tt> as the hash function and <tt>key_equal()</tt> as
the key equality predicate. </td>
<td><tt>O(N)</tt></td>
</tr>

<tr>
<td><tt>X()<br>X a</tt></td>
<td><tt>X</tt></td>
<td><ins><i>Requires:</i> <tt>hasher</tt>  and <tt>key_equal</tt> are
<tt>DefaultConstructible</tt>.</ins> Constructs an empty container an unspecified number of buckets,
using <tt>hasher()</tt> as the hash function and <tt>key_equal()</tt> as
the key equality predicate. </td>
<td>constant</td>
</tr>

<tr>
<td><tt>X(i, j, n, hf, eq)<br>X a(i, j, n, hf, eq)</tt></td>
<td><tt>X</tt></td>
<td><ins><i>Requires:</i> <tt>value_type</tt> is constructible from
<tt>*i</tt>. <tt>hasher</tt>  and <tt>key_equal</tt> are
<tt>CopyConstructible</tt>.</ins><br>
Constructs an empty container with at least <tt>n</tt> buckets, using
<tt>hf</tt> as the hash function and <tt>eq</tt> as the key equality predicate,
and inserts elements from <tt>[i, j)</tt> into it.</td>
<td>Average case <tt>O(N)</tt> (<tt>N</tt> is <tt>distance(i, j)</tt>), worst
case <tt>O(N<sup>2</sup>)</tt></td>
</tr>

<tr>
<td><tt>X(i, j, n, hf)<br>X a(i, j, n, hf)</tt></td>
<td><tt>X</tt></td>
<td><ins><i>Requires:</i> <tt>value_type</tt> is constructible from <tt>*i</tt>.
<tt>hasher</tt> is <tt>CopyConstructible</tt> and <tt>key_equal</tt> is
<tt>DefaultConstructible</tt>.</ins><br> Constructs an empty container with at
least <tt>n</tt> buckets, using <tt>hf</tt> as the hash function and
<tt>key_equal()</tt> as the key equality predicate, and inserts elements from
<tt>[i, j)</tt> into it.</td>
<td>Average case <tt>O(N)</tt> (<tt>N</tt> is <tt>distance(i, j)</tt>), worst
case <tt>O(N<sup>2</sup>)</tt></td>
</tr>

<tr>
<td><tt>X(i, j, n)<br>X a(i, j, n)</tt></td>
<td><tt>X</tt></td>
<td><ins><i>Requires:</i> <tt>value_type</tt> is constructible from <tt>*i</tt>.
<tt>hasher</tt> and <tt>key_equal</tt> are
<tt>DefaultConstructible</tt>.</ins><br> Constructs an empty container with at
least <tt>n</tt> buckets, using <tt>hasher()</tt> as the hash function and
<tt>key_equal()</tt> as the key equality predicate, and inserts elements from
<tt>[i, j)</tt> into it.</td>
<td>Average case <tt>O(N)</tt> (<tt>N</tt> is <tt>distance(i, j)</tt>), worst
case <tt>O(N<sup>2</sup>)</tt></td>
</tr>

<tr>
<td><tt>X(i, j)<br>X a(i, j)</tt></td>
<td><tt>X</tt></td>
<td><ins><i>Requires:</i> <tt>value_type</tt> is constructible from <tt>*i</tt>.
<tt>hasher</tt> and <tt>key_equal</tt> are
<tt>DefaultConstructible</tt>.</ins><br> Constructs an empty container with an
unspecified number of buckets, using <tt>hasher()</tt> as the hash function and
<tt>key_equal()</tt> as the key equality predicate, and inserts elements from
<tt>[i, j)</tt> into it.</td>
<td>Average case <tt>O(N)</tt> (<tt>N</tt> is <tt>distance(i, j)</tt>), worst
case <tt>O(N<sup>2</sup>)</tt></td>
</tr>

<tr>
<td><tt>X(b)<br>X a(b)</tt></td>
<td><tt>X</tt></td>
<td>Copy constructor. In addition to the <del>contained elements</del>
<ins>requirements of Table 93 (23.2.1 [container.requirements.general])</ins>, copies the hash function,
predicate, and maximum load factor.</td>
<td>Average case linear in <tt>b.size()</tt>, worst case quadratic.</td>
</tr>

<tr>
<td><tt>a = b</tt></td>
<td><tt>X&amp;</tt></td>
<td>Copy assignment operator. In addition to the <del>contained elements</del>
<ins>requirements of Table 93 (23.2.1 [container.requirements.general])</ins>, copies the hash function,
predicate, and maximum load factor.</td>
<td>Average case linear in <tt>b.size()</tt>, worst case quadratic.</td>
</tr>

<tr>
<td><tt>a = il</tt></td>
<td><tt>X&amp;</tt></td>
<td><del><tt>a = X(il); return *this;</tt></del><br>
<ins><i>Requires:</i> <tt>T</tt> is <tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt>.</ins><br>
<ins>Assigns the range <tt>[il.begin(), il.end())</tt> into <tt>a</tt>.  All
existing elements of <tt>a</tt> are either assigned or destroyed.</ins></td>
<td>Average case linear in <tt>il.size()</tt>, worst case quadratic.</td>
</tr>

<tr>
<td><tt>a_uniq.emplace(args)</tt></td>
<td><tt>pair&lt;iterator, bool&gt;</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
<tt>args</tt></ins><br>
inserts a <tt>T</tt> object <tt>t</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt> if and only if there is no element in
the container with key equivalent to the key of <tt>t</tt>. The <tt>bool</tt>
component of the returned pair is true if and only if the insertion takes place,
and the iterator component of the pair points to the element with key equivalent
to the key of <tt>t</tt>.</td>
<td>Average case O(1), worst case O(<tt>a_uniq.size()</tt>).</td>
</tr>

<tr>
<td><tt>a_eq.emplace(args)</tt></td>
<td><tt>iterator</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
<tt>args</tt></ins><br>
inserts a <tt>T</tt> object <tt>t</tt> constructed with
<tt>std::forward&lt;Args&gt;(args)...</tt> and returns the iterator pointing to
the newly inserted element.</td>
<td>Average case O(1), worst case O(<tt>a_eq.size()</tt>).</td>
</tr>

<tr>
<td><tt>a.emplace_hint(p, args)</tt></td>
<td><tt>iterator</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be constructible from
<tt>args</tt></ins><br>
equivalent to <tt>a.emplace( std::forward&lt;Args&gt;(args)...)</tt>. Return
value is an iterator pointing to the element with the key equivalent to the
newly inserted element. The <tt>const_iterator p</tt> is a hint pointing to
where the search should start. Implementations are permitted to ignore the
hint.</td>
<td>Average case O(1), worst case O(<tt>a.size()</tt>).</td>
</tr>

<tr>
<td><tt>a_uniq.insert(t)</tt></td>
<td><tt>pair&lt;iterator, bool&gt;</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
<tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
<tt>CopyConstructible</tt>.</ins><br>
Inserts <tt>t</tt> if and only if there is no element in the container with key
equivalent to the key of <tt>t</tt>. The <tt>bool</tt> component of the returned
pair indicates whether the insertion takes place, and the iterator component
points to the element with key equivalent to the key of <tt>t</tt>.</td>
<td>Average case O(1), worst case O(<tt>a_uniq.size()</tt>).</td>
</tr>

<tr>
<td><tt>a_eq.insert(t)</tt></td>
<td><tt>iterator</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
<tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
<tt>CopyConstructible</tt>.</ins><br>
Inserts <tt>t</tt>, and returns an iterator pointing to the newly inserted
element.</td>
<td>Average case O(1), worst case O(<tt>a_uniq.size()</tt>).</td>
</tr>

<tr>
<td><tt>a.insert(q, t)</tt></td>
<td><tt>iterator</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt> if
<tt>t</tt> is a non-const rvalue expression, else <tt>T</tt> shall be
<tt>CopyConstructible</tt>.</ins><br>
Equivalent to <tt>a.insert(t)</tt>. Return value is an iterator pointing to the
element with the key equivalent to that of <tt>t</tt>. The iterator <tt>q</tt>
is a hint pointing to where the search should start. Implementations are
permitted to ignore the hint.</td>
<td>Average case O(1), worst case O(<tt>a_uniq.size()</tt>).</td>
</tr>

<tr>
<td><tt>a.insert(i, j)</tt></td>
<td><tt>void</tt></td>
<td><ins><i>Requires:</i> <tt>T</tt> shall be
constructible from <tt>*i</tt>.</ins><br>
Pre: <tt>i</tt> and <tt>j</tt> are not iterators in <tt>a</tt>. Equivalent to
<tt>a.insert(t)</tt> for each element in <tt>[i,j)</tt>.</td>
<td>Average case O(<tt>N</tt>), where <tt>N</tt> is <tt>distance(i, j)</tt>.
Worst case O(<tt>N * a.size()</tt>).</td>
</tr>

</tbody></table>

</blockquote>

<p>
Change 23.3.3 [forwardlist]/2:
</p>

<blockquote>
2 A <tt>forward_list</tt> satisfies all of the requirements of a container
(table 91), except that the <tt>size()</tt> member function is not provided.
<ins>A <tt>forward_list</tt> also satisfies all of the requirements of an
allocator-aware container (table 93).  And <tt>forward_list</tt> provides the
<tt>assign</tt> member functions as specified in Table 94, Sequence container
requirements, and several of the optional sequence container requirements (Table
95).</ins>
Descriptions are provided here only for operations on <tt>forward_list</tt> that
are not described in that table or for operations where there is additional
semantic information.
</blockquote>

<p>
Add a new paragraph after 23.3.3.4 [forwardlist.modifiers]/23:
</p>

<blockquote><pre>void clear();
</pre>

<blockquote>
<p>
23 <i>Effects:</i> Erases all elements in the range <tt>[begin(),end())</tt>.
</p>
<p><ins>
<i>Remarks:</i> Does not invalidate past-the-end iterators.
</ins></p>
</blockquote>
</blockquote>

<p>
Change 23.4.1.2 [vector.capacity]/13:
</p>

<blockquote><pre>void resize(size_type sz, const T&amp; c);
</pre>
<blockquote>
13 <i>Requires:</i> <ins><tt>T</tt> shall be <tt>CopyConstructible</tt>.</ins>
If <tt>value_type</tt> has a move constructor, that constructor shall not throw
any exceptions.
</blockquote>
</blockquote>

<p>
In 23.7.3 [unord.set] and 23.7.4 [unord.multiset] substitute
"<tt>Key</tt>" for "<tt>Value</tt>".
</p>

<blockquote>
<p><i>[
The above substitution is normative as it ties into the requirements table.
]</i></p>

</blockquote>






<hr>
<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
<p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current working draft has a type-trait <tt>decay</tt> in 20.7.7.6 [meta.trans.other].
</p>

<p>
Its use is to turn C++03 pass-by-value parameters into efficient C++0x
pass-by-rvalue-reference parameters. However, the current definition
introduces an incompatible change where the cv-qualification of the
parameter type is retained. The deduced type should loose such
cv-qualification, as pass-by-value does.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 20.7.7.6 [meta.trans.other] change the last sentence:
</p>

<blockquote><p>
Otherwise the  member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
</p></blockquote>

<p>
In 20.4.2.4 [tuple.creation]/1 change:
</p>

<blockquote><p>
<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
corresponding type <tt>Ti</tt> in <tt>Types</tt>,
<tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
<tt>decay&lt;Ti&gt;::type</tt>.</del>
<ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
is <tt>X&amp;</tt> if <tt>Ui</tt> equals
<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
<tt>Ui</tt>.</ins>
</p></blockquote>






<hr>
<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current draft has <tt>make_pair()</tt> in 20.3.5 [pairs]/16
and <tt>make_tuple()</tt> in 20.4.2.4 [tuple.creation].
<tt>make_tuple()</tt> detects the presence of
<tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
such cases. <tt>make_pair()</tt> would OTOH create a
<tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
functions are made to behave similar in this respect to minimize
confusion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 20.3 [utility] change the synopsis for make_pair() to read
</p>

<blockquote><pre>template &lt;class T1, class T2&gt;
  pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
</pre></blockquote>

<p>
In 20.3.5 [pairs]/16 change the declaration to match the above synopsis.
Then change the 20.3.5 [pairs]/17 to:
</p>

<blockquote>
<p>
<i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
<tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
<tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
<tt>Ui</tt>.</ins>
</p>
</blockquote>






<hr>
<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
<p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The changes made for <tt>constexpr</tt> in 21.2.3 [char.traits.specializations] have 
not only changed the <tt>not_eof</tt> function from pass by const reference to 
pass by value, it has also changed the parameter type from <tt>int_type</tt> to 
<tt>char_type</tt>.
</p>
<p>
This doesn't work for type <tt>char</tt>, and is inconsistent with the 
requirements in Table 56, Traits requirements, 21.2.1 [char.traits.require].
</p>

<p>
Pete adds:
</p>

<blockquote><p>
For what it's worth, that may not have been an intentional change. 
N2349, which detailed the changes for adding constant expressions to 
the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that 
surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. 
So the intention may have been just to change to pass by value, with 
text incorrectly copied from the standard.
</p></blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change the signature in 21.2.3.1 [char.traits.specializations.char],
21.2.3.2 [char.traits.specializations.char16_t], 21.2.3.3 [char.traits.specializations.char32_t],
and 21.2.3.4 [char.traits.specializations.wchar.t] to
</p>

<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
</pre></blockquote>



<p><i>[
Bellevue:
]</i></p>


<blockquote>
Resolution: NAD editorial - up to Pete's judgment
</blockquote>

<p><i>[
Post Sophia Antipolis
]</i></p>


<blockquote>
Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
</blockquote>




<hr>
<h3><a name="710"></a>710. Missing postconditions</h3>
<p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A discussion on
<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
has identified a contradiction in the <tt>shared_ptr</tt> specification.
The <tt>shared_ptr</tt> move constructor and the cast functions are
missing postconditions for the <tt>get()</tt> accessor.
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Move to "ready", adopting the first (Peter's) proposed resolution.
</p>
<p>
Note to the project editor: there is an editorial issue here. The
wording for the postconditions of the casts is slightly awkward, and the
editor should consider rewording "If w is the return value...", e. g. as
"For a return value w...".
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Add to 20.9.10.2.1 [util.smartptr.shared.const]:
</p>

<blockquote>
<pre>shared_ptr(shared_ptr&amp;&amp; r);
template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
</pre>
<blockquote>
<p>
<i>Postconditions:</i>  <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
</p>
</blockquote>
</blockquote>

<p>
Add to 20.9.10.2.10 [util.smartptr.shared.cast]:
</p>

<blockquote>
<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
</pre>
<blockquote>
<p>
<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
<tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
</p>
</blockquote>
</blockquote>

<blockquote>
<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
</pre>
<blockquote>
<p>
<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
</p>
</blockquote>
</blockquote>

<blockquote>
<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
</pre>
<blockquote>
<p>
<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
<tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
</p>
</blockquote>
</blockquote>

<p>
Alberto Ganesh Barbati has written an
<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
where he suggests (among other things) that the casts be respecified in terms of
the aliasing constructor as follows:
</p>

<p>
Change 20.9.10.2.10 [util.smartptr.shared.cast]:
</p>

<blockquote>
<p>
-2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
</p>
</blockquote>

<blockquote>
<p>
-6- <i>Returns:</i>
</p>
<ul>
<li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy 
of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
<li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
<li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
<li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
</ul>
</blockquote>

<blockquote>
<p>
-10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
</p>
</blockquote>

<p>
This takes care of the missing postconditions for the casts by bringing
in the aliasing constructor postcondition "by reference".
</p>






<hr>
<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
<p><b>Section:</b> 20.9.10.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A discussion on
<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
has identified a contradiction in the <tt>shared_ptr</tt> specification.
The note:
</p>

<blockquote><p>
[ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
-end note ]
</p></blockquote>

<p>
after the aliasing constructor
</p>

<blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
</pre></blockquote>

<p>
reflects the intent of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
to, well, allow the creation of an empty <tt>shared_ptr</tt>
with a non-NULL stored pointer.
</p>

<p>
This is contradicted by the second sentence in the Returns clause of 20.9.10.2.5 [util.smartptr.shared.obs]:
</p>

<blockquote>
<pre>T* get() const;
</pre>
<blockquote><p>
<i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
</p></blockquote>
</blockquote>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Adopt option 1 and move to review, not ready.
</p>
<p>
There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
isn't defined anywhere), and whether we have a good mental model for how
one behaves. We think it might be possible to deduce what the definition
should be, but the words just aren't there. We need to open an issue on
the use of this undefined term. (The resolution of that issue might
affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>.)
</p>
<p>
The LWG is getting more uncomfortable with the aliasing proposal (N2351)
now that we realize some of its implications, and we need to keep an eye
on it, but there isn't support for removing this feature at this time.
</p>
</blockquote>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
We heard from Peter Dimov, who explained his reason for preferring solution 1.
</p>
<p>
Because it doesn't seem to add anything. It simply makes the behavior
for p = 0 undefined. For programmers who don't create empty pointers
with p = 0, there is no difference. Those who do insist on creating them
presumably have a good reason, and it costs nothing for us to define the
behavior in this case.
</p>
<p>
The aliasing constructor is sharp enough as it is, so "protecting" users
doesn't make much sense in this particular case.
</p>
<p>
&gt; Do you have a use case for r being empty and r being non-null? 
</p>
<p>
I have received a few requests for it from "performance-conscious"
people (you should be familiar with this mindset) who don't like the
overhead of allocating and maintaining a control block when a null
deleter is used to approximate a raw pointer. It is obviously an "at
your own risk", low-level feature; essentially a raw pointer behind a
shared_ptr facade.
</p>
<p>
We could not agree upon a resolution to the issue; some of us thought
that Peter's description above is supporting an undesirable behavior.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
We favor option 1, move to Ready.
</p>
<p><i>[
Howard:  Option 2 commented out for clarity, and can be brought back.
]</i></p>

</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In keeping the N2351 spirit and obviously my preference, change 20.9.10.2.5 [util.smartptr.shared.obs]:
</p>

<blockquote>
<pre>T* get() const;
</pre>
<blockquote><p>
<i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
</p></blockquote>
</blockquote>








<hr>
<h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Marc Paterno <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
One of the motivations for incorporating <tt>seed_seq::size()</tt>
was to simplify the wording
in other parts of 26.5 [rand].
As a side effect of resolving related issues,
all such references
to <tt>seed_seq::size()</tt> will have been excised.
More importantly,
the present specification is contradictory,
as "The number of 32-bit units the object can deliver"
is not the same as "the result of <tt>v.size()</tt>."
</p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
for some further discussion.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Adopt the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
</p>


<p><i>[
Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
]</i></p>





<hr>
<h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
<p><b>Section:</b> 25.4.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
average", with no worst case complicity specified. The intention was to
allow a median-of-three quicksort implementation, which is usually <tt>O(N
log N)</tt> but can be quadratic for pathological inputs. However, there is
no longer any reason to allow implementers the freedom to have a
worst-cast-quadratic sort algorithm. Implementers who want to use
quicksort can use a variant like David Musser's "Introsort" (Software
Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
log N)</tt> in the worst case without incurring additional overhead in the
average case. Most C++ library implementers already do this, and there
is no reason not to guarantee it in the standard.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 25.4.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
</p>

<blockquote>
<p>
<i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> (where <i>N</i> == <i>last</i> - <i>first</i> )
comparisons<del> on the average</del>.<del><sup>266)</sup></del>
</p>
<p>
<del><sup>266)</sup>
If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
(25.3.1.3) should be used.</del>
</p>
</blockquote>






<hr>
<h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
<p><b>Section:</b> 25.2.13 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The complexity for <tt>search_n</tt> (25.2.13 [alg.search] par 7) is specified as "At most
(last - first ) * count applications of the corresponding predicate if
count is positive, or 0 otherwise." This is unnecessarily pessimistic.
Regardless of the value of count, there is no reason to examine any
element in the range more than once.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the complexity to "At most (last - first) applications of the corresponding predicate".
</p>

<blockquote>
<pre>template&lt;class ForwardIterator, class Size, class T&gt; 
  ForwardIterator 
    search_n(ForwardIterator first , ForwardIterator last , Size count , 
             const T&amp; value ); 

template&lt;class ForwardIterator, class Size, class T, 
         class BinaryPredicate&gt; 
  ForwardIterator 
    search_n(ForwardIterator first , ForwardIterator last , Size count , 
             const T&amp; value , BinaryPredicate pred );
</pre>
<blockquote>
<p>
<i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
<del>if <tt>count</tt> is positive, or 0 otherwise</del>.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The complexity for <tt>minmax_element</tt> (25.4.7 [alg.min.max] par 16) says "At most <tt>max(2 *
(last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
<tt>max_element</tt> separately. This is gratuitously inefficient. There is a
well known technique that does better: see section 9.1 of CLRS
(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 25.4.7 [alg.min.max] to:
</p>

<blockquote>
<pre>template&lt;class ForwardIterator&gt; 
  pair&lt;ForwardIterator, ForwardIterator&gt; 
    minmax_element(ForwardIterator first , ForwardIterator last); 
template&lt;class ForwardIterator, class Compare&gt; 
  pair&lt;ForwardIterator, ForwardIterator&gt; 
    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
<del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
comp)</tt></del> <ins>the first iterator in <tt>[first,
last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
<ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
<tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
</p>
<p>
<i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
<ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
<p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-08-31 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
</p>

<blockquote>
<p>
The following productions within the ECMAScript grammar are modified as follows:
</p>

<blockquote><pre>CharacterClass ::
[ [lookahead &#8713; {^}] ClassRanges ]
[ ^ ClassRanges ]
</pre></blockquote>

</blockquote>

<p>
This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
</p>

<p>
Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We agree that what is specified is identical to what ECMA-262 specifies.
Pete would like to take a bit of time to assess whether we had intended,
but failed, to make a change.
It would also be useful to hear from John Maddock on the issue.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Remove this mention of the CharacterClass production.
</p>

<blockquote><pre><del>CharacterClass ::
[ [lookahead &#8713; {^}] ClassRanges ]
[ ^ ClassRanges ]</del>
</pre></blockquote>






<hr>
<h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
<p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a></p>
<p><b>Discussion:</b></p>
<p>
Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
</p>

<blockquote>
<p>
-11- A type is a <i>literal</i> type if it is:
</p>
<ul>
<li>a scalar type; or</li>
<li><p>a class type (clause 9) with</p>
<ul>
<li>a trivial copy constructor,</li>
<li>a trivial destructor,</li>
<li>at least one constexpr constructor other than the copy constructor,</li>
<li>no virtual base classes, and</li>
<li>all non-static data members and base classes of literal types; or</li>
</ul>
</li>
<li>an array of literal type.</li>
</ul>
</blockquote>

<p>
I strongly suggest that the standard provides a type traits for
literal types in 20.7.4.3 [meta.unary.prop] for several reasons:
</p>

<ol type="a">
<li>To keep the traits in sync with existing types.</li>
<li>I see many reasons for programmers to use this trait in template
   code to provide optimized template definitions for these types,
   see below.</li>
<li>A user-provided definition of this trait is practically impossible
to write portably.</li>
</ol>

<p>
The special problem of reason (c) is that I don't see currently a
way to portably test the condition for literal class types:
</p>

<blockquote>
<ul>
<li>at least one constexpr constructor other than the copy constructor,</li>
</ul>
</blockquote>

<p><i>[
Alisdair is considering preparing a paper listing a number of missing
type traits, and feels that it might be useful to handle them all
together rather than piecemeal. This would affect issue 719 and 750.
These two issues should move to OPEN pending AM paper on type traits.
]</i></p>


<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Beman, Daniel, and Alisdair will work on a paper proposing new type traits.
</blockquote>

<p><i>[
Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.htm">N2984</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In 20.7.2 [meta.type.synop] in the group "type properties",
just below the line
</p>

<blockquote><pre>template &lt;class T&gt; struct is_pod;
</pre></blockquote>

<p>
add a new one:
</p>

<blockquote><pre>template &lt;class T&gt; struct is_literal;
</pre></blockquote>

<p>
In 20.7.4.3 [meta.unary.prop], table Type Property Predicates, just
below the line for the <tt>is_pod</tt> property add a new line:
</p>

<table border="1">
<tbody><tr>
<th>Template</th><th>Condition</th><th>Preconditions</th>
</tr>
<tr>
<td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
<td><tt>T</tt> is a literal type (3.9)</td>
<td><tt>T</tt> shall be a complete type, an
array of unknown bound, or
(possibly cv-qualified) <tt>void</tt>.</td>
</tr>
</tbody></table>






<hr>
<h3><a name="720"></a>720. Omissions in constexpr usages</h3>
<p><b>Section:</b> 23.3.1 [array], 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<ol>
<li>
The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
<tt>constexpr</tt> because this is easily to proof and to implement following it's operational
semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
</li>
<li>
The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
</li>
<li>
I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
initialisation. What have I overlooked here?
</li>
</ol>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
We handle this as two parts
</p>
<ol>
<li>
The proposed resolution is correct; move to ready.
</li>
<li>
The issue points out a real problem, but the issue is larger than just
this solution. We believe a paper is needed, applying the full new
features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
We note that we do not consider this new work, and that is should be
handled by the Library Working Group.
</li>
</ol>
<p>
In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>In the class template definition of 23.3.1 [array]/p. 3 change</p>
<blockquote><pre><ins>constexpr</ins> bool empty() const;
</pre></blockquote>
</li>

<li>
<p>In the class template definition of 20.5 [template.bitset]/p. 1 change</p>
<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
</pre></blockquote>

<p>
and in 20.5.2 [bitset.members] change
</p>

<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
</pre></blockquote>

</li>
</ol>





<hr>
<h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the listing of 26.8 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
the following C99 functions (from 7.12.11.2):
</p>

<blockquote><pre>float nanf(const char *tagp);
long double nanl(const char *tagp);
</pre></blockquote>

<p>
(Note: These functions cannot be overloaded and they are also not
listed anywhere else)
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 26.8 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
just after the existing entry <tt>nan</tt>.
</p>





<hr>
<h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 316</b></p>

<p>
According to the current state of the standard draft, the class
template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
IMO it should be, because typical regex state machines tend
to have a rather large data quantum and I have seen several
use cases, where a factory function returns regex values,
which would take advantage of moveabilities.
</p>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
Needs wording for the semantics, the idea is agreed upon.
</blockquote>

<p><i>[
Post Summit Daniel updated wording to reflect new "swap rules".
]</i></p>


<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
perform the following changes:
</p>

<ol type="a">
<li>
<p>
Just after <tt>basic_regex(const basic_regex&amp;);</tt> insert:
</p>

<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
</pre></blockquote>
</li>
<li>
<p>
Just after <tt>basic_regex&amp; operator=(const basic_regex&amp;);</tt> insert:
</p>
<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
</pre></blockquote>
</li>
<li>
<p>
Just after <tt>basic_regex&amp; assign(const basic_regex&amp; that);</tt> insert:
</p>
<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
</pre></blockquote>
</li>
<li>
<p>
In 28.8.2 [re.regex.construct], just after p.11 add the following
new member definition:
</p>
<blockquote><pre>basic_regex(basic_regex&amp;&amp; e);
</pre>
<blockquote>
<p>
<i>Effects:</i> Move-constructs a <tt>basic_regex</tt> instance from <tt>e</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>e.flags()</tt> and
<tt>e.mark_count()</tt>, respectively,
that <tt>e</tt> had before construction, leaving
<tt>e</tt> in a valid state with an unspecified value.
</p>
<p>
<i>Throws:</i> nothing.
</p>
</blockquote>
</blockquote>
</li>
<li>
<p>
Also in 28.8.2 [re.regex.construct], just after p.18 add the
following new member definition:
</p>

<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp; e);
</pre>
<blockquote>
<i>Effects:</i> Returns the result of <tt>assign(std::move(e))</tt>.
</blockquote>
</blockquote>
</li>
<li>
<p>
In 28.8.3 [re.regex.assign], just after p. 2 add the following new
member definition:
</p>
<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; rhs);
</pre>
<blockquote>
<p>
<i>Effects:</i> Move-assigns a <tt>basic_regex</tt> instance from <tt>rhs</tt> and returns <tt>*this</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>rhs.flags()</tt>
and <tt>rhs.mark_count()</tt>, respectively, that
<tt>rhs</tt> had before assignment, leaving <tt>rhs</tt>
in a valid state with an unspecified value.
</p>
<p>
<i>Throws:</i> nothing.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2007-09-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>DefaultConstructible</tt> requirement is referenced in
several places in the August 2007 working draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
but is not defined anywhere.
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Walking into the default/value-initialization mess...
</p>
<p>
Why two lines? Because we need both expressions to be valid.
</p>
<p>
AJM not sure what the phrase "default constructed" means. This is
unfortunate, as the phrase is already used 24 times in the library!
</p>
<p>
Example: const int would not accept first line, but will accept the second.
</p>
<p>
This is an issue that must be solved by concepts, but we might need to solve it independantly first.
</p>
<p>
It seems that the requirements are the syntax in the proposed first
column is valid, but not clear what semantics we need.
</p>
<p>
A table where there is no post-condition seems odd, but appears to sum up our position best.
</p>
<p>
At a minimum an object is declared and is destuctible.
</p>
<p>
Move to open, as no-one happy to produce wording on the fly.
</p>
</blockquote>

<p><i>[
2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
]</i></p>


<p><i>[
2009-08-17 Daniel adds "[defaultconstructible]" to table title.  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>
depends upon this issue.
]</i></p>


<p><i>[
2009-08-18 Alisdair adds:
]</i></p>


<blockquote>
<p>
Looking at the proposed table in this issue, it really needs two rows:
</p>

<blockquote>
<table border="1">
<caption>Table 33: <tt>DefaultConstructible</tt> requirements [defaultconstructible]</caption>
<tbody><tr>
<th>expression</th><th>post-condition</th>
</tr>

<tr>
<td><tt>T t;</tt></td><td><tt>t</tt> is default-initialized.</td>
</tr>

<tr>
<td><tt>T{}</tt></td><td>Object of type <tt>T</tt> is value-initialized.</td>
</tr>
</tbody></table>
</blockquote>

<p>
Note I am using the new brace-initialization syntax that is unambiguous
in all use cases (no most vexing parse.)
</p>
</blockquote>

<p><i>[
2009-10-03 Daniel adds:
]</i></p>


<blockquote>
<p>
The suggested definition <tt>T{}</tt> describing it as
value-initialization is wrong, because it belongs to list-initialization
which would - as the current rules are - always prefer a
initializer-list constructor over a default-constructor. I don't
consider this as an appropriate definition of
<tt>DefaultConstructible</tt>. My primary suggestion is to ask core,
whether the special case <tt>T{}</tt> (which also easily leads to
ambiguity situations for more than one initializer-list in a class)
would always prefer a default-constructor - if any - before considering
an initializer-list constructor or to provide another syntax form to
prefer value-initialization over list-initialization. If that fails I
would fall back to suggest to use the expression <tt>T()</tt> instead of
<tt>T{}</tt> with all it's disadvantages for the meaning of the
expression
</p>

<blockquote><pre>T t();
</pre></blockquote>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave Open. Core is looking to make Alisdair's proposed
resolution correct.
</blockquote>

<p><i>[
2010-01-24 At Alisdiar's request, moved his proposal into the proposed wording
seciton.  The old wording is preserved here:
]</i></p>


<blockquote>
<p>
In section 20.2.1 [utility.arg.requirements], before table 33, add the
following table:
</p>

<p align="center" style="text-align:center">Table 33: <tt>DefaultConstructible</tt> requirements [defaultconstructible]</p>

<div align="center">

<table border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
 <tbody><tr>
  <td width="114" valign="top" style="width:85.5pt;border-top:solid navy 1.0pt;
  border-left:solid navy 1.0pt;border-bottom:double navy 1.5pt;border-right:
  none;padding:0in 5.4pt 0in 5.4pt">
  <p align="center" style="margin:0in;margin-bottom:.0001pt;text-align:center">expression</p>
  </td>
  <td width="324" valign="top" style="width:243.0pt;border-top:solid navy 1.0pt;
  border-left:none;border-bottom:double navy 1.5pt;border-right:solid navy 1.0pt;
  padding:0in 5.4pt 0in 5.4pt">
  <p align="center" style="margin:0in;margin-bottom:.0001pt;text-align:center">post-condition</p>
  </td>
 </tr>
 <tr>
  <td width="114" valign="top" style="width:85.5pt;border-top:none;border-left:
  solid navy 1.0pt;border-bottom:solid navy 1.0pt;border-right:none;padding:
  0in 5.4pt 0in 5.4pt">
  <p style="margin:0in;margin-bottom:.0001pt"><tt>T
  t;</tt><br>
  <tt>T()</tt></p>
  </td>
  <td width="324" valign="top" style="width:243.0pt;border-top:none;border-left:
  none;border-bottom:solid navy 1.0pt;border-right:solid navy 1.0pt;padding:
  0in 5.4pt 0in 5.4pt">
  <p style="margin:0in;margin-bottom:.0001pt"><tt>T</tt>
  is <i>default constructed.</i></p>
  </td>
 </tr>
</tbody></table>

</div>

</blockquote>

<p><i>[
2010-02-04: Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Rationale:</b></p>
<p><i>[
San Francisco:
]</i></p>

<blockquote>
We believe concepts will solve this problem
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
</blockquote>

<p><i>[
Rationale is obsolete.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
In section 20.2.1 [utility.arg.requirements], before table 33, add the
following table:
</p>

<blockquote>
<table border="1">
<caption>Table 33: <tt>DefaultConstructible</tt> requirements [defaultconstructible]</caption>
<tbody><tr>
<th>expression</th><th>post-condition</th>
</tr>

<tr>
<td><tt>T t;</tt></td><td>Object <tt>t</tt> is default-initialized.</td>
</tr>

<tr>
<td><tt>T u{};</tt></td><td>Object <tt>u</tt> is value-initialized.</td>
</tr>

<tr>
<td><tt>T()<br>T{}</tt></td><td>A temporary object of type <tt>T</tt> is value-initialized.</td>
</tr>

</tbody></table>
</blockquote>






<hr>
<h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
SA&gt;&amp;</tt>.  <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.  This prevents
<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
allocators.
</p>

<p>
Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
SA&gt;&amp;</tt>.  Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
<tt>class ST, class SA</tt> as the first template arguments; compatibility with
existing code using TR1 and giving explicit template arguments to
<tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
arguments.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Bill comments, "We need to look at the depth of this change."
</p>
<p>
Pete remarks that we are here dealing with a convenience function
that saves a user from calling the iterato-based overload.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Howard to ask Stephan Lavavej to provide wording.
</blockquote>

<p><i>[
2009-07-17 Stephan provided wording.
]</i></p>


<p><i>[
2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#726">726</a>.
]</i></p>


<blockquote>
<p>
One relevant part of the proposed resolution below suggests
to add a new overload of the format member function in the
<tt>match_results</tt> class template that accepts two character pointers
defining the <tt>begin</tt> and <tt>end</tt> of a format range. A more general
approach could have proposed a pair of iterators instead, but
the used pair of char pointers reflects existing practice. If the
committee strongly favors an iterator-based signature, this
could be simply changed. I think that the minimum requirement
should be a <tt>BidirectionalIterator</tt>, but current implementations
take advantage (at least partially) of the <tt>RandomAccessIterator</tt>
sub interface of the char pointers.
</p>

<p><b>Suggested Resolution:</b></p>

<p><i>[Moved into the proposed resloution]</i></p>



</blockquote>

<p><i>[
2009-07-30 Stephan agrees with Daniel's wording.  Howard places Daniel's wording
in the Proposed Resolution.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Review. Chair is anxious to move this to Ready in Pittsburgh.
</blockquote>

<p><i>[
2010-01-27 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li>
<p>
Change 28.4 [re.syn] as indicated:
</p>

<blockquote><pre>// 28.11.4, function template regex_replace:
template &lt;class OutputIterator, class BidirectionalIterator,
          class traits, class charT<ins>, class ST, class SA</ins>&gt;
  OutputIterator
  regex_replace(OutputIterator out,
                BidirectionalIterator first, BidirectionalIterator last,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);

<ins>
template &lt;class OutputIterator, class BidirectionalIterator,
          class traits, class charT&gt;
  OutputIterator
  regex_replace(OutputIterator out,
                BidirectionalIterator first, BidirectionalIterator last,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const charT* fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);
</ins>

template &lt;class traits, class charT<ins>, class ST, class SA,
          class FST, class FSA</ins>&gt;
  basic_string&lt;charT<ins>, ST, SA</ins>&gt;
  regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);

<ins>
template &lt;class traits, class charT, class ST, class SA&gt;
  basic_string&lt;charT, ST, SA&gt;
  regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const charT* fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);
</ins>

<ins>
template &lt;class traits, class charT, class ST, class SA&gt;
  basic_string&lt;charT&gt;
  regex_replace(const charT* s,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);
</ins>

<ins>
template &lt;class traits, class charT&gt;
  basic_string&lt;charT&gt;
  regex_replace(const charT* s,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const charT* fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);
</ins>
</pre></blockquote>
</li>

<li>
<p>
Change 28.10 [re.results]/3, class template <tt>match_results</tt> as
indicated:
</p>

<blockquote><pre><ins>
template &lt;class OutputIter&gt;
  OutputIter
  format(OutputIter out,
         const char_type* fmt_first, const char_type* fmt_last,
         regex_constants::match_flag_type flags =
           regex_constants::format_default) const;
</ins>

template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
  OutputIter
  format(OutputIter out,
         const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
         regex_constants::match_flag_type flags =
           regex_constants::format_default) const;

<ins>template &lt;class ST, class SA&gt;</ins>
  <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
  format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
         regex_constants::match_flag_type flags =
           regex_constants::format_default) const;

<ins>
string_type
format(const char_type* fmt,
       regex_constants::match_flag_type flags =
         regex_constants::format_default) const;
</ins>
</pre></blockquote>
</li>

<li>
<p>
Insert at the very beginning of 28.10.5 [re.results.form] the following:
</p>

<blockquote><pre><ins>
template &lt;class OutputIter&gt;
  OutputIter
  format(OutputIter out,
         const char_type* fmt_first, const char_type* fmt_last,
         regex_constants::match_flag_type flags =
           regex_constants::format_default) const;
</ins>
</pre>
<blockquote>

<p><ins>
1 <i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for an
Output Iterator (24.2.4 [output.iterators]).
</ins></p>

<p><ins>
2 <i>Effects:</i> Copies the character sequence <tt>[fmt_first,fmt_last)</tt> to
<tt>OutputIter out</tt>. Replaces each format specifier or escape sequence in
the copied range with either the character(s) it represents or the sequence of
characters within <tt>*this</tt> to which it refers.  The bitmasks specified in
<tt>flags</tt> determine which format specifiers and escape sequences are
recognized.
</ins></p>

<p><ins>
3 <i>Returns:</i> <tt>out</tt>.
</ins></p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 28.10.5 [re.results.form], before p. 1 until p. 3 as indicated:
</p>

<blockquote><pre>template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
  OutputIter
  format(OutputIter out,
         const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
         regex_constants::match_flag_type flags =
           regex_constants::format_default) const;
</pre>

<blockquote>
<p>
<del>1 <i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for
an Output Iterator (24.2.3).</del>
</p>

<p>
2 <i>Effects:</i> <del>Copies the character sequence
<tt>[fmt.begin(),fmt.end())</tt> to <tt>OutputIter out</tt>. Replaces each
format specifier or escape sequence in <tt>fmt</tt> with either the character(s)
it represents or the sequence of characters within <tt>*this</tt> to which it
refers. The bitmasks specified in <tt>flags</tt> determines what format
specifiers and escape sequences are recognized</del> <ins>Equivalent to
<tt>return format(out, fmt.data(), fmt.data() + fmt.size(), flags)</tt></ins>.
</p>

<p>
<del>3 <i>Returns:</i> <tt>out</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 28.10.5 [re.results.form], before p. 4 until p. 4 as indicated:
</p>

<blockquote><pre><ins>template &lt;class ST, class SA&gt;</ins>
  <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
  format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
         regex_constants::match_flag_type flags =
           regex_constants::format_default) const;
</pre>

<blockquote>
<p>
<i>Effects:</i> <del>Returns a copy of the string <tt>fmt</tt>. Replaces each format
specifier or escape sequence
in <tt>fmt</tt> with either the character(s) it represents or the sequence of
characters within <tt>*this</tt> to which
it refers. The bitmasks specified in flags determines what format
specifiers and escape sequences are
recognized.</del> <ins>Constructs an empty string <tt>result</tt> of type
<tt>basic_string&lt;char_type, ST, SA&gt;</tt>,
and calls <tt>format(back_inserter(result), fmt, flags)</tt>.</ins>
</p>

<p>
<ins><i>Returns:</i> <tt>result</tt></ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
At the end of 28.10.5 [re.results.form] insert as indicated:
</p>

<blockquote><pre><ins>
string_type
  format(const char_type* fmt,
         regex_constants::match_flag_type flags =
           regex_constants::format_default) const;
</ins></pre>

<blockquote>
<p>
<ins><i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>string_type</tt>, and calls
<tt>format(back_inserter(result), fmt, fmt +
char_traits&lt;char_type&gt;::length(fmt), flags)</tt>.</ins>
</p>
<p>
<ins><i>Returns:</i> <tt>result</tt></ins>
</p>
</blockquote>
</blockquote>

</li>

<li>
<p>
Change 28.11.4 [re.alg.replace] before p. 1 as indicated:
</p>

<blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
          class traits, class charT<ins>, class ST, class SA</ins>&gt;
  OutputIterator
  regex_replace(OutputIterator out,
                BidirectionalIterator first, BidirectionalIterator last,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);

<ins>
template &lt;class OutputIterator, class BidirectionalIterator,
          class traits, class charT&gt;
  OutputIterator
  regex_replace(OutputIterator out,
                BidirectionalIterator first, BidirectionalIterator last,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const charT* fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);
</ins></pre>

<blockquote>
<i>Effects:</i> [..]. If any matches are found then, for each such match, if <tt>!(flags &amp;
 regex_constants::format_no_copy)</tt> calls <tt>std::copy(m.prefix().first,
m.prefix().second,
 out)</tt>, and then calls <tt>m.format(out, fmt, flags)</tt> <ins>for the first
form of the function
 and <tt>m.format(out, fmt, fmt + char_traits&lt;charT&gt;::length(fmt), flags)</tt>
for the second
 form</ins>. [..].
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 28.11.4 [re.alg.replace] before p. 3 as indicated:
</p>

<blockquote><pre>template &lt;class traits, class charT<ins>, class ST, class SA,
          class FST, class FSA</ins>&gt;
  basic_string&lt;charT<ins>, ST, SA</ins>&gt;
  regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);

<ins>
template &lt;class traits, class charT, class ST, class SA&gt;
  basic_string&lt;charT, ST, SA&gt;
  regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const charT* fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);
</ins></pre>

<blockquote>
<i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>basic_string&lt;charT<ins>,
ST, SA</ins>&gt;</tt>, calls <tt>regex_replace(back_inserter(result), s.begin(), s.end(),
e, fmt, flags)</tt>, and then returns <tt>result</tt>.
</blockquote>
</blockquote>
</li>

<li>
<p>
At the end of 28.11.4 [re.alg.replace] add the following new prototype description:
</p>

<blockquote><pre><ins>
template &lt;class traits, class charT, class ST, class SA&gt;
  basic_string&lt;charT&gt;
  regex_replace(const charT* s,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);
</ins>

<ins>
template &lt;class traits, class charT&gt;
  basic_string&lt;charT&gt;
  regex_replace(const charT* s,
                const basic_regex&lt;charT, traits&gt;&amp; e,
                const charT* fmt,
                regex_constants::match_flag_type flags =
                  regex_constants::match_default);
</ins></pre>

<blockquote>
<ins>
<i>Effects:</i> Constructs an empty string <tt>result</tt> of type <tt>basic_string&lt;charT&gt;</tt>,
calls <tt>regex_replace(back_inserter(result), s, s +
char_traits&lt;charT&gt;::length(s),
e, fmt, flags)</tt>, and then returns <tt>result</tt>.
</ins>
</blockquote>
</blockquote>
</li>

</ol>







<hr>
<h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
<p><b>Section:</b> 26.5.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given 
as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate 
for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in 
which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M. 
Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
[<a href="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
</p>

<p>
I see two possible resolutions: 
</p>

<ol type="a">
<li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the 
multiplier from [the above reference] for the 64-bit case (my preference)</li>
<li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte 
order) and always employ the 32-bit algorithm for seeding
</li>
</ol>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
for further discussion.
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Stephan Tolksdorf has additional comments on N2424. He comments: "there
is a typo in the required behaviour for mt19937_64: It should be the
10000th (not 100000th) invocation whose value is given, and the value
should be 9981545732273789042 (not 14002232017267485025)." These values
need checking.
</p>
<p>
Take the proposed recommendation in N2424 and move to REVIEW.
</p>
</blockquote>




<p><b>Proposed resolution:</b></p>

<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
for the proposed resolution.
</p>

<p><i>[
Stephan Tolksdorf adds pre-Bellevue:
]</i></p>


<blockquote>
I support the proposed resolution in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
but there is a typo in the
required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
100000<sup>th</sup>) invocation whose value is given, and the value should be
9981545732273789042 (not 14002232017267485025). The change to para. 8
proposed by Charles Karney should also be included in the proposed
wording.
</blockquote>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
Note the main part of the issue is resolved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
</blockquote>






<hr>
<h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
<p><b>Section:</b> 26.5.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the 
following two reasons this is an unnecessary restriction: First, in many applications such as 
Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- 
eters as continuous variables. Second, the standard non-naive algorithms (i.e. 
O(1) algorithms) 
for simulating from these distributions work with floating-point parameters anyway (all three 
distributions could be easily implemented using the Gamma distribution, for instance).
</p>

<p>
Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete 
<tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
the implementation would be significantly complicated by a non-discrete parameter (in most 
implementations one would need an approximation of the log-gamma function instead of just the 
log-factorial function).
</p>

<p>
<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters 
to double.
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
In N2424. Not wildly enthusiastic, not really felt necessary. Less
frequently used in practice. Not terribly bad either. Move to OPEN.
</blockquote>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
</p>
<p>
Marc Paterno: Ask implementers whether floating-point is a significant burden.
</p>
<p>
Alisdair: It's neater to do it now, do ask Bill Plauger.
</p>
<p>
Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
for the proposed resolution.
</p>

<p><i>[
Stephan Tolksdorf adds pre-Bellevue:
]</i></p>


<blockquote>
<p>
In 26.5.8.4.3 [rand.dist.norm.chisq]:
</p>

<blockquote>
<p>
Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
</p>

<p>
Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
</p>

<p>
Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
</p>

</blockquote>

<p>
In 26.5.8.4.5 [rand.dist.norm.f]:
</p>
<blockquote>
<p>
Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
</p>

<p>
Replace both occurrences of
</p>
<blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
</pre></blockquote>
<p>
with
</p>
<blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
</pre></blockquote>

<p>
Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
</p>

<p>
Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
</p>
</blockquote>

<p>
In 26.5.8.4.6 [rand.dist.norm.t]:
</p>

<blockquote>
<p>
Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
</p>

<p>
Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
</p>

<p>
Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
</p>
</blockquote>

</blockquote>





<hr>
<h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
<p><b>Section:</b> X [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2007-10-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
<tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
immediately falters on <tt>op--</tt> which can't reliably dereference because we
don't know the lower bound). Also, most buffers you'd want to point to
don't have a compile-time known size.
</p>

<p>
To enable any bounds-checking would require run-time information, with
the usual triplet: base (lower bound), current offset, and max offset
(upper  bound). And I can sympathize with the point of view that you
wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
query the bounds etc., because this sets wrong user expectations by
embarking on a path that doesn't go all the way to bounds checking as it
seems to imply.
</p>

<p>
If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
debug builds and not doing so on release builds (for example).
</p>

<p>
Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
don't agree, but if that were true that would be another reason to
remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
<tt>std::array.</tt> :-)
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Suggestion that fixed-size array instantiations are going to fail at compile time anyway (if we remove specialization) due to pointer decay, at least that appears to be result from available compilers.
</p>
<p>
So concerns about about requiring static_assert seem unfounded.
</p>
<p>
After a little more experimentation with compiler, it appears that fixed size arrays would only work at all if we supply these explicit specialization. So removing them appears less breaking than originally thought.
</p>
<p>
straw poll unanimous move to Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis under 20.9.9 [unique.ptr] p2:
</p>

<blockquote><pre>...
template&lt;class T&gt; struct default_delete; 
template&lt;class T&gt; struct default_delete&lt;T[]&gt;; 
<del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>

template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr; 
template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;; 
<del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
...
</pre></blockquote>

<p>
Remove the entire section  [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
</p>

<p>
Remove the entire section X [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
and its subsections:  [unique.ptr.compiletime.dtor],  [unique.ptr.compiletime.observers],
 [unique.ptr.compiletime.modifiers].
</p>






<hr>
<h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
<tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
</p>

<p>
This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
is example code:
</p>

<blockquote><pre>namespace Mine {

template &lt;class T&gt;
struct proxy {...};

template &lt;class T&gt;
struct proxied_iterator
{
   typedef T value_type;
   typedef proxy&lt;T&gt; reference;
   reference operator*() const;
   ...
};

struct A
{
   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
   void swap(A&amp;);
   ...
};

void swap(A&amp;, A&amp;);
void swap(proxy&lt;A&gt;, A&amp;);
void swap(A&amp;, proxy&lt;A&gt;);
void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);

}  // Mine

...

Mine::proxied_iterator&lt;Mine::A&gt; i(...)
Mine::A a;
<b>swap(*i1, a);</b>
</pre></blockquote>

<p>
The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
same type).  A secondary point is that to support proxies, one must be able to pass rvalues
to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
to take rvalues.
</p>

<p>
That is, no standard library code needs to change.  We simply need to have a more flexible
definition of <tt>Swappable</tt>.
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
While we believe Concepts work will define a swappable concept, we
should still resolve this issue if possible to give guidance to the
Concepts work.
</p>
<p>
Would an ambiguous swap function in two namespaces found by ADL break
this wording? Suggest that the phrase "valid expression" means such a
pair of types would still not be swappable.
</p>
<p>
Motivation is proxy-iterators, but facility is considerably more
general. Are we happy going so far?
</p>
<p>
We think this wording is probably correct and probably an improvement on
what's there in the WP. On the other hand, what's already there in the
WP is awfully complicated. Why do we need the two bullet points? They're
too implementation-centric. They don't add anything to the semantics of
what swap() means, which is there in the post-condition. What's wrong
with saying that types are swappable if you can call swap() and it
satisfies the semantics of swapping?
</p>
</blockquote>

<p><i>[
2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as Open. Dave to provide wording.
</blockquote>

<p><i>[
2009-11-08 Howard adds:
]</i></p>


<blockquote>
Updated wording to sync with
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>.
Also this issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>.
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to <del>NAD Editorial</del><ins>Resolved</ins>.  Rationale added.
</blockquote>



<p><b>Rationale:</b></p>
<p>
Solved by N3048.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.2.1 [utility.arg.requirements]:
</p>

<blockquote>

<p>
-1- The template definitions in the C++ Standard Library refer to various
named requirements whose details are set out in tables 31-38. In these
tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
<tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
</p>

<table border="1">
<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
<tbody><tr><th>expression</th><th>Return type</th><th>Post-condition</th></tr>
<tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
<td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
<del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
<tr><td colspan="3">
<p>
The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
</p>
<ul>
<li>
<tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
the same type and </ins> <tt>T</tt> satisfies the
<tt>MoveConstructible</tt> requirements (Table 
33) and the 
<tt>MoveAssignable</tt> requirements (Table 
35);
</li>
<li>
<tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
<tt>swap</tt> exists in the same namespace as the definition of
<tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
<tt>swap(<del>s</del><ins>w</ins>,<del>t</del> <ins>v</ins>)</tt> is valid and has the
semantics described in this table.
</li>
<li>
<tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose
element type is <tt>Swappable</tt>.
</li>
</ul>
</td></tr>
</tbody></table>
</blockquote>



<p><b>Rationale:</b></p>
<p><i>[
post San Francisco:
]</i></p>


<blockquote>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
</blockquote>






<hr>
<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
<p><b>Section:</b> 20.9.10.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made:
</p>

<blockquote><p>
We may need to open an issue to deal with the question of
whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
</p></blockquote>

<p>
This issue was opened in response to that note.
</p>

<p>
I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
appropriate, and consistent with how other library components are currently specified.
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Concern that the three signatures for swap is needlessly complicated,
but this issue merely brings shared_ptr into equal complexity with the
rest of the library. Will open a new issue for concern about triplicate
signatures.
</p>
<p>
Adopt issue as written.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis in 20.9.10.2 [util.smartptr.shared]:
</p>

<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
...
template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
</pre></blockquote>

<p>
Change 20.9.10.2.4 [util.smartptr.shared.mod]:
</p>

<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
</pre></blockquote>

<p>
Change 20.9.10.2.9 [util.smartptr.shared.spec]:
</p>

<blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
</pre></blockquote>





<hr>
<h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Without some lifetime guarantee, it is hard to know how this type can be
used.  Very specifically, I don't see how the current wording would
guarantee and exception_ptr caught at the end of one thread could be safely
stored and rethrown in another thread - the original motivation for this
API.
</p>
<p>
(Peter Dimov agreed it should be clearer, maybe a non-normative note to
explain?)
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Agree the issue is real.
</p>
<p>
Intent is lifetime is similar to a shared_ptr (and we might even want to
consider explicitly saying that it is a shared_ptr&lt; unspecified type &gt;).
</p>
<p>
We expect that most implementations will use shared_ptr, and the
standard should be clear that the exception_ptr type is intended to be
something whose semantics are smart-pointer-like so that the user does
not need to worry about lifetime management. We still need someone to
draught those words - suggest emailing Peter Dimov.
</p>
<p>
Move to Open.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 18.8.5 [propagation]/7:
</p>

<blockquote>
-7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
handled exception or a copy of the currently handled exception, or a
null <tt>exception_ptr</tt> object if no exception is being handled.
<ins>The referenced object remains valid at least as long as there is an
<tt>exception_ptr</tt> that refers to it.</ins>
If the function needs to allocate memory and the attempt
fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
<tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
each time it is called. <i>--end note</i>]
</blockquote>





<hr>
<h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I understand that the attempt to copy an exception may run out of memory,
but I believe this is the only part of the standard that mandates failure
with specifically <tt>bad_alloc</tt>, as opposed to allowing an
implementation-defined type derived from <tt>bad_alloc</tt>.  For instance, the Core
language for a failed new expression is:
</p>
<blockquote>
<p>
Any other allocation function that fails to allocate storage shall indicate
failure only by throwing an exception of a type that would match a handler
(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
</p>
</blockquote>
<p>
I think we should allow similar freedom here (or add a blanket
compatible-exception freedom paragraph in 17)
</p>
<p>
I prefer the clause 17 approach myself, and maybe clean up any outstanding
wording that could also rely on it.
</p>
<p>
Although filed against a specific case, this issue is a problem throughout
the library. 
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Is issue bigger than library?
</p>
<p>
No - Core are already very clear about their wording, which is inspiration for the issue.
</p>
<p>
While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
</p>
<p>
Accept the broad view and move to ready
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Add the following exemption clause to 17.6.4.12 [res.on.exception.handling]:
</p>

<blockquote>
A function may throw a type not listed in its <i>Throws</i> clause so long as it is
derived from a class named in the <i>Throws</i> clause, and would be caught by an
exception handler for the base type.
</blockquote>





<hr>
<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor&lt;T&gt;::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
<p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Unfortunately a class can have multiple copy constructors, and I believe to
be useful this trait should only return true is ALL copy constructors are
no-throw.
</p>
<p>
For instance:
</p>
<blockquote>
<pre>struct awkward {
 awkward( const awkward &amp; ) throw() {}
 awkward( awkward &amp; ) { throw "oops"; } };
</pre>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.7.4.3 [meta.unary.prop]:
</p>

<blockquote>
<pre>has_trivial_copy_constructor</pre>
<blockquote>
<tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
<ins>where all copy constructors are trivial</ins> (12.8).
</blockquote>
</blockquote>

<blockquote>
<pre>has_trivial_assign</pre>
<blockquote>
<tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
</blockquote>
</blockquote>

<blockquote>
<pre>has_nothrow_copy_constructor</pre>
<blockquote>
<tt>has_trivial_copy_constructor&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins> 
known not to throw any exceptions or <tt>T</tt> is an
array of such a class type
</blockquote>
</blockquote>

<blockquote>
<pre>has_nothrow_assign</pre>
<blockquote>
<tt>T</tt> is neither <tt>const</tt> nor a reference type, and
<tt>has_trivial_assign&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
<ins>where all</ins> copy
assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
throw any exceptions or <tt>T</tt> is an array of such a class type.
</blockquote>
</blockquote>






<hr>
<h3><a name="752"></a>752. Allocator complexity requirement</h3>
<p><b>Section:</b> 20.2.5 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2007-10-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Did LWG recently discuss 20.2.5 [allocator.requirements]-2, which states that "All the operations
on the allocators are expected to be amortized constant time."?
</p>
<p>
As I think I pointed out earlier, this is currently fiction for
<tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
large objects.  Would it be controversial to officially let these take
time linear in the size of the object, as they already do in real life?
</p>
<p>
<tt>Allocate()</tt> more blatantly takes time proportional to the size of the
object if you mix in GC.  But it's not really a new problem, and I think
we'd be confusing things by leaving the bogus requirements there.  The
current requirement on <tt>allocate()</tt> is generally not important anyway,
since it takes O(size) to construct objects in the resulting space.
There are real performance issues here, but they're all concerned with
the constants, not the asymptotic complexity.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.2.5 [allocator.requirements]/2:
</p>

<blockquote>
<p>
-2- Table 39 describes the requirements on types manipulated through
allocators. <del>All the operations on the allocators are expected to be
amortized constant time.</del> Table 40 describes the
requirements on allocator types.
</p>
</blockquote>





<hr>
<h3><a name="753"></a>753. Move constructor in draft</h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2007-10-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The draft standard n2369 uses the term <i>move constructor</i> in a few
places, but doesn't seem to define it.
</p>

<p>
<tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.2.1 [utility.arg.requirements] as
follows:
</p>

<blockquote>
<table border="1">
<caption><tt>MoveConstructible</tt> requirements</caption>
<tbody><tr>
<th>expression</th> <th>post-condition</th>
</tr>
<tr>
<td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
</tr>
<tr>
<td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the 
construction. <i>-- end note</i>]</td>
</tr>
</tbody></table>
</blockquote>

<p>
(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
</p>

<p>
So I assume the move constructor is the constructor that would be used
in filling the above requirement.
</p>

<p>
For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
23.4.1.4 [vector.modifiers] we have
</p>

<blockquote>
<i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
not throw any exceptions.
</blockquote>

<p>
Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
type which can be put into a <tt>vector</tt> has a move constructor (a copy
constructor is also a move constructor). Secondly it means that for
any <tt>value_type</tt> which has a throwing copy constructor and no other move
constructor these functions cannot be used -- which I think will come
as a shock to people who have been using such types in <tt>vector</tt> until
now!
</p>

<p>
I can see two ways to correct this. The simpler, which is presumably
what was intended, is to say "If <tt>value_type</tt> has a move constructor and
no copy constructor, the move constructor shall not throw any
exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
value of its parameter,".
</p>

<p>
The other alternative is add to <tt>MoveConstructible</tt> the requirement that
the expression does not throw. This would mean that not every type
that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
<tt>MoveConstructible</tt> requirements. It would mean changing requirements in
various places in the draft to allow either <tt>MoveConstructible</tt> or
<tt>CopyConstructible</tt>, but I think the result would be clearer and
possibly more concise too.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add new defintions to 17.3 [definitions]:
</p>

<blockquote>
<p>
<b>move constructor</b>
</p>
<p>
a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
side effect during the construction.
</p>
<p>
<b>move assignment operator</b>
</p>
<p>
an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
side effect during the assignment.
</p>
<p>
<b>move assignment</b>
</p>
<p>
use of the move assignment operator.
</p>
</blockquote>

<p><i>[
Howard adds post-Bellevue:
]</i></p>


<blockquote>
<p>
Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect.  <tt>reserve</tt> et. al. will use a move constructor
if one is available, else it will use a copy constructor.  A type may have both.  If the move constructor is
used, it must not throw.  If the copy constructor is used, it can throw.  The sentence in the proposed wording
is correct without the recommended insertion.  The Bellevue LWG recommended moving this issue to Ready.  I am
unfortunately pulling it back to Open.  But I'm drafting wording to atone for this egregious action. :-)
</p>
</blockquote>






<hr>
<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
<p><b>Section:</b> 23.4.1.2 [vector.capacity], 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
</p>

<blockquote><pre>vector&lt;int&gt; v;
...
v.swap(vector&lt;int&gt;(v));  // shrink to fit
</pre>
<blockquote><p>
or:
</p></blockquote>
<pre>vector&lt;int&gt;(v).swap(v);  // shrink to fit
</pre>
<blockquote><p>
or:
</p></blockquote>
<pre>swap(v, vector&lt;int&gt;(v));  // shrink to fit
</pre>
</blockquote>

<p>
A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
</p>

<blockquote><pre>string s;
...
s.reserve(0);
</pre></blockquote>

<p>
Neither of these is at all obvious to beginners, and even some
experienced C++ programmers are not aware that shrink-to-fit is
trivially available.
</p>
<p>
Lack of explicit functions to perform these commonly requested
operations makes vector and string less usable for non-experts. Because
the idioms are somewhat obscure, code readability is impaired. It is
also unfortunate that two similar vector-like containers use different
syntax for the same operation.
</p>
<p>
The proposed resolution addresses these concerns. The proposed function
takes no arguments to keep the solution simple and focused.
</p>


<p><b>Proposed resolution:</b></p>
<p>
To Class template basic_string 21.4 [basic.string] synopsis,
Class template vector 23.4.1 [vector] synopsis, and Class
vector&lt;bool&gt; 23.4.2 [vector.bool] synopsis, add:
</p>

<blockquote><pre>    
void shrink_to_fit();
</pre></blockquote>

<p>
To basic_string capacity 21.4.4 [string.capacity] and vector
capacity 23.4.1.2 [vector.capacity], add:
</p>

<blockquote>
<pre>void shrink_to_fit();
</pre>
<blockquote>
<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
allow latitude for implementation-specific optimizations.
<i>-- end note</i>]
</blockquote>
</blockquote>

<p><i>[
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>.
]</i></p>






<hr>
<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
<p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following program:
</p>

<blockquote><pre>int main() {
   shared_ptr&lt;int&gt; p(nullptr); 
   return 0;
}
</pre></blockquote>

<p>
This program will fail to compile because <tt>shared_ptr</tt> uses the following 
template constructor to construct itself from pointers:
</p>

<blockquote><pre>template &lt;class Y&gt; shared_ptr(Y *);
</pre></blockquote>

<p>
According
to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
deducible, so the above constructor will not be found.  There are similar problems with the
constructors that take a pointer and a <tt>deleter</tt> or a
pointer, a <tt>deleter</tt> and an allocator, as well as the
corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
<tt>deleters</tt> or allocators or for <tt>reset()</tt>.
</p>

<p>
In the case of the functions that take deleters, there is the additional
question of what argument should be passed to the deleter when it is
eventually called.  There are two reasonable possibilities: <tt>nullptr</tt> or
<tt>static_cast&lt;T *&gt;(0)</tt>, where <tt>T</tt> is the template argument of the
<tt>shared_ptr</tt>.  It is not immediately clear which of these is better.  If
<tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
constructor, then <tt>d(static_cast&lt;T*&gt;(0))</tt> will compile and <tt>d(nullptr)</tt>
will not.  On the other hand, if <tt>D::operator()()</tt> takes a parameter that
is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast&lt;T *&gt;(0))</tt> may not.
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
The general idea is right, we need to be able to pass a nullptr to a
shared_ptr, but there are a few borderline editorial issues here. (For
example, the single-argument nullptr_t constructor in the class synopsis
isn't marked explicit, but it is marked explicit in the proposed wording
for 20.6.6.2.1. There is a missing empty parenthesis in the form that
takes a nullptr_t, a deleter, and an allocator.)
</p>
<p>
More seriously: this issue says that a shared_ptr constructed from a
nullptr is empty. Since "empty" is undefined, it's hard to know whether
that's right. This issue is pending on handling that term better.
</p>
<p>
Peter suggests definition of empty should be "does not own anything"
</p>
<p>
Is there an editorial issue that post-conditions should refer to get() =
nullptr, rather than get() = 0?
</p>
<p>
No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
</p>
<p>
Seems there are no technical merits between NAD and Ready, comes down to
"Do we intentially want to allow/disallow null pointers with these
functions". Staw Poll - support null pointers 5 - No null pointers 0
</p>
<p>
Move to Ready, modulo editorial comments
</p>
</blockquote>

<p><i>[
post Bellevue Peter adds:
]</i></p>


<blockquote>
<p>
The following wording changes are less intrusive:
</p>

<p>
In 20.9.10.2.1 [util.smartptr.shared.const], add:
</p>

<blockquote><pre>shared_ptr(nullptr_t);
</pre></blockquote>

<p>
after:
</p>

<blockquote><pre>shared_ptr();
</pre></blockquote>

<p>
(Absence of explicit intentional.)
</p>

<p>
<tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
I'm not convinced of its utility.
</p>
<p>
It's similarly not clear to me whether the deleter constructors need to be
extended to take <tt>nullptr</tt>, but if they need to:
</p>
<p>
Add
</p>

<blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
</pre></blockquote>

<p>
after
</p>

<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
</pre></blockquote>

<p>
Note that this changes the semantics of the new constructors such that they
consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
</p>
<p>
The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
has repeatedly been requested by users, but the other additions that the
proposed resolution makes are not supported by real world demand or
motivating examples.
</p>
<p>
It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
constructor into a separate issue. Waiting for "empty" to be clarified is
unnecessary; this is effectively an alias for the default constructor.
</p>
</blockquote>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
We want to remove the reset functions from the proposed resolution.
</p>
<p>
The remaining proposed resolution text (addressing the constructors) are wanted.
</p>
<p>
Disposition: move to review. The review should check the wording in the then-current working draft.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In 20.9.10.2 [util.smartptr.shared] p4, add to the definition/synopsis
of <tt>shared_ptr</tt>:
</p>

<blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
</pre></blockquote>

<p>
after
</p>

<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
</pre></blockquote>

<p>
In 20.9.10.2.1 [util.smartptr.shared.const] add:
</p>

<blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
</pre></blockquote>

<p>
after
</p>

<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
</pre></blockquote>

<p>
(reusing the following paragraphs 20.9.10.2.1 [util.smartptr.shared.const]/9-13 that speak of p.)
</p>

<p>
In 20.9.10.2.1 [util.smartptr.shared.const]/10,  change
</p>

<blockquote>
<i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that <i>owns</i> the
<del>pointer</del> <ins>object</ins> <tt>p</tt> and the deleter <tt>d</tt>. The second 
constructor shall use a copy of <tt>a</tt> to allocate memory for internal use.
</blockquote>


<p><b>Rationale:</b></p>
<p><i>[
San Francisco:
]</i></p>


<blockquote>
"pointer" is changed to "object" to handle the fact that nullptr_t isn't a pointer.
</blockquote>






<hr>
<h3><a name="759"></a>759. A reference is not an object</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-11-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.2 [container.requirements] says:
</p>

<blockquote>
-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
diagnostic required.
</blockquote>

<p>
A reference is not an object, but this sentence appears to claim so.
</p>

<p>
What is probably meant here:
</p>
<blockquote>
An object bound to an rvalue
reference parameter of a member function of a container shall not be
an element of that container; no diagnostic required.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 23.2 [container.requirements]:
</p>

<blockquote>
-12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
<ins>An object bound to an rvalue
reference parameter of a member function of a container shall not be
an element</ins>
of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o 
diagnostic required.
</blockquote>






<hr>
<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
<p><b>Section:</b> 23.7.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>.  It acts 
like <tt>operator[]()</tt>, except it throws an exception when the input key is 
not found.  It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the 
key doesn't have  a default constructor, it is an error if the key is 
not found, or the user wants to avoid accidentally adding an element to 
the map.  For exactly these same reasons, <tt>at()</tt> would be equally useful 
in <tt>std::unordered_map</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.7.1 [unord.map]):
</p>

<blockquote><pre>mapped_type&amp; at(const key_type&amp; k);
const mapped_type &amp;at(const key_type &amp;k) const;
</pre></blockquote>

<p>
Add the following definitions to 23.7.1.2 [unord.map.elem]:
</p>

<blockquote>
<pre>mapped_type&amp; at(const key_type&amp; k);
const mapped_type &amp;at(const key_type &amp;k) const;
</pre>
<blockquote>
<p>
<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element 
whose key is equivalent to <tt>k</tt>.
</p>
<p>
<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element 
is present.
</p>
</blockquote>
</blockquote>

<p><i>[
Bellevue:  Editorial note: the "(unique)" differs from map.
]</i></p>







<hr>
<h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
<p><b>Section:</b> 20.9.9 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-11-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
does currently not support incomplete types, because it
gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
an incomplete pointee type <tt>T</tt> automatically belongs to
undefined behaviour according to 17.6.3.8 [res.on.functions]/2, last
bullet. This is an unnecessary restriction and prevents
many well-established patterns - like the bridge pattern -
for <tt>std::unique_ptr</tt>.
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
Move to open. The LWG is comfortable with the intent of allowing
incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
not comfortable with the wording. The specification for <tt>unique_ptr</tt>
should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
member functions, which ones require their types to be complete. The
<tt>shared_ptr</tt> specification is careful to say that for each function, and
we need the same level of care here. We also aren't comfortable with the
"part of the operational semantic" language; it's not used elsewhere in
the standard, and it's not clear what it means. We need a volunteer to
produce new wording.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
The proposed changes in the following revision refers to the current state of
N2521 including the assumption that X [unique.ptr.compiletime] will be removed
according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
</p>
<p>
The specialization <tt>unique_ptr&lt;T[]&gt;</tt> has some more restrictive constraints on
type-completeness on <tt>T</tt> than <tt>unique_ptr&lt;T&gt;</tt>. The following proposed wordings
try to cope with that. If the committee sees less usefulness on relaxed
constraints on <tt>unique_ptr&lt;T[]&gt;</tt>, the alternative would be to stop this relaxation
e.g. by adding one further bullet to 20.9.9.3 [unique.ptr.runtime]/1:
"<tt>T</tt> shall be a complete type, if used as template argument of
<tt>unique_ptr&lt;T[], D&gt;</tt>
</p>
<p>
This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any
problems with this one,
because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
with the here discussed
ones, provided that <tt>D::pointer</tt>'s operations (including default
construction, copy construction/assignment,
and pointer conversion) are specified <em>not</em> to throw, otherwise this
would have impact on the
current specification of <tt>unique_ptr</tt>.
</p>

<ol>
<li>
<p>
In 20.9.9 [unique.ptr]/2 add as the last sentence to the existing para:
</p>

<blockquote>
The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
<tt>unique_ptr</tt> owns the object it holds a pointer to. A
<tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
<tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
<tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
<tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
uses of <tt>unique_ptr</tt> include providing exception safety for
dynamically allcoated memory, passing ownership of dynamically allocated
memory to a function, and returning dynamically allocated memory from a
function. -- <i>end note</i> ]
</blockquote>
</li>

<li>
<p>
20.9.9.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
</p>

<blockquote>
<p><i>[
N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
The current wording says just this.
]</i></p>

</blockquote>
</li>

<li>
<p>
In 20.9.9.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
</p>

<blockquote>
<p>
<i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
of <tt>D</tt> shall not throw an exception.</del>
<del><tt>D</tt> must not be a reference type.</del>
<ins>
<tt>D</tt> shall be default constructible, and that construction
shall not throw an exception.
</ins>
</p>
<p><i>[
N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
this point. I assume that the current wording is based on the
corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
requirement is necessary, because the corresponding c'tor *can* fail
and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
this regard. The *only* functions that must insist on well-formedness
and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
invocation of
<tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
we do *not* need the
requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
<tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
potentially requires <tt>Convertible&lt;Y*, X*&gt;</tt>, which
again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</tt>
]</i></p>

</blockquote>
</li>

<li>
<p>
Merge 20.9.9.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
of 12, but transferring the "requires" to 13:
</p>

<blockquote>
<p>
<i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
</p>
<p><i>[
N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
well-formed/well-defined at this point. The current wording guarantees
all what we need, namely that the initialization of both the <tt>T*</tt>
pointer and the <tt>D</tt> deleter are well-formed and well-defined.
]</i></p>

</blockquote>
</li>

<li>
20.9.9.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
</li>
<li>
<p>20.9.9.2.1 [unique.ptr.single.ctor]/21:</p>

<blockquote>
<i>Requires:</i> If <tt>D</tt> is not a reference type, construction of
the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well
formed and shall not throw an exception. If <tt>D</tt> is a reference
type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
be complete types. <i>-- end note</i>]</ins>
</blockquote>

<p><i>[
N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt> is
true. If the committee wishes this explicit requirement can be added,
e.g. "<tt>U</tt> shall be a complete type."
]</i></p>

</li>

<li>
<p>
20.9.9.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
</p>
<blockquote>
<p>
<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
shall have well-defined behavior, and shall not throw exceptions.
<ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
be a complete type. <i>-- end note</i>]</ins>
</p>
<p><i>[
N.B.: This requirement ensures that the whole responsibility on
type-completeness of <tt>T</tt> is delegated to this expression.
]</i></p>

</blockquote>
</li>

<li>
<p>
20.9.9.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
current editorial issue, that "must shall" has to be changed to
"shall", but this change is not a special part of this resolution.
</p>

<p><i>[
N.B. The current wording is sufficient, because we can delegate all
further requirements on the requirements of the effects clause
]</i></p>

</li>

<li>
<p>
20.9.9.2.3 [unique.ptr.single.asgn]/6:
</p>

<blockquote>
<i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
<tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
convertible to <tt>T*</tt>.
<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
be complete types. <i>-- end note</i>]</ins>
</blockquote>

<p><i>[
N.B.: The current wording of p. 6 already implicitly guarantees that
<tt>U</tt> is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt>
is true, see (6)+(8).
]</i></p>

</li>

<li>
<p>
20.9.9.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
</p>
<p><i>[
N.B.: Delegation to requirements of effects clause is sufficient.
]</i></p>

</li>

<li>
20.9.9.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
</li>

<blockquote>
<pre>T* operator-&gt;() const;</pre>
<blockquote>
<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
</blockquote>
</blockquote>

<li>
20.9.9.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
</li>

<li>
<p>
20.9.9.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
</p>
<blockquote>
<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
shall have well-defined behavior, and shall not throw exceptions.
</blockquote>
</li>

<li>
20.9.9.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
</li>

<li>
<p>
20.9.9.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
</p>

<blockquote>
<p>
A specialization for array types is provided with a slightly altered interface.
</p>

<ul>
<li>
...
</li>
<li>
<ins><tt>T</tt> shall be a complete type.</ins>
</li>
</ul>
</blockquote>
</li>
</ol>

<p><i>[
post Bellevue: Daniel provided revised wording.
]</i></p>







<hr>
<h3><a name="765"></a>765. more on iterator validity</h3>
<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-12-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
       <p>

Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
defines the meaning of the term "invalid iterator" as one that may be
singular.

       </p>
       <p>

Consider the following code:

       </p>
       <pre>   std::deque&lt;int&gt; x, y;
   std::deque&lt;int&gt;::iterator i = x.end(), j = y.end();
   x.swap(y);
       </pre>
       <p>

Given that <code>swap()</code> is required not to invalidate iterators
and using the definition above, what should be the expected result of
comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
and <code>y.end()</code>, respectively, after the <code>swap()</code>?

       </p>
       <p>

I.e., is the expression below required to evaluate
to <code>true</code>?

       </p>
       <pre>   i == y.end() &amp;&amp; j == x.end()
       </pre>
       <p>

(There are at least two implementations where the expression
returns <code>false</code>.)

       </p>
       <p>

More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to
make any guarantees about whether iterators actually point to the same
elements or be associated with the same containers after a
non-invalidating operation as they did before?

       </p>
       <p>

Here's a motivating example intended to demonstrate the importance of
the question:

       </p>
       <pre>   Container x, y ({ 1, 2});   // pseudocode to initialize y with { 1, 2 }
   Container::iterator i = y.begin() + 1;
   Container::iterator j = y.end();
   std::swap(x, y);
   std::find(i, j, 3);
       </pre>
       <p>

<code>swap()</code> guarantees that <code>i</code> and <code>j</code>
continue to be valid. Unless the spec says that even though they are
valid they may no longer denote a valid range the code above must be
well-defined. Expert opinions on this differ as does the behavior of
popular implementations for some standard <code>Containers</code>.

       </p>
<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Pablo: add a note to the last bullet of paragraph 11 of 23.1.1 clarifying that the end() iterator doesn't refer to an element and that it can therefore be invalidated.
</p>
<p>
Proposed wording:
</p>
<blockquote>
[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element and can
therefore be invalidated. <i>-- end note</i>]
</blockquote>
<p>
Howard will add this proposed wording to the issue and then move it to Review.
</p>
</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Lawrence: suggestion: "Note: The <tt>end()</tt> iterator does not refer to any element"
</p>
<p>
Walter: "Note: The <tt>end()</tt> iterator can nevertheless be invalidated,
because it does not refer to any element."
</p>
<p>
Nick: "The <tt>end()</tt> iterator does not refer to any element. It is therefore
subject to being invalidated."
</p>
<p>
Consensus: go with Nick
</p>
<p>
With that update, Recommend Tentatively Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add to 23.2.1 [container.requirements.general], p11:
</p>

<blockquote>
<p>
Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
23.2.6.4) all container types defined in this Clause meet the following
additional requirements:
</p>
<ul>
<li>...</li>
<li>
no <tt>swap()</tt> function invalidates any references, pointers, or
iterators referring to the elements of the containers being swapped.
<ins>[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element. It is therefore
subject to being invalidated. <i>-- end note</i>]</ins>
</li>
</ul>
</blockquote>





<hr>
<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
<p><b>Section:</b> 23.2 [container.requirements], 23.2.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Ion Gazta�aga <b>Opened:</b> 2007-12-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.2 [container.requirements]p10 states:
</p>

<blockquote>
<p>
Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
additional requirements:
</p>
<ul>

<li>[...]</li>

<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>

</ul>
</blockquote>

<p>
23.3.2.3 [deque.modifiers] and 23.4.1.4 [vector.modifiers] offer
additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
<tt>erase()</tt> members. However, 23.2 [container.requirements]p10 does not mention 23.2.5.1 [unord.req.except] that specifies exception safety guarantees
for unordered containers. In addition,  23.2.5.1 [unord.req.except]p1 offers the following guaratee for
<tt>erase()</tt>:
</p>

<blockquote>
No <tt>erase()</tt> function throws an exception unless that exception
is thrown by the container's Hash or Pred object (if any).
</blockquote>

<p>
Summary:
</p>

<p>
According to 23.2 [container.requirements]p10 no
<tt>erase()</tt> function should throw an exception unless otherwise
specified. Although does not explicitly mention 23.2.5.1 [unord.req.except], this section offers additional guarantees
for unordered containers, allowing <tt>erase()</tt> to throw if
predicate or hash function throws.
</p>

<p>
In contrast, associative containers have no exception safety guarantees
section so no <tt>erase()</tt> function should throw, <em>including
<tt>erase(k)</tt></em> that needs to use the predicate function to
perform its work. This means that the predicate of an associative
container is not allowed to throw.
</p>

<p>
So:
</p>

<ol>
<li>
<tt>erase(k)</tt> for associative containers is not allowed to throw. On
the other hand, <tt>erase(k)</tt> for unordered associative containers
is allowed to throw.
</li>
<li>
<tt>erase(q)</tt> for associative containers is not allowed to throw. On
the other hand, <tt>erase(q)</tt> for unordered associative containers
is allowed to throw if it uses the hash or predicate.
</li>
<li>
To fulfill 1), predicates of associative containers are not allowed to throw.
Predicates of unordered associative containers are allowed to throw.
</li>
<li>
2) breaks a widely used programming pattern (flyweight pattern) for
unordered containers, where objects are registered in a global map in
their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
allowed to throw, the destructor of the object would need to rethrow the
exception or swallow it, leaving the object registered.
</li>
</ol>


<p><b>Proposed resolution:</b></p>
<p>
Create a new sub-section of 23.2.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
safety guarantees".
</p>

<blockquote>
<p>
1 For associative containers, no <tt>clear()</tt> function throws an exception.
<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
the container's Pred object (if any).
</p>

<p>
2 For associative containers, if an exception is thrown by any operation
from within an <tt>insert()</tt> function inserting a single element, the
<tt>insert()</tt> function has no effect.
</p>

<p>
3 For associative containers, no <tt>swap</tt> function throws an exception
unless that exception is thrown by the copy constructor or copy
assignment operator of the container's Pred object (if any).
</p>
</blockquote>

<p>
Change 23.2.5.1 [unord.req.except]p1:
</p>

<blockquote>
For unordered associative containers, no <tt>clear()</tt> function
throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
<del>function</del> <ins>does not</ins> throw<del>s</del> an exception
unless that exception is thrown by the container's Hash or Pred object
(if any).
</blockquote>

<p>
Change 23.2 [container.requirements]p10 to add references to new sections:
</p>

<blockquote>
Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
<del>and</del> [vector.modifiers]<ins>, [associative.req.except],
[unord.req.except]</ins>) all container types defined in this clause meet
the following additional requirements:
</blockquote>

<p>
Change 23.2 [container.requirements]p10 referring to <tt>swap</tt>:
</p>

<blockquote>
<ul>
<li>
no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
by the copy constructor or assignment operator of the container's
Compare object (if any; see [associative.reqmts])</del>.
</li>
</ul>
</blockquote>






<hr>
<h3><a name="768"></a>768. Typos in [atomics]?</h3>
<p><b>Section:</b> 29.5 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2007-12-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
in the latest publicly available draft, paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
in section 29.5 [atomics.types.generic], the following specialization of the template
<tt>atomic&lt;&gt;</tt> is provided for pointers:
</p>

<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 

  atomic() = default; 
  constexpr explicit atomic(T); 
  atomic(const atomic&amp;) = delete; 
  atomic&amp; operator=(const atomic&amp;) = delete; 

  T* operator=(T*) volatile; 
  T* operator++(int) volatile; 
  T* operator--(int) volatile; 
  T* operator++() volatile; 
  T* operator--() volatile; 
  T* operator+=(ptrdiff_t) volatile;
  T* operator-=(ptrdiff_t) volatile; 
};
</pre></blockquote>

<p>
First of all, there is a typo in the non-default constructor which
should take a <tt>T*</tt> rather than a <tt>T</tt>.
</p>

<p>
As you can see, the specialization redefine and therefore hide a few
methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
to the other methods, in particular these ones:
</p>

<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
T* load( memory_order = memory_order_seq_cst ) volatile;
T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;
bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;
</pre></blockquote>

<p>
By reading paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
I see that the
definition of the specialization <tt>atomic&lt;T*&gt;</tt> matches the one in the
draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
and <tt>compare_swap()</tt> are indeed present.
</p>

<p>
Strangely, the example implementation does not redefine the method
<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
hiding the <tt>void*</tt> signature from the base class makes the class
error-prone to say the least: it lets you assign pointers of any type to
a <tt>T*</tt>, without any hint from the compiler.
</p>

<p>
Is there a true intent to remove them from the specialization or are
they just missing from the definition because of a mistake?
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
The proposed revisions are accepted.
</p>
<p>
Further discussion: why is the ctor labeled "constexpr"? Lawrence said
this permits the object to be statically initialized, and that's
important because otherwise there would be a race condition on
initialization.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis in 29.5 [atomics.types.generic]:
</p>

<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
  <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
  <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
  <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
  <ins>bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;</ins>
  <ins>bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;</ins>

  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 

  atomic() = default; 
  constexpr explicit atomic(T<ins>*</ins>); 
  atomic(const atomic&amp;) = delete; 
  atomic&amp; operator=(const atomic&amp;) = delete; 

  T* operator=(T*) volatile; 
  T* operator++(int) volatile; 
  T* operator--(int) volatile; 
  T* operator++() volatile; 
  T* operator--() volatile; 
  T* operator+=(ptrdiff_t) volatile;
  T* operator-=(ptrdiff_t) volatile; 
};
</pre></blockquote>






<hr>
<h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
<p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
N2461 already replaced in 20.8.14.2 [func.wrap.func] it's originally proposed
(implicit) conversion operator to "unspecified-bool-type" by the new
explicit bool conversion, but the inverse conversion should also
use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
type".
</p>


<p><b>Proposed resolution:</b></p>

<p>
In 20.8 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
</p>

<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
template&lt;class R, class... ArgTypes&gt;
  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
template&lt;class R, class... ArgTypes&gt;
  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
template&lt;class R, class... ArgTypes&gt;
  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
</pre></blockquote>

<p>
In the class function synopsis of 20.8.14.2 [func.wrap.func] replace
</p>

<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
...
function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
</pre></blockquote>

<p>
In 20.8.14.2 [func.wrap.func], "Null pointer comparisons" replace:
</p>

<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
template &lt;class R, class... ArgTypes&gt;
  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
template &lt;class R, class... ArgTypes&gt;
  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
template &lt;class R, class... ArgTypes&gt;
  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
</pre></blockquote>

<p>
In 20.8.14.2.1 [func.wrap.func.con], replace
</p>

<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
...
function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
</pre></blockquote>

<p>
In 20.8.14.2.6 [func.wrap.func.nullptr], replace
</p>

<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
template &lt;class R, class... ArgTypes&gt;
  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
</pre></blockquote>

<p>
and replace
</p>

<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
template &lt;class R, class... ArgTypes&gt;
  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
</pre></blockquote>






<hr>
<h3><a name="770"></a>770. std::function should use rvalue swap</h3>
<p><b>Section:</b> 20.8.14 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is expected that typical implementations of <tt>std::function</tt> will
use dynamic memory allocations at least under given conditions,
so it seems appropriate to change the current lvalue swappabilty of
this class to rvalue swappability.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 20.8 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis, just below of
</p>

<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
<ins>template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
</pre></blockquote>

<p>
In 20.8.14.2 [func.wrap.func] class <tt>function</tt> definition, change
</p>

<blockquote><pre>void swap(function&amp;<ins>&amp;</ins>);
</pre></blockquote>

<p>
In 20.8.14.2 [func.wrap.func], just below of
</p>

<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
<ins>template &lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
template &lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
</pre></blockquote>

<p>
In 20.8.14.2.2 [func.wrap.func.mod] change
</p>

<blockquote><pre>void swap(function&amp;<ins>&amp;</ins> other);
</pre></blockquote>

<p>
In 20.8.14.2.7 [func.wrap.func.alg] add the two overloads
</p>

<blockquote><pre><ins>template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</ins>
</pre></blockquote>






<hr>
<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
<p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.5 [string.conversions]
have throws clauses (paragraphs 8 and 16) which say:
</p>

<blockquote>
<i>Throws:</i> nothing
</blockquote>

<p>
Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
constructors can fail due to out-of-memory conditions. Either these throws
clauses should be removed or should be more detailled like:
</p>

<blockquote>
<i>Throws:</i> Nothing if the string construction throws nothing
</blockquote>

<p>
Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
header <tt>&lt;string&gt;</tt> synopsis of 21.3 [string.classes] is correct in this
regard).
</p>



<p><b>Proposed resolution:</b></p>
<p>
In 21.5 [string.conversions], remove the paragraphs 8 and 16.
</p>

<blockquote>
<pre>string to_string(long long val); 
string to_string(unsigned long long val); 
string to_string(long double val); 
</pre>
<blockquote>
<del><i>Throws:</i> nothing</del>
</blockquote>
</blockquote>

<blockquote>
<pre><ins>w</ins>string to_wstring(long long val); 
<ins>w</ins>string to_wstring(unsigned long long val); 
<ins>w</ins>string to_wstring(long double val); 
</pre>
<blockquote>
<del><i>Throws:</i> nothing</del>
</blockquote>
</blockquote>






<hr>
<h3><a name="772"></a>772.  Impossible return clause in [string.conversions]</h3>
<p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The return clause 21.5 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
overloads says:
</p>

<blockquote>
<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
representation of the value of its argument that would be generated by
calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
or <tt>L"%f"</tt>, respectively.
</blockquote>

<p>
Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
the 2nd edition of ISO 9899, and the first and the second corrigenda from
2001-09-01 and 2004-11-15). What probably meant here is the function
<tt>swprintf</tt> from <tt>&lt;wchar.h&gt;/&lt;cwchar&gt;</tt>, but this has the non-equivalent
declaration:
</p>

<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
const wchar_t * restrict format, ...);
</pre></blockquote>

<p>
therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change the current wording of 21.5 [string.conversions]/p. 15 to:
</p>

<blockquote>
<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
<tt>wstring</tt> object holding the character representation of the
value of its argument that would be generated by calling
<tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
<tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
</blockquote>

<p>
[Hint to the editor: The resolution also adds to mention the name of
the format specifier "fmt"]
</p>

<p>
I also would like to remark that the current wording of it's equivalent
paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
</p>

<p>
Change the current wording of 21.5 [string.conversions]/p. 7 to:
</p>

<blockquote>
<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
character representation of the value of its argument that would be
generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
character buffer of sufficient size</ins>.
</blockquote>






<hr>
<h3><a name="774"></a>774. Member swap undefined for most containers</h3>
<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It appears most containers declare but do not define a member-swap
function.
</p>

<p>
This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
member-swap function!
(required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
[Table 87])
</p>

<p>
Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
definition.
</p>

<p>
A quick survey of clause 23 shows that the following containers provide a
definition for member-swap:
</p>

<blockquote><pre>array
queue
stack
vector
</pre></blockquote>

<p>
Whereas the following declare it, but do not define the semantics:
</p>

<blockquote><pre>deque
list
map
multimap
multiset
priority_queue
set
unordered_map
unordered_multi_map
unordered_multi_set
unordered_set
</pre></blockquote>

<p>
Suggested resolution:
</p>
<blockquote>
Provide a definition for each of the affected containers...
</blockquote>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
Move to Open and ask Alisdair to provide wording.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Daniel to provide wording.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>
is no longer applicable.
</blockquote>

<p><i>[
2009-07-28 Daniel provided wording.
]</i></p>


<blockquote>
<ol>
<li>
It assumes that the proposed resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a> is applied,
which breaks the circularity of definition between member
<tt>swap</tt> and free <tt>swap</tt>.
</li>

<li>
It uses the notation of the pre-concept allocator trait
<tt>allocator_propagation_map</tt>, which might be renamed after the
next refactoring phase of generalized allocators.
</li>

<li>
It requires that compare objects, key equal functions and
hash functions in containers are swapped via unqualified free
<tt>swap</tt> according to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#594">594</a>.
</li>
</ol>
</blockquote>

<p><i>[
2009-09-30 Daniel adds:
]</i></p>


<blockquote>
The outcome of this issue should be considered with the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1198">1198</a> both in style and in content (e.g. bullet 9 suggests to
define the semantic of <tt>void
priority_queue::swap(priority_queue&amp;)</tt> in terms of the member
<tt>swap</tt> of the container).
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Looked at, but took no action on as it overlaps too much with
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
Waiting for a new draft WP.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as open. Pablo to provide wording.
</blockquote>

<p><i>[
2009-10-26 Pablo updated wording.  Here is the wording he replaced:
]</i></p>


<blockquote class="note">
<ol>
<li>
<p>
Add a new Throws clause just after X [allocator.propagation.map]/5:
</p>

<blockquote><pre>static void swap(Alloc&amp; a, Alloc&amp; b);
</pre>
<blockquote>
<p>
<i>Effects:</i> [..]
</p>

<p>
<ins><i>Throws:</i> Nothing.</ins>
</p>
</blockquote>
</blockquote>
<p><i>[
This exception requirement is added, such that it's combination with the
general container requirements of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
[container.requirements.general]/9
make it unambiguously clear that the following descriptions of "swaps the
allocators" have the following meaning: (a) This swap is done by calling
<tt>allocator_propagation_map&lt;allocator_type&gt;::swap</tt> and (b) This allocator
swap does never propagate an exception
]</i></p>

</li>

<li>
<p>
Change 23.2.4.1 [associative.reqmts.except]/3 as indicated:
</p>

<blockquote>
For associative containers, no <tt>swap</tt> function throws an exception unless that
exception is thrown by the <del>copy constructor or copy assignment
operator</del>
<ins><tt>swap</tt></ins> of the container's <tt>Pred</tt> object<ins>s</ins><del> (if any)</del>.
</blockquote>
</li>

<li>
<p>
Change 23.2.5.1 [unord.req.except]/3 as indicated:
</p>

<blockquote>
For unordered associative containers, no <tt>swap</tt> function throws an
exception unless
that exception is thrown by the <del>copy constructor or copy
assignment operator</del>
<ins><tt>swap</tt></ins> of the container's <tt>Hash</tt> or <tt>Pred</tt> object<ins>s,
respectively</ins><del> (if any)</del>.
</blockquote>
</li>

<li>
<p>
Insert a new paragraph just after 23.3 [sequences]/1:
</p>

<blockquote>
<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when the
header <tt>&lt;queue&gt;</tt> is included.</ins>
</blockquote>

<p><i>[
There is a new issue in process that will suggest a minimum header for <tt>swap</tt>
and <tt>move</tt>. If this one is provided, this text can be removed and the header
dependency should be added to <tt>&lt;queue&gt;</tt>
]</i></p>


</li>

<li>
<p>
Add one further clause at the end of 23.3.1.2 [array.special]:
</p>
<p><i>[This part is added, because otherwise <tt>array::swap</tt> would otherwise
contradict the
general contract of 23.2.1 [container.requirements.general] p. 10 b. 5]</i></p>


<blockquote>
<ins><i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throws
an exception.</ins>
</blockquote>
</li>

<li>
<ol type="a">
<li>
<p>
In 23.3.2 [deque], class template deque synopsis change as indicated:
</p>
<blockquote><pre>void swap(deque<del>&lt;T,Alloc&gt;</del>&amp;);
</pre></blockquote>
</li>

<li>
<p>
At the end of 23.3.2.3 [deque.modifiers] add as indicated:
</p>

<blockquote><pre><ins>void swap(deque&amp; x);</ins>
</pre>
<blockquote>
<p>
<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
with that of <tt>x</tt>.</ins>
</p>
<p>
<ins><i>Complexity:</i> Constant time.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li>
<ol type="a">
<li>
<p>
In 23.3.3 [forwardlist], class template <tt>forward_list</tt> synposis change as indicated:
</p>

<blockquote><pre>void swap(forward_list<del>&lt;T,Allocator&gt;</del>&amp;);
</pre></blockquote>
</li>

<li>
<p>
At the end of 23.3.3.4 [forwardlist.modifiers] add as indicated:
</p>

<blockquote><pre><ins>void swap(forward_list&amp; x);</ins>
</pre>
<blockquote>
<p>
<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
with that of <tt>x</tt>.</ins>
</p>
<p>
<ins><i>Complexity:</i> Constant time.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li>
<ol type="a">
<li>
<p>
In 23.3.4 [list], class template <tt>list</tt> synopsis change as indicated:
</p>

<blockquote><pre>void swap(list<del>&lt;T,Allocator&gt;</del>&amp;);
</pre></blockquote>
</li>

<li>
<p>
At the end of 23.3.4.3 [list.modifiers] add as indicated:
</p>

<blockquote><pre><ins>void swap(list&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
with that of <tt>x</tt>.</ins>
</p>

<p>
<ins><i>Complexity:</i> Constant time.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li>
<p>
At the end of 23.5.2.3 [priqueue.members] add a new prototype description:
</p>

<blockquote><pre><ins>void swap(priority_queue&amp; q);</ins>
</pre>
<blockquote>
<p>
<ins><i>Requires:</i> <tt>Compare</tt> shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>

<p><i>[
This requirement is added to ensure that even a user defined <tt>swap</tt>
which is found by
ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt> requirements
]</i></p>


<p>
<ins><i>Effects:</i> <tt>this-&gt;c.swap(q.c); swap(this-&gt;comp, q.comp);</tt></ins>
</p>
<p>
<ins><i>Throws:</i> What and if <tt>c.swap(q.c)</tt> and <tt>swap(comp, q.comp)</tt> throws.</ins>
</p>
</blockquote>
</blockquote>
<p><i>[
This part is added, because otherwise <tt>priority_queue::swap</tt> would otherwise
contradict the general contract of 23.2.1 [container.requirements.general] p. 10 b. 5
]</i></p>

</li>

<li>
<ol type="a">
<li>
<p>
In 23.4.1 [vector], class template <tt>vector</tt> synopsis change as indicated:
</p>

<blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp;);
</pre></blockquote>
</li>

<li>
<p>
Change 23.4.1.2 [vector.capacity]/8 as indicated:
</p>

<blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp; x);
</pre>

<blockquote>
<i>Effects:</i> Exchanges the contents and <tt>capacity()</tt> <ins>and swaps the
allocators</ins>
of <tt>*this</tt> with that of <tt>x</tt>.
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li>
<p>
Insert a new paragraph just before 23.6 [associative]/1:
</p>

<blockquote>
<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when any of the
headers <tt>&lt;map&gt;</tt> or <tt>&lt;set&gt;</tt> are included.</ins>
</blockquote>
</li>

<li>
<ol type="a">
<li>
<p>
In 23.6.1 [map], class template <tt>map</tt> synopsis change as indicated:
</p>

<blockquote><pre>void swap(map<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
</pre></blockquote>
</li>

<li>
<p>
At the end of 23.6.1.3 [map.modifiers] add as indicated:
</p>

<blockquote><pre><ins>void swap(map&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>

<p><i>[
This requirement is added to ensure that even a user defined <tt>swap</tt>
which is found by ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt>
requirements
]</i></p>


<p>
<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
of <tt>*this</tt> and <tt>x</tt>.</ins>
</p>

<p>
<ins><i>Complexity:</i> Constant time</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li>
<ol type="a">
<li>
<p>
In 23.6.2 [multimap], class template <tt>multimap</tt> synopsis change as indicated:
</p>

<blockquote><pre>void swap(multimap<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
</pre></blockquote>
</li>

<li>
<p>
At the end of 23.6.2.2 [multimap.modifiers] add as indicated:
</p>

<blockquote><pre><ins>void swap(multimap&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>
<p>
<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
of <tt>*this</tt> and <tt>x</tt>.</ins>
</p>
<p>
<ins><i>Complexity:</i> Constant time</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li>
<ol type="a">
<li>
<p>
In 23.6.3 [set], class template <tt>set</tt> synopsis change as indicated:
</p>

<blockquote><pre>void swap(set<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
</pre></blockquote>
</li>

<li>
<p>
After section 23.6.3.1 [set.cons] add a new section <ins><tt>set</tt> modifiers
 [set.modifiers]</ins>
and add the following paragraphs:
</p>

<blockquote><pre><ins>void swap(set&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>

<p>
<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
of <tt>*this</tt> and <tt>x</tt>.</ins>
</p>

<p>
<ins>Complexity: Constant time</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li>
<ol type="a">
<li>
<p>
In 23.6.4 [multiset], class template <tt>multiset</tt> synosis, change as indicated:
</p>

<blockquote><pre>void swap(multiset<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
</pre></blockquote>
</li>

<li>
<p>
After section 23.6.4.1 [multiset.cons] add a new section <ins><tt>multiset</tt> modifiers
 [multiset.modifiers]</ins> and add the following paragraphs:
</p>

<blockquote><pre><ins>void swap(multiset&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>

<p>
<ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
of <tt>*this</tt> and <tt>x</tt>.</ins>
</p>

<p>
<ins><i>Complexity:</i> Constant time</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li>
<p>
Insert a new paragraph just before 23.7 [unord]/1:
</p>

<blockquote>
<ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
the <tt>swap</tt> function templates in 25.3.3 [alg.swap] are also available when any of the
headers <tt>&lt;unordered_map&gt;</tt> or <tt>&lt;unordered_set&gt;</tt> are included.</ins>
</blockquote>

</li>

<li>
<p>
After section 23.7.1.2 [unord.map.elem] add a new section <ins>unordered_map
modifiers  [unord.map.modifiers]</ins> and add the following paragraphs:
</p>

<blockquote><pre><ins>void swap(unordered_map&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>

<p><i>[
This requirement is added to ensure that even a user defined <tt>swap</tt>
which is found by ADL for <tt>Hash</tt> and <tt>Pred</tt> satisfies the <tt>Swappable</tt>
requirements
]</i></p>


<p>
<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
allocators of <tt>*this</tt>
with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt>.</ins>
</p>

<p>
<ins><i>Complexity:</i> Constant time</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
After section 23.7.2.1 [unord.multimap.cnstr] add a new section
<ins>unordered_multimap
modifiers  [unord.multimap.modifiers]</ins> and add the following paragraphs:
</p>

<blockquote><pre><ins>void swap(unordered_multimap&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>

<p>
<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
allocators of <tt>*this</tt>
with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
</p>
<p>
<ins><i>Complexity:</i> Constant time</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
After section 23.7.3.1 [unord.set.cnstr] add a new section
<ins>unordered_set modifiers
 [unord.set.modifiers]</ins> and add the following paragraphs:
</p>

<blockquote><pre><ins>void swap(unordered_set&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>

<p>
<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
allocators of <tt>*this</tt>
with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
</p>

<p>
<ins><i>Complexity:</i> Constant time</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
After section 23.7.4.1 [unord.multiset.cnstr] add a new section
<ins>unordered_multiset
modifiers  [unord.multiset.modifiers]</ins> and add the following paragraphs:
</p>

<blockquote><pre><ins>void swap(unordered_multiset&amp; x);</ins>
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
( [swappable]).</ins>
</p>

<p>
<ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
allocators of <tt>*this</tt>
with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
</p>
<p>
<ins><i>Complexity:</i> Constant time</ins>
</p>
</blockquote>
</blockquote>
</li>

</ol>

</blockquote>

<p><i>[
2009-10-30 Pablo and Daniel updated wording.
]</i></p>


<p><i>[
2010 Pittsburgh:  Ready for Pittsburgh.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>[
This resolution is based on the September 2009 WP,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>,
except that it
assumes that
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>
and issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1232">1232</a> have already been applied.  Note in
particular that Table 91 in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
is refered to as Table 90 because
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>
removed the old Table 90.  This resolution also addresses issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#431">431</a>.
]</i></p>

<p>
In 23.2.1 [container.requirements.general], replace the a.swap(b) row in table 90,
"container requirements" (was table 91 before the application of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a> to the
WP):
</p>
<blockquote>
<table border="1">
  <tbody><tr>
    <td><code>a.swap(b)</code></td>
    <td><code>void</code></td>
    <td>&nbsp;&nbsp;&nbsp;</td>
    <td><code><del>swap(a,b)</del><ins>Exchange the contents of <tt>a</tt> and <tt>b</tt>.</ins></code></td>
    <td>(Note A)</td>
  </tr>
  <tr>
    <td><ins><code>swap(a,b)</code></ins></td>
    <td><ins><code>void</code></ins></td>
    <td><code>&nbsp;&nbsp;&nbsp;</code></td>
    <td><ins><code>a.swap(b)</code></ins></td>
    <td><ins>(Note A)</ins></td>
  </tr>
</tbody></table>
</blockquote>
<p>
Modify the notes immediately following Table 90 in
23.2.1 [container.requirements.general] as follows (The wording below is after the
application of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>.  The editor might also want to combine Notes
A and B into one.):
</p>
<blockquote><p>
Notes: the algorithms<del> swap(),</del> equal() and lexicographical_compare()
are defined in Clause 25.  Those entries marked "(Note A)" or "(Note B)"
<del>should</del> have <ins>linear complexity for array and</ins> constant
complexity <ins>for all other standard containers</ins>.
</p></blockquote>
<p>
In 23.2.1 [container.requirements.general], before paragraph 8, add:
</p>
<blockquote><p><ins>
The expression <code>a.swap(b)</code>, for containers <code>a</code>
and <code>b</code> of a standard container type other than <code>array</code>,
exchanges the values of <code>a</code> and <code>b</code> without invoking any
move, copy, or swap operations on the individual container elements.
Any <code>Compare</code>, <code>Pred</code>, or <code>Hash</code> function
objects belonging to <code>a</code> and <code>b</code> shall be
<code>swappable</code> and are exchanged by unqualified calls
to non-member <code>swap</code>.  If
<code>allocator_traits&lt;allocator_type&gt;::propagate_on_container_swap::value
== true</code>, then the allocators of <code>a</code> and <code>b</code> are
also exchanged using an unqualified call to non-member <code>swap</code>.
Otherwise, the behavior is undefined unless <code>a.get_allocator() ==
b.get_allocator()</code>.  Each iterator refering to an element in one
container before the swap shall refer to the same element in the other
container after the swap.  It is unspecified whether an iterator with
value <code>a.end()</code> before the swap will have
value <code>b.end()</code> after the swap.  In addition to being available via
inclusion of the <code>&lt;utility&gt;</code> header, the <code>swap</code>
function template in 25.3.3 [alg.swap] is also available within the definition of
every standard container's <code>swap</code> function.
</ins></p></blockquote>
<p><i>[
Note to the editor: Paragraph 2 starts with a sentence fragment,
clearly from an editing or source-control error.
]</i></p>

<p>
Modify 23.2.4.1 [associative.reqmts.except] as follows:
</p>
<blockquote>
<p>
<b>23.2.4.1 Exception safety guarantees 23.2.4.1 [associative.reqmts.except]</b>
</p>
<p>
For associative containers, no <code>clear()</code> function throws an
exception. <code>erase(k)</code> does not throw an exception unless that
exception is thrown by the
container's <code><del>Pred</del><ins>Compare</ins></code> object (if any).
</p>
<p>
For associative containers, if an exception is thrown by any operation from
within an <code>insert()</code> function inserting a single element,
the <code>insert()</code> function has no effect.
</p>
<p>
For associative containers, no <code>swap</code> function throws an exception
unless that exception is thrown by the <del>copy constructor
or copy assignment operator</del><ins>swap</ins> of the
container's <code><del>Pred</del><ins>Compare</ins></code> object (if any).
</p></blockquote>
<p>
Modify 23.2.5.1 [unord.req.except], paragraph 3 as follows:
</p>
<blockquote><p>
For unordered associative containers, no <code>swap</code> function throws an
exception unless that exception is thrown by the <del>copy constructor or copy
assignment operator</del><ins>swap</ins> of the container's <code>Hash</code>
or <code>Pred</code> object (if any).
</p></blockquote>
<p>
Modify section 23.3.1.2 [array.special]:
</p>
<blockquote>
<p>
<b>array specialized algorithms 23.3.1.2 [array.special]</b>
</p>
<p>
<code>template &lt;class T, size_t N&gt; void swap(array&lt;T,N&gt;&amp; x,array&lt;T,N&gt;&amp; y);</code>
</p>
<blockquote>
<p>
<i>Effects:</i> <code><del>swap_ranges(x.begin(), x.end(), y.begin() );</del><ins>x.swap(y);</ins></code>
</p>
</blockquote>
</blockquote>
<p>
Add a new section after 23.3.1.5 [array.fill] (Note to the editor: array::fill make use
of a concept requirement that must be removed or changed to text.):
</p>
<blockquote>
<p>
<ins><b>array::swap [array.swap]</b></ins>
</p>
<p>
<ins><code>void swap(array&amp; y);</code></ins>
</p>
<blockquote>
<p><ins>
<i>Effects:</i> <code>swap_ranges(this-&gt;begin(), this-&gt;end(), y.begin() );</code>
</ins></p>
<p><ins>
<i>Throws:</i> Nothing unless one of the element-wise swap calls throws an
exception.
</ins></p>
<p><ins>
[<i>Note</i>: Unlike other containers' <code>swap</code> functions,
<code>array::swap</code> takes linear, not constant, time, may exit via an
exception, and does not cause iterators to become associated with the other
container. � <i>end note</i>]
</ins></p>
</blockquote>
</blockquote>

<p>
Insert a new paragraph just after 23.5 [container.adaptors]/1:
</p>
<blockquote><p><ins>
For container adaptors, no <code>swap</code> function throws an exception
unless that exception is thrown by the swap of the
adaptor's <code>Container</code> or <code>Compare</code> object (if any).
</ins></p></blockquote>












<hr>
<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
<p><b>Section:</b> 20.4.2.5 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The tuple element access API identifies the element in the sequence
using signed integers, and then goes on to enforce the requirement that
I be &gt;= 0.  There is a much easier way to do this - declare I as
<tt>unsigned</tt>.
</p>
<p>
In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
</p>
<p>
A second suggestion is that it is hard to imagine an API that deduces
and index at compile time and returns a reference throwing an exception.
Add a specific <em>Throws:</em> Nothing paragraph to each element
access API.
</p>
<p>
In addition to <code>tuple</code>, update the API applies to
<code>pair</code> and <code>array</code>, and should be updated
accordingly.
</p>

<p>
A third observation is that the return type of the <code>get</code>
functions for <code>std::pair</code> is pseudo-code, but it is not
clearly marked as such.  There is actually no need for pseudo-code as
the return type can be specified precisely with a call to
<code>tuple_element</code>.  This is already done for
<code>std::tuple</code>, and <code>std::array</code> does not have a
problem as all elements are of type <code>T</code>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Update header &lt;utility&gt; synopsis in 20.3 [utility]
</p>
<pre><em>// 20.2.3, tuple-like access to pair:</em>
template &lt;class T&gt; class tuple_size;
template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element;

template &lt;class T1, class T2&gt; struct tuple_size&lt;std::pair&lt;T1, T2&gt; &gt;;
template &lt;class T1, class T2&gt; struct tuple_element&lt;0, std::pair&lt;T1, T2&gt; &gt;;
template &lt;class T1, class T2&gt; struct tuple_element&lt;1, std::pair&lt;T1, T2&gt; &gt;;

template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
  <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(std::pair&lt;T1, T2&gt;&amp;);
template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
  const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const std::pair&lt;T1, T2&gt;&amp;);
</pre>
<p>
Update <strong>20.3.5 [pairs] Pairs</strong>
</p>
<pre>template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
  <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(pair&lt;T1, T2&gt;&amp;);
template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
  const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const pair&lt;T1, T2&gt;&amp;);
</pre>
<p>
<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del>
</p>
<p>
25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>.
</p>
<p>
<ins><em>Throws:</em> Nothing.</ins>
</p>


<p>
Update header &lt;tuple&gt; synopsis in 20.4 [tuple] with a APIs as below:
</p>
<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// undefined</em>
template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;

<em>// 20.3.1.4, element access:</em>
template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp;);
template &lt;<del>int</del><ins>size_t</ins> I, class ... types&gt;
  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp;);
</pre>

<p>
Update <strong>20.4.2.5 [tuple.helper] Tuple helper classes</strong>
</p>
<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
public:
  typedef TI type;
};</pre>
<p>
1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
</p>
<p>
2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based.
</p>
<p>
Update <strong>20.4.2.6 [tuple.elem] Element access</strong>
</p>
<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types &gt;
typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp; t);
</pre>
1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
<p>
2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
</p>
<ins><em>Throws:</em> Nothing.</ins>
<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types&gt;
typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp; t);
</pre>
<p>
3 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
</p>
<p>
4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
</p>
<p>
<ins><em>Throws:</em> Nothing.</ins>
</p>


<p>
Update header &lt;array&gt; synopsis in 20.3 [utility]
</p>
<pre>template &lt;class T&gt; class tuple_size; <em>// forward declaration</em>
template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// forward declaration</em>
template &lt;class T, size_t N&gt;
  struct tuple_size&lt;array&lt;T, N&gt; &gt;;
template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
  struct tuple_element&lt;I, array&lt;T, N&gt; &gt;;
template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
  T&amp; get(array&lt;T, N&gt;&amp;);
template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
  const T&amp; get(const array&lt;T, N&gt;&amp;);
</pre>

<p>
Update <strong>23.3.1.8 [array.tuple] Tuple interface to class template array</strong>
</p>
<pre>tuple_element&lt;<ins>size_t </ins>I, array&lt;T, N&gt; &gt;::type
</pre>
<p>
3 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N.</code> The program is ill-formed if <code>I</code> is out of bounds.
</p>
<p>
4 <em>Value:</em> The type <code>T</code>.
</p>
<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; T&amp; get(array&lt;T, N&gt;&amp; a);
</pre>
<p>
5 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
</p>
<p>
<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
</p>
<p>
<ins><em>Throws:</em> Nothing.</ins>
</p>
<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; const T&amp; get(const array&lt;T, N&gt;&amp; a);
</pre>
<p>
6 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
</p>
<p>
7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
</p>
<p>
<ins><em>Throws:</em> Nothing.</ins>
</p>


<p><i>[
Bellevue: Note also that the phrase "The program is ill-formed if I is
out of bounds" in the requires clauses are probably unnecessary, and
could be removed at the editor's discretion. Also std:: qualification
for pair is also unnecessary.
]</i></p>




<hr>
<h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The class template array synopsis in 23.3.1 [array]/3 declares a member
function
</p>

<blockquote><pre>void assign(const T&amp; u);
</pre></blockquote>

<p>
which's semantic is no-where described. Since this signature is
not part of the container requirements, such a semantic cannot
be derived by those.
</p>

<p>
I found only one reference to this function in the issue list,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a> where the question is raised:
</p>

<blockquote>
what's the effect of calling <tt>assign(T&amp;)</tt> on a zero-sized array?
</blockquote>

<p>
which does not answer the basic question of this issue.
</p>

<p>
If this function shall be part of the <tt>std::array</tt>, it's probable
semantic should correspond to that of <tt>boost::array</tt>, but of
course such wording must be added.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Just after the section 23.3.1.4 [array.data] add the following new section:
</p>

<p>
23.2.1.5 array::fill [array.fill]
</p>

<blockquote>
<pre>void fill(const T&amp; u);
</pre>

<p>
1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
</p>
</blockquote>

<p>
[N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
section. If it had, then <tt>assign</tt> would naturally belong to it]
</p>

<p>
Change the synopsis in 23.3.1 [array]/3:
</p>

<blockquote><pre>template &lt;class T, size_t N&gt;
struct array { 
  ...
  void <del>assign</del> <ins>fill</ins>(const T&amp; u);
  ...
</pre></blockquote>


<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Suggest substituting "fill" instead of "assign".
</p>
<p>
Set state to Review given substitution of "fill" for "assign".
</p>
</blockquote>




<hr>
<h3><a name="777"></a>777. Atomics Library Issue</h3>
<p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-01-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The load functions are defined as
</p>

<blockquote><pre>C atomic_load(volatile A* object);
C atomic_load_explicit(volatile A* object, memory_order);
C A::load(memory_order order = memory_order_seq_cst) volatile;
</pre></blockquote>

<p>
which prevents their use in <tt>const</tt> contexts.
</p>

<p><i>[
post Bellevue Peter adds:
]</i></p>


<blockquote>
<p>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
subtle point here. Atomic loads do not generally write to the object, except
potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
architecture, a dummy write with the same value may be required to be issued
by the atomic load to maintain sequential consistency. This, in turn, may
make the following code:
</p>

<blockquote><pre>const atomic_int x{};

int main()
{
  x.load();
}
</pre></blockquote>

<p>
dump core under a straightforward implementation that puts const objects in
a read-only section.
</p>
<p>
There are ways to sidestep the problem, but it needs to be considered.
</p>
<p>
The tradeoff is between making the data member of the atomic types
mutable and requiring the user to explicitly mark atomic members as
mutable, as is already the case with mutexes.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
</p>

<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
</pre></blockquote>






<hr>
<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
<p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-01-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
<p><b>Discussion:</b></p>
<p>
A small issue with <tt>std::bitset</tt>: it does not have any constructor
taking a string literal, which is clumsy and looks like an oversigt when
we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
</p>

<p>
Suggestion: Add
</p>

<blockquote><pre>explicit bitset( const char* str );
</pre></blockquote>

<p>
to std::bitset.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add to synopsis in 20.5 [template.bitset]
</p>

<blockquote><pre>explicit bitset( const char* str );
</pre></blockquote>

<p>
Add to synopsis in 20.5.1 [bitset.cons]
</p>

<blockquote><pre>explicit bitset( const char* str );
</pre>
<p>
<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
</p>
</blockquote>






<hr>
<h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
<p><b>Section:</b> 25.3.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm
<tt>remove_copy[_if]</tt>,
which seems to be an oversight.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 25.3.8 [alg.remove]/p.6, replace the N2461 requires clause with:
</p>

<blockquote>
<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
valid.</ins>
</blockquote>






<hr>
<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
<p><b>Section:</b> 25.4.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
</p>

<p>
Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.4.4 [alg.merge] in N2461
have no Requires element and the Effects element contains some requirements,
which is probably editorial. Worse is that:
</p>

<ul>
<li>
no assignment requirements are specified (neither implicit nor explicit).
</li>

<li>
the effects clause just speaks of "merges", which is badly worded
near to a circular definition.
</li>

<li>
p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
function arguments or otherwise.
</li>

<li>
p. 2 says "according to the ordering defined by comp" which is both
incomplete (because
this excludes the first variant with &lt;) and redundant (because the
following subordinate
clause mentions comp again)
</li>
</ul>

<p><i>[
Post Summit Alisdair adds:
]</i></p>


<blockquote>
<p>
Suggest:
</p>
<blockquote>
(where <tt>last</tt> is equal to <tt>next(result, distance(first1, last1) +
distance(first2, last2))</tt>, such that resulting range will be sorted in
non-decreasing order; that is, for every iterator <tt>i</tt> in <tt>[result,last)</tt> other
than <tt>result</tt>, the condition <tt>*i &lt; *prev(i)</tt> or, respectively, <tt>comp(*i,
*prev(i))</tt> will be <tt>false</tt>.
</blockquote>

<p>
Note that this might still not be technically accurate in the case of
<tt>InputIterators</tt>, depending on other resolutions working their way through the
system (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1011">1011</a>).
</p>
</blockquote>

<p><i>[
Post Summit Daniel adds:
]</i></p>


<blockquote>
If we want to use <tt>prev</tt> and <tt>next</tt> here (Note: <tt>merge</tt>
is sufficiently satisfied with <tt>InputIterator</tt>) we should instead *add* more to
25 [algorithms]/6, but I can currently not propose any good wording for this.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Pete points out the existing wording in [algorithms]/4
that permits the use of + in algorithm specifications.
</p>
<p>
Alisdair points out that that wording may not apply to input iterators.
</p>
<p>
Move to Review.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
2009-08-23 Daniel reopens:
]</i></p>


<blockquote>
<p>
The proposed wording must be rephrased, because the part
</p>

<blockquote>
for every iterator <tt>i</tt> in <tt>[result,last)</tt> other than <tt>result</tt>, the condition
<tt>*i &lt; *(i - 1)</tt> or, respectively, <tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>"
</blockquote>

<p>
isn't meaningful, because the range <tt>[result,last)</tt> is that of a pure
<tt>OutputIterator</tt>, which is not <em>readable</em> in general.
</p>

<p><i>[Howard:  Proposed wording updated by Daniel, status moved from Ready to Review.]</i></p>

</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<p>
Matt has some different words to propose.  Those words have been moved into
the proposed wording section, and the original proposed wording now appears
here:
</p>
<blockquote>
<p>
In 25.4.4 [alg.merge] replace p.1+ 2:
</p>

<blockquote>
<p>
<i>Effects:</i> <del>Merges</del><ins>Copies all the elements of the</ins>
two sorted ranges
<tt>[first1,last1)</tt> and <tt>[first2,last2)</tt> into the range <tt>[result,result +
(last1 - first1) + (last2 - first2))</tt>
<ins>, such that resulting range will be sorted in non-decreasing
order; that is for every
pair of iterators <tt>i</tt> and <tt>j</tt> of either input ranges, where <tt>*i</tt> was copied
to the output range
before <tt>*j</tt> was copied to the output range, the condition <tt>*j &lt; *i</tt> or,
respectively, <tt>comp(*j, *i)</tt>
will be <tt>false</tt>.</ins>
</p>

<p>
<ins><i>Requires:</i></ins>The resulting range shall not overlap with either
of the original ranges.
<del>The list will be sorted in non-decreasing order according to the
ordering defined by
<tt>comp</tt>; that is, for every iterator <tt>i</tt> in <tt>[first,last)</tt> other than <tt>first</tt>,
the condition <tt>*i &lt; *(i - 1)</tt> or
<tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>.</del>
</p>
</blockquote>
</blockquote>
</blockquote>

<p><i>[
2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Change 25.4.4 [alg.merge] 1 and 2:
</p>

<blockquote>
<p>1 <del>
<i>Effects:</i> Merges two sorted ranges <tt>[first1,last1)</tt> and
<tt>[first2,last2)</tt> into the range <tt>[result, result + (last1 -
first1) + (last2 - first2))</tt>.
</del></p>
<p><ins>
<i>Effects:</i> Copies all the elements of the two ranges
<tt>[first1,last1)</tt> and <tt>[first2,last2)</tt> into the range
<tt>[result, result_last)</tt>, where <tt>result_last</tt> is <tt>result
+ (last1 - first1) + (last2 - first2)</tt>, such that the resulting
range satisfies <tt>is_sorted(result, result_last)</tt> or
<tt>is_sorted(result, result_last, comp)</tt>, respectively.
</ins></p>

<p>
2 <ins><i>Requires:</i></ins> <ins>The ranges <tt>[first1,last1)</tt> and
<tt>[first2,last2)</tt> shall be sorted with respect to <tt>operator&lt;</tt> or
<tt>comp</tt>.</ins> The resulting range shall not overlap with either of the
original ranges.  <del>The list will be sorted in non-decreasing order according
to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt>
in <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt;
*(i - 1)</tt> or <tt>comp(*i, *(i - 1))</tt> will be <tt>false</tt>.</del>
</p>

</blockquote>

<p>
Change 25.4.4 [alg.merge]/6+7 as indicated <i>[This ensures harmonization
between <tt>inplace_merge</tt> and <tt>merge</tt>]</i>
</p>

<blockquote>
<p>
6 <i>Effects:</i> Merges two <del>sorted</del> consecutive ranges
<tt>[first,middle)</tt> and <tt>[middle,last)</tt>, putting the result of the
merge into the range <tt>[first,last)</tt>. The resulting range will be in
non-decreasing order; that is, for every iterator <tt>i</tt> in
<tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt; *(i -
1)</tt> or, respectively, <tt>comp(*i, *(i - 1))</tt> will be false.
</p>

<p>
7 <i>Requires:</i> <ins>The ranges <tt>[first,middle)</tt> and
<tt>[middle,last)</tt> shall be sorted with respect to <tt>operator&lt;</tt> or
<tt>comp</tt>.</ins> The type of <tt>*first</tt> shall satisfy the
<tt>Swappable</tt> requirements (37), the <tt>MoveConstructible</tt>
requirements (Table 33), and the the <tt>MoveAssignable</tt> requirements (Table
35).
</p>
</blockquote>






<hr>
<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
<p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
some complex functions that are missing in C++. These are:
</p>

<ol>
<li>
7.3.9.4: (required elements of the C99 library)<br>
The <tt>cproj</tt> functions
</li>
<li>
7.26.1: (optional elements of the C99 library)<br>
<pre>cerf    cerfc    cexp2
cexpm1  clog10   clog1p
clog2   clgamma  ctgamma
</pre>
</li>
</ol>

<p>
I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
C++ functions. This addition is easy to do in one sentence (delegation to C99
function).
</p>

<p>
Please note also that the current entry <tt>polar</tt>
in 26.4.9 [cmplx.over]/1
should be removed from the mentioned overload list. It does not make sense to require that a
function already expecting <em>scalar</em> arguments
should cast these arguments into corresponding
<tt>complex&lt;T&gt;</tt> arguments, which are not accepted by
this function.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 26.4.1 [complex.syn] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
</p>

<blockquote><pre>template&lt;class T&gt; complex&lt;T&gt; conj(const complex&lt;T&gt;&amp;);
<ins>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp;);</ins>
template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);
</pre></blockquote>

<p>
In 26.4.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
</p>

<blockquote>
<pre>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);
</pre>
<blockquote>

<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
subclause 7.3.9.4."
</blockquote>
</blockquote>

<p>
In 26.4.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
the overload list.
</p>

<blockquote>
<p>
The following function templates shall have additional overloads:
</p>
<blockquote><pre>arg           norm 
conj          <del>polar</del> <ins>proj</ins>
imag          real
</pre></blockquote>
</blockquote>






<hr>
<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-27 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Part of the resolution of n2423, issue 8 was the proposal to
extend the <tt>seed_seq</tt> constructor accepting an input range
as follows (which is now part of N2461):
</p>

<blockquote><pre>template&lt;class InputIterator,
size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits&gt;
seed_seq(InputIterator begin, InputIterator end);
</pre></blockquote>

<p>
First, the expression <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>
is invalid due to missing <tt>typename</tt> keyword, which is easy to
fix.
</p>

<p>
Second (and worse), while the language now supports default
template arguments of function templates, this customization
point via the second <tt>size_t</tt> template parameter is of no advantage,
because <tt>u</tt> can never be deduced, and worse - because it is a
constructor function template - it can also never be explicitly
provided (14.8.1 [temp.arg.explicit]/7).
</p>

<p>
The question arises, which advantages result from a compile-time
knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
suffices, this parameter should be provided as normal function
default argument [Resolution marked (A)], if compile-time knowledge
is important, this could be done via a tagging template or more
user-friendly via a standardized helper generator function
(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
Fermilab does not have a strong opinion. Would prefer to go with
solution A. Bill agrees that solution A is a lot simpler and does the
job.
</p>
<p>
Proposed Resolution: Accept Solution A.
</p>
</blockquote>

<p>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> claims to make this issue moot.
</p>



<p><b>Proposed resolution:</b></p>
<ol type="A">
<li>
<p>
In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
</p>

<blockquote><pre>class seed_seq 
{ 
public:
   ...
   template&lt;class InputIterator<del>,
      size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
          seed_seq(InputIterator begin, InputIterator end<ins>,
          size_t u = numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</ins>);
   ...
};
</pre></blockquote>

<p>
and do a similar replacement in the member description between
p.3 and p.4.
</p>
</li>

<li>
<p>
In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
member description between p.3 and p.4 replace:
</p>

<blockquote><pre>template&lt;class InputIterator<del>,
  size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
      seed_seq(InputIterator begin, InputIterator end);
<ins>template&lt;class InputIterator, size_t u&gt;
seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
</pre></blockquote>

<p>
In 26.5.2 [rand.synopsis], header <tt>&lt;random&gt;</tt> synopsis, immediately after the
class <tt>seed_seq</tt> declaration <em>and</em> in 26.5.7.1 [rand.util.seedseq]/2, immediately
after the class <tt>seed_seq</tt> definition add:
</p>

<blockquote><pre>template&lt;size_t u, class InputIterator&gt;
  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
</pre></blockquote>

<p>
In 26.5.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
</p>

<blockquote>
<p>
The first constructor behaves as if it would provide an
integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
<tt>numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</tt>.
</p>
<p>
The second constructor uses an implementation-defined mechanism
to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
is called by the function <tt>make_seed_seq</tt>.
</p>
</blockquote>

<p>
In 26.5.7.1 [rand.util.seedseq], just after the last paragraph add:
</p>

<blockquote>
<pre>template&lt;size_t u, class InputIterator&gt;
   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
</pre>
<blockquote>
<p>
where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
</p>
<p>
<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
<p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-02-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current working paper 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
integrated just before Bellevue) is
not completely clear whether a given <tt>thread::id</tt> value may be reused once
a thread has exited and has been joined or detached.  Posix allows
thread ids (<tt>pthread_t</tt> values) to be reused in this case.  Although it is
not completely clear whether this originally was the right decision, it
is clearly the established practice, and we believe it was always the
intent of the C++ threads API to follow Posix and allow this.  Howard
Hinnant's example implementation implicitly relies on allowing reuse
of ids, since it uses Posix thread ids directly.
</p>

<p>
It is important to be clear on this point, since it the reuse of thread
ids often requires extra care in client code, which would not be
necessary if thread ids were unique across all time.  For example, a
hash table indexed by thread id may have to be careful not to associate
data values from an old thread with a new one that happens to reuse the
id.  Simply removing the old entry after joining a thread may not be
sufficient, if it creates a visible window between the join and removal
during which a new thread with the same id could have been created and
added to the table.
</p>

<p><i>[
post Bellevue Peter adds:
]</i></p>


<blockquote>
<p>
There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
reconsider fixing this by disallowing reuse, rather than explicitly allowing
it. Dealing with thread id reuse is an incredibly painful exercise that
would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
and over.
</p>
<p>
In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
atomically in a lock-free manner, as motivated by the recursive lock
example:
</p>

<p>
<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add a sentence to 30.3.1.1 [thread.thread.id]/p1:
</p>

<blockquote>
<p>
An object of type <code>thread::id</code> provides
a unique identifier for each thread of execution
and a single distinct value for all thread objects
that do not represent a thread of execution ([thread.threads.class]).
Each thread of execution has a <code>thread::id</code>
that is not equal to the <code>thread::id</code>
of other threads of execution
and that is not equal to
the <code>thread::id</code> of <code>std::thread</code> objects
that do not represent threads of execution.
<ins>The library may reuse the value of a <code>thread::id</code> of a
terminated thread that can no longer be joined.</ins>
</p>
</blockquote>





<hr>
<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
<p><b>Section:</b> 20.11 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Opened:</b> 2008-02-03 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The draft C++0x thread library requires that the time points of type
<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
Universal Time (UTC) (section  [datetime.system]). This can lead to
surprising behavior when a library user performs a duration-based wait,
such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
problem may be found in the
<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
section in POSIX, but in summary:
</p>

<ul>
<li>
Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
to address the problem of spurious wakeups.
</li>

<li>
The typical use of the timed wait operations is to perform a relative
wait. This may be achieved by first calculating an absolute time as the
sum of the current time and the desired duration. In fact, the C++0x
thread library includes duration-based overloads of
<tt>condition_variable::timed_wait()</tt> that behave as if by calling the
corresponding absolute time overload with a time point value of
<tt>get_system_time() + rel_time</tt>.
</li>

<li>
A UTC clock may be affected by changes to the system time, such as
synchronization with an external source, leap seconds, or manual changes
to the clock.
</li>

<li>
Should the clock change during a timed wait operation, the actual
duration of the wait will not be the expected length. For example, a
user may intend a timed wait of one second duration but, due to an
adjustment of the system clock backwards by a minute, the wait instead
takes 61 seconds.
</li>
</ul>

<p>
POSIX solves the problem by introducing a new monotonic clock, which is
unaffected by changes to the system time. When a condition variable is
initialized, the user may specify whether the monotonic clock is to be
used. (It is worth noting that on POSIX systems it is not possible to
use <tt>condition_variable::native_handle()</tt> to access this facility, since
the desired clock type must be specified during construction of the
condition variable object.)
</p>

<p>
In the context of the C++0x thread library, there are added dimensions
to the problem due to the need to support platforms other than POSIX:
</p>

<ul>
<li>
Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
</li>

<li>
Some environments do not have a monotonic clock, but do have a UTC clock.
</li>

<li>
The Microsoft Windows API's synchronization functions use relative
timeouts based on an implied monotonic clock. A program that switches
from the Windows API to the C++0x thread library will now find itself
susceptible to clock changes.
</li>
</ul>

<p>
One possible minimal solution:
</p>

<ul>
<li>
Strike normative references to UTC and an epoch based on 1970-01-01.
</li>

<li>
Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
implementation-defined (i.e standard library implementors may choose the
appropriate underlying clock based on the capabilities of the target
platform).
</li>

<li>
Add a non-normative note encouraging use of a monotonic clock.
</li>

<li>
Remove <tt>system_time::seconds_since_epoch()</tt>.
</li>

<li>
Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
</li>
</ul>



<p><b>Proposed resolution:</b></p>
<p>
</p>


<p><b>Rationale:</b></p>
Addressed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>.





<hr>
<h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
<p><b>Section:</b> 25.4.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-09-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 25.4.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
</p>

<blockquote>
At most <tt>log(last - first) + 2</tt> comparisons.
</blockquote>

<p>
This should be precised and brought in line with the nomenclature used for
<tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
</p>

<p>
All existing libraries I'm aware of, delegate to
<tt>lower_bound</tt> (+ one further comparison). Since
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
has now WP status, the resolution of #787 should
be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
to <tt>+ O(1)</tt>.
</p>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
Alisdair prefers to apply an upper bound instead of O(1), but that would
require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
cares about it, he'll send an issue to Howard.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 25.4.3.4 [binary.search]/3
</p>

<blockquote>
<i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons.
</blockquote>





<hr>
<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
<p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-02-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 287</b></p>

<blockquote>
<p>
It is not clear what the initial state of an <tt>istream_iterator</tt> should be. Is
_value_ initialized by reading the stream, or default/value initialized? If
it is initialized by reading the stream, what happens if the initialization
is deferred until first dereference, when ideally the iterator value should
have been that of an end-of-stream iterator which is not safely
dereferencable?
</p>

<p>
Recommendation: Specify _value_ is initialized by reading the stream, or
the iterator takes on the end-of-stream value if the stream is empty.
</p>
</blockquote>

<p>
The description of how an istream_iterator object becomes an
end-of-stream iterator is a) ambiguous and b) out of date WRT
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
</p>

<blockquote>
<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
input stream for which it was constructed. After it is constructed, and
every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
the end of stream is reached (<tt>operator void*()</tt> on the stream returns
<tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
The constructor with no arguments <tt>istream_iterator()</tt> always constructs
an end of stream input iterator object, which is the only legitimate
iterator to be used for the end condition. The result of <tt>operator*</tt> on an
end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
store things into istream iterators. The main peculiarity of the istream
iterators is the fact that <tt>++</tt> operators are not equality preserving,
that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
is used a new value is read.
</blockquote>

<p>
<tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
<tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
void*()</tt> will return a non-null value).
</p>

<p>
Also I would prefer to be explicit about calling <tt>fail()</tt> here
(there is no <tt>operator void*()</tt> anymore.)
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Moved from Ready to Open for the purposes of using this issue to address NB UK 287.
Martin to handle.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
This improves the wording.
</p>
<p>
Move to Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 24.6.1 [istream.iterator]/1:
</p>

<blockquote>
<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
input stream for which it was constructed. After it is constructed, and
every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
<del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
(<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
<tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
The constructor with no arguments <tt>istream_iterator()</tt> always constructs
an end of stream input iterator object, which is the only legitimate
iterator to be used for the end condition. The result of <tt>operator*</tt> on an
end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
store things into istream iterators. The main peculiarity of the istream
iterators is the fact that <tt>++</tt> operators are not equality preserving,
that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
is used a new value is read.
</blockquote>





<hr>
<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
<p><b>Section:</b> X [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
Non-controversial. Bill is right, but Fermilab believes that this is
easy to use badly and hard to use right, and so it should be removed
entirely. Got into TR1 by well defined route, do we have permission to
remove stuff? Should probably check with Jens, as it is believed he is
the originator. Broad consensus that this is not a robust engine
adapter.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Remove xor_combine_engine from synopsis of 26.5.2 [rand.synopsis].
</p>
<p>
Remove X [rand.adapt.xor] <tt>xor_combine_engine</tt>.
</p>





<hr>
<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
<p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>piecewise_constant_distribution</tt> is undefined for a range with just one
endpoint. (Probably should be the same as an empty range.)
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 26.5.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
</p>

<blockquote>
b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
</blockquote>





<hr>
<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
<p><b>Section:</b> D.11 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-02-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
and its earlier predecessors have moved the old binders from
[lib.binders] to D.11 [depr.lib.binders] thereby introducing some renaming
of the template parameter names (<tt>Operation -&gt; Fn</tt>). During this
renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
this user access point is probably rarely used.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change D.11.1 [depr.lib.binder.1st]:
</p>

<blockquote>
<pre>template &lt;class Fn&gt; 
class binder1st 
  : public unary_function&lt;typename Fn::second_argument_type, 
                          typename Fn::result_type&gt; { 
protected: 
  Fn <del>fn</del> <ins>op</ins>; 
  typename Fn::first_argument_type value; 
public: 
  binder1st(const Fn&amp; x, 
            const typename Fn::first_argument_type&amp; y); 
  typename Fn::result_type 
    operator()(const typename Fn::second_argument_type&amp; x) const; 
  typename Fn::result_type 
    operator()(typename Fn::second_argument_type&amp; x) const; 
};
</pre>

<blockquote>
<p>
-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
</p>
<p>
-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
</p>
</blockquote>
</blockquote>

<p>
Change D.11.3 [depr.lib.binder.2nd]:
</p>

<blockquote>
<pre>template &lt;class Fn&gt; 
class binder2nd
  : public unary_function&lt;typename Fn::first_argument_type, 
                          typename Fn::result_type&gt; { 
protected: 
  Fn <del>fn</del> <ins>op</ins>; 
  typename Fn::second_argument_type value; 
public: 
  binder2nd(const Fn&amp; x, 
            const typename Fn::second_argument_type&amp; y); 
  typename Fn::result_type 
    operator()(const typename Fn::first_argument_type&amp; x) const; 
  typename Fn::result_type 
    operator()(typename Fn::first_argument_type&amp; x) const; 
};
</pre>

<blockquote>
<p>
-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
</p>
<p>
-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
<p><b>Section:</b> 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Classes with trivial special member functions are inherently more
efficient than classes without such functions.  This efficiency is
particularly pronounced on modern ABIs that can pass small classes
in registers.  Examples include value classes such as complex numbers
and floating-point intervals.  Perhaps more important, though, are
classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>.  When the
parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
themselves can be trivial, leading to substantial performance wins.
</p>
<p>
The current working draft make specification of trivial functions
(where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
As long as the semantics of defaulted and deleted functions match
the intended semantics, specification of defaulted and deleted
functions will yield more efficient programs.
</p>
<p>
There are at least two cases where specification of an explicitly
defaulted function may be desirable.
</p>
<p>
First, the <tt>std::pair</tt> template has a non-trivial default constructor,
which prevents static initialization of the pair even when the
types are statically initializable.  Changing the definition to
</p>

<blockquote><pre>pair() = default;
</pre></blockquote>

<p>
would enable such initialization.  Unfortunately, the change is
not semantically neutral in that the current definition effectively
forces value initialization whereas the change would not value
initialize in some contexts.
</p>

<p>
** Does the committee confirm that forced value initialization
was the intent?  If not, does the committee wish to change the
behavior of <tt>std::pair</tt> in C++0x?
</p>
<p>
Second, the same default constructor issue applies to <tt>std::tuple</tt>.
Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
which effectively prevents passing it in registers.  To enable
passing <tt>tuples</tt> in registers, the copy constructor should be
make explicitly <tt>default</tt>ed.  The new declarations are:
</p>

<blockquote><pre>tuple() = default;
tuple(const tuple&amp;) = default;
</pre></blockquote>

<p>
This changes is not implementation neutral.  In particular, it
prevents implementations based on pointers to the parameter
types.  It does however, permit implementations using the
parameter types as bases.
</p>
<p>
** How does the committee wish to trade implementation
efficiency versus implementation flexibility?
</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote>
<p>
General agreement; the first half of the issue is NAD.
</p>
<p>
Before voting on the second half, it was agreed that a "Strongly Favor"
vote meant support for trivial tuples (assuming usual requirements met),
even at the expense of other desired qualities. A "Weakly Favor" vote
meant support only if not at the expense of other desired qualities.
</p>
<p>
Concensus: Go forward, but not at expense of other desired qualities.
</p>
<p>
It was agreed to Alisdair should fold this work in with his other
pair/tuple action items, above, and that issue 801 should be "open", but
tabled until Alisdair's proposals are disposed of.
</p>
</blockquote>

<p><i>[
2009-05-27 Daniel adds:
]</i></p>


<blockquote>
This is partly solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1117">1117</a>.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Wait for dust to settle from fixing exception safety problem
with rvalue refs.
</blockquote>

<p><i>[
2009-07-20 Alisdair adds:
]</i></p>


<blockquote>
<p>
Basically, this issue is what should we do with the default constructor
for pairs and tuples of trivial types.  The motivation of the issue was
to force static initialization rather than dynamic initialization, and
was rejected in the case of pair as it would change the meaning of
existing programs.  The advice was "do the best we can" for tuple
without changing existing meaning.
</p>

<p>
Frankfurt seems to simply wait and see the resolution on no-throw move
constructors, which (I believe) is only tangentially related to this
issue, but as good as any to defer until Santa Cruz.
</p>

<p>
Looking again now, I think constant (static) initialization for pair can
be salvaged by making the default construct constexpr.  I have a
clarification from Core that this is intended to work, even if the
constructor is not trivial/constexpr, so long as no temporaries are
implied in the process (even if elided).
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as open. Alisdair to provide wording.
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
<p>
We believe this may be NAD Editorial since both pair and tuple now have
constexpr default constructors, but we're not sure.
</p>
</blockquote>


<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote>
Daniel believes his pair/tuple paper will resolve this issue. <tt>constexpr</tt> will allow static initialization, and he is already changing the move and copy constructors to be defaulted.
</blockquote>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> should resolve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
</p>





<hr>
<h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-02-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<ol type="A">
<li>
<p>
19.5.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
19.5.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
declare an expository data member <tt>cat_</tt>:
</p>
<blockquote><pre>const error_category&amp; cat_; // exposition only
</pre></blockquote>
<p>
which is used to define the semantics of several members. The decision
to use a member of reference type lead to several problems:
</p>
<ol>
<li>
The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
</li>
<li>
The post conditions of all modifiers from
19.5.2.3 [syserr.errcode.modifiers] and 19.5.3.3 [syserr.errcondition.modifiers], resp.,
cannot be fulfilled.
</li>
</ol>
<p>
The simple fix would be to replace the reference by a pointer member.
</p>
</li>

<li>
I would like to give the editorial remark that in both classes the
constrained <tt>operator=</tt>
overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
valid circumstances - this return type must be explicitly provided (In
<tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
type).
</li>

<li>
The member function <tt>message</tt> throws clauses (
19.5.1.2 [syserr.errcat.virtuals]/10, 19.5.2.4 [syserr.errcode.observers]/8, and
19.5.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
although
they return a <tt>std::string</tt> by value, which might throw in out-of-memory
conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>).
</li>
</ol>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.
</p>
<p>
Part B: Technically correct, save for typo. Rendered moot by the concept proposal 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
</p>
<p>
Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>.
</p>
<p>
Howard: please ping Beman, asking him to clear away parts A and B from
the wording in the proposed resolution, so it is clear to the editor
what needs to be applied to the working paper.
</p>
<p>
Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a> is not going
forward, the provided wording includes resolution of part A.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>

<p>
Resolution of part A:
</p>
<blockquote>
<p>
Change 19.5.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
</p>

<blockquote><pre>private:
  int val_;                    // exposition only
  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
</pre></blockquote>

<p>
Change 19.5.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
</p>

<blockquote>
<pre>error_code();
</pre>
<blockquote>
<p>
<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
</blockquote>
<pre>error_code(int val, const error_category&amp; cat);
</pre>
<blockquote>
<p>
<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
</blockquote>
</blockquote>

<p>
Change 19.5.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
</p>

<blockquote>
<pre>void assign(int val, const error_category&amp; cat);
</pre>
<blockquote>
<p>
<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
</blockquote>
</blockquote>

<p>
Change 19.5.2.4 [syserr.errcode.observers] Class error_code observers as indicated:
</p>

<blockquote>
const error_category&amp; category() const;
<blockquote>
<p>
<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
</blockquote>
</blockquote>

<p>
Change 19.5.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
</p>

<blockquote><pre>private:
  int val_;                    // exposition only
  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
</pre></blockquote>

<p>
Change 19.5.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
</p>
<p><i>[
(If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> has already been applied, the
name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
no effect on this resolution.)
]</i></p>


<blockquote>
<pre>error_condition();
</pre>
<blockquote>
<p>
<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
</blockquote>
<pre>error_condition(int val, const error_category&amp; cat);
</pre>
<blockquote>
<p>
<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
</blockquote>
</blockquote>

<p>
Change 19.5.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
</p>

<blockquote>
void assign(int val, const error_category&amp; cat);
<blockquote>
<p>
<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
</blockquote>
</blockquote>

<p>
Change 19.5.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
</p>

<blockquote>
const error_category&amp; category() const;
<blockquote>
<p>
<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
</blockquote>
</blockquote>
</blockquote>

<p>
Resolution of part C:
</p>

<blockquote>

<p>
In 19.5.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
</p>

<blockquote>
<pre>virtual string message(int ev) const = 0;
</pre>

<blockquote>
<p>
<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
</p>
<p>
<del><i>Throws:</i> Nothing.</del>
</p>
</blockquote>
</blockquote>

<p>
In 19.5.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
</p>

<blockquote>
<pre>string message() const;
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>category().message(value())</tt>.
</p>
<p>
<del><i>Throws:</i> Nothing.</del>
</p>
</blockquote>
</blockquote>

<p>
In 19.5.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
</p>

<blockquote>
<pre>string message() const;
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>category().message(value())</tt>.
</p>
<p>
<del><i>Throws:</i> Nothing.</del>
</p>
</blockquote>
</blockquote>

</blockquote>






<hr>
<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-02-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
19.5 [syserr]
</p>

<blockquote><pre>namespace posix_error {
  enum posix_errno {
    address_family_not_supported, // EAFNOSUPPORT
    ...
</pre></blockquote>

<p>
should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
which would avoid the necessity for a new <tt>posix_error</tt>
namespace, if I understand correctly.
</p>

<p><i>[
Further discussion:
]</i></p>


<blockquote>
<p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
Strongly Typed Enums, since renamed Scoped Enums.
</p>
<p>
Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
</p>
<p>
Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
</p>
<p>
The wording for the Proposed resolution was provided by Beman Dawes.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change System error support 19.5 [syserr] as indicated:
</p>

<blockquote><pre><del>namespace posix_error {</del>
  enum <del>posix_errno</del> <ins>class errc</ins> {
    address_family_not_supported, // EAFNOSUPPORT
    ...
    wrong_protocol_type, // EPROTOTYPE
  };
<del>} // namespace posix_error</del>

template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
  : public true_type {}

<del>namespace posix_error {</del>
  error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
  error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
<del>} // namespace posix_error</del>
</pre></blockquote>

<p>
Change System error support 19.5 [syserr] :
</p>

<blockquote>
<del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
specialized for user-defined types to indicate that such a type is
eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
conversions, respectively.</del>
</blockquote>

<p>
Change System error support 19.5 [syserr] and its subsections:
</p>

<blockquote>
<ul>
<li>
remove all occurrences of <tt>posix_error::</tt>
</li>
<li>
change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
</li>
<li>
change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
</li>
<li>
change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
</li>
</ul>
</blockquote>

<p>
Change Error category objects 19.5.1.5 [syserr.errcat.objects], paragraph 2:
</p>

<blockquote>
<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
functions shall behave as specified for the class <tt>error_category</tt>. The
object's name virtual function shall return a pointer to the string
<del>"POSIX"</del> <ins>"generic"</ins>.
</blockquote>

<p>
Change 19.5.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
</p>

<blockquote>
<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
</pre>

<blockquote>
<i>Returns:</i> <tt>error_code(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
</blockquote>
</blockquote>

<p>
Change 19.5.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
</p>

<blockquote>
<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
</pre>

<blockquote>
<i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
</blockquote>
</blockquote>



<p><b>Rationale:</b></p>
<table border="1">
<tbody><tr>
<th colspan="2">Names Considered</th>
</tr>

<tr>
<td><tt>portable</tt></td>
<td>
Too non-specific. Did not wish to reserve such a common word in
namespace std. Not quite the right meaning, either.
</td>
</tr>

<tr>
<td><tt>portable_error</tt></td>
<td>
Too long. Explicit qualification is always required for scoped enums, so
a short name is desirable. Not quite the right meaning, either. May be
misleading because <tt>*_error</tt> in the std lib is usually an exception class
name.
</td>
</tr>

<tr>
<td><tt>std_error</tt></td>
<td>
Fairly short, yet explicit. But in fully qualified names like
<tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
quite the right meaning, either. May be misleading because <tt>*_error</tt> in
the std lib is usually an exception class name.
</td>
</tr>

<tr>
<td><tt>generic</tt></td>
<td>
Short enough. The category could be <tt>generic_category</tt>. Fully qualified
names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
namespace std seems dicey.
</td>
</tr>

<tr>
<td><tt>generic_error</tt></td>
<td>
Longish. The category could be <tt>generic_category</tt>. Fully qualified names
like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
<tt>*_error</tt> in the std lib is usually an exception class name.
</td>
</tr>

<tr>
<td><tt>generic_err</tt></td>
<td>
A bit less longish. The category could be <tt>generic_category</tt>. Fully
qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
</td>
</tr>

<tr>
<td><tt>gen_err</tt></td>
<td>
Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
names like <tt>std::gen_err::not_enough_memory</tt> read well.
</td>
</tr>

<tr>
<td><tt>generr</tt></td>
<td>
Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
names like <tt>std::generr::not_enough_memory</tt> read well.
</td>
</tr>

<tr>
<td><tt>error</tt></td>
<td>
Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
this general a name?
</td>
</tr>

<tr>
<td><tt>err</tt></td>
<td>
Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
it seems fairly intuitive.
Problem: <tt>err</tt> is used throughout the standard library as an argument name
and in examples as a variable name; it seems too confusing to add yet
another use of the name.
</td>
</tr>

<tr>
<td><tt>errc</tt></td>
<td>
Short enough. The "c" stands for "constant". The category could be
<tt>generic_category</tt>. Fully qualified names like
<tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
</td>
</tr>
</tbody></table>





<hr>
<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
<p><b>Section:</b> 20.9.9.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
</p>

<blockquote>
<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
</blockquote>

<p>
There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
deleter is called with a NULL pointer, and this is probably not what's
intended (the destructor avoids calling the deleter with 0.)
</p>

<p>
Two, the special check for <tt>get() == p</tt> is generally not needed and such a
situation usually indicates an error in the client code, which is being
masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
self-resets in 2001 and there were no complaints.
</p>

<p>
One might think that self-resets are necessary for operator= to work; it's specified to perform
</p>

<blockquote><pre>reset( u.release() );
</pre></blockquote>

<p>
and the self-assignment
</p>

<blockquote><pre>p = move(p);
</pre></blockquote>

<p>
might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
performed first, zeroing the stored pointer. In other words, <tt>p.reset(
q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
</p>



<p><b>Proposed resolution:</b></p>

<p>
Change 20.9.9.2.5 [unique.ptr.single.modifiers]:
</p>

<blockquote>
<pre>void reset(T* p = 0);
</pre>
<blockquote>
-4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
</blockquote>
</blockquote>

<p>
Change 20.9.9.3.3 [unique.ptr.runtime.modifiers]:
</p>

<blockquote>
<pre>void reset(T* p = 0);
</pre>
<blockquote>
<p>...</p>
<p>
-2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
<p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors.  I believe the same throws clause
should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add to 20.4.2.1 [tuple.cnstr]:
</p>

<blockquote>
<p>
For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
or assignment of one of the types in <tt>Types</tt> throws an exception.
</p>
</blockquote>





<hr>
<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
p4 (forward) says:
</p>
<blockquote>
<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
</blockquote>

<p>
First of all, lvalue-ness and rvalue-ness are properties of an expression,
not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
Second, the phrase says exactly what the core language wording says for
folding references in 14.3.1 [temp.arg.type]/p4  and for function return values
in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
at most be a note with cross-references to those sections.)
</p>
<p>
The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
In my opinion, this is a category error:  "<tt>int&amp;</tt>" is a type, "lvalue" is a
property of an expression, orthogonal to its type.  (Btw, expressions cannot
have reference type, ever.)
</p>
<p>
Similar with move:
</p>
<blockquote>
Return type: an rvalue.
</blockquote>
<p>
is just wrong and also redundant.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.3.3 [forward] as indicated:
</p>

<blockquote>
<pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
</pre>

<blockquote>
<p>...</p>
<p>
<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
</p>
<p>...</p>
<p>
-7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
<del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
</p>
</blockquote>

<pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
</pre>

<blockquote>
<p>...</p>
<p>
<del><i>Return type:</i>  an rvalue.</del>
</p>
</blockquote>

</blockquote>






<hr>
<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
<p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-02-28 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
overload of <code>std::swap</code> for array types:
</p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
</pre>
<p></p>

<p>
It became apparent to me that this overload is missing, when I considered how to write a swap
function for a generic wrapper class template.
(Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
Please look at the following template, <code>W</code>, and suppose that is intended to be a very
<em>generic</em> wrapper:
</p><pre>template&lt;class T&gt; class W {
public:
   T data;
};
</pre>
Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
<em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
whose element type is CopyConstructible and CopyAssignable.
Still it is recommended to add a <em>custom</em> swap function template to such a class template,
for the sake of efficiency and exception safety.
(E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
swap</em>.)
This function template is typically written as follows:
<pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
  using std::swap;
  swap(x.data, y.data);
}
</pre>
Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
allow calling the custom swap function that was especially written for <code>W</code>!
<pre>W&lt;std::string[8]&gt; w1, w2;  // Two objects of a Swappable type.
std::swap(w1, w2);  // Well-defined, but inefficient.
using std::swap;
swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
</pre>

<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
<code>std::string[8]</code>, which is not supported by the Standard Library.
This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
This swap function should be implemented in terms of swapping the elements of the arrays, so that
it would be non-throwing for arrays whose element types have a non-throwing swap.
<p></p>

<p>
Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
means of recursion.
</p>

<p>
For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add an extra condition to the definition of Swappable requirements [swappable] in 20.2.1 [utility.arg.requirements]:
</p>
<blockquote>
- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
</blockquote>
<p>
Add the following to 25.3.3 [alg.swap]:
</p>
<blockquote>
<pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
</pre>
<blockquote>
<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
</blockquote>
<blockquote>
<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
</blockquote>
</blockquote>





<hr>
<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
<p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-03-01 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The recent draft (as well as the original proposal n2072) uses an
operational semantic
for <tt>get_money</tt> ([ext.manip]/4) and <tt>put_money</tt> ([ext.manip]/6), which uses
</p>

<blockquote><pre>istreambuf_iterator&lt;charT&gt;
</pre></blockquote>

<p>
and
</p>

<blockquote><pre>ostreambuf_iterator&lt;charT&gt;
</pre></blockquote>

<p>
resp, instead of the iterator instances, with explicitly provided
traits argument (The operational semantic defined by <tt>f</tt> is also traits
dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
</p>
<p>
The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic 
where additional to the problem we
have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
<tt>istreambuf_iterator</tt>).
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
This appears to be an issue of presentation.
</p>
<p>
We agree with the proposed resolution.
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 27.7.4 [ext.manip]/4 within function <tt>f</tt> replace the first line
</p>

<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) { 
   typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
   ...
</pre></blockquote>

<p>
In 27.7.4 [ext.manip]/5 remove the first template <tt>charT</tt> parameter:
</p>

<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
</pre></blockquote>

<p>
In 27.7.4 [ext.manip]/6 within function <tt>f</tt> replace the first line
</p>

<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) { 
  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
  ...
</pre></blockquote>

<p>
In 27.7.4 [ext.manip]/8 within function <tt>f</tt> replace the first line
</p>

<blockquote><pre>template &lt;class charT, class traits&gt; 
void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) { 
  typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
  ...
</pre></blockquote>

<p>
In 27.7.4 [ext.manip]/10 within function <tt>f</tt> replace the first line
</p>

<blockquote><pre>template &lt;class charT, class traits&gt; 
void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) { 
  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
  ...
</pre></blockquote>

<p>
In 27.7 [iostream.format], Header <tt>&lt;iomanip&gt;</tt> synopsis change:
</p>

<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; T8 put_money(const moneyT&amp; mon, bool intl = false);
</pre></blockquote>





<hr>
<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-03-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<blockquote><pre>#include &lt;utility&gt;

int main()
{
   std::pair&lt;char *, char *&gt; p (0,0);
}
</pre></blockquote>

<p>
I just got a bug report about that, because it's valid C++03, but not
C++0x. The important realization, for me, is that the emplace
proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
issue---didn't cause this break in backward compatibility. The break
actually happened when we added this pair constructor as part of adding
rvalue references into the language, long before variadic templates or
emplace came along:
</p>

<blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
</pre></blockquote>

<p>
Now, concepts will address this issue by constraining that <tt>pair</tt>
constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
"second", e.g. (from
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
</p>

<blockquote><pre>template&lt;class U , class V &gt;
requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
pair(U&amp;&amp; x , V&amp;&amp; y );
</pre></blockquote>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Suggested to resolve using pass-by-value for that case.
</p>
<p>
Side question: Should pair interoperate with tuples? Can construct a
tuple of a pair, but not a pair from a two-element tuple.
</p>
<p>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#885">885</a>.
</p>
</blockquote>

<p><i>[
2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as open. Howard to provide wording.
</blockquote>

<p><i>[
2010-02-06 Howard provided wording.
]</i></p>


<p><i>[
2010-02-09 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>




<p><b>Rationale:</b></p>
<p><i>[
San Francisco:
]</i></p>


<blockquote>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
</blockquote>

<p><i>[
The rationale is obsolete.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add a paragraph to 20.3.5 [pairs]:
</p>

<blockquote>
<pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
</pre>
<blockquote>
<p>
6 <i>Effects:</i> The constructor initializes <tt>first</tt> with
<tt>std::forward&lt;U&gt;(x)</tt> and second with
<tt>std::forward&lt;V&gt;(y)</tt>.
</p>

<p>
<ins><i>Remarks:</i> <tt>U</tt> shall be implicitly convertible to
<tt>first_type</tt> and <tt>V</tt> shall be implicitly convertible to
<tt>second_type</tt>, else this constructor shall not participate in overload
resolution.</ins>
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
<p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2008-02-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Several places in 20.9.10.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
However, that term is nowhere defined. The closest thing we have to a
definition is that the default constructor creates an empty <tt>shared_ptr</tt>
and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
term or stop using it.
</p><p>
</p>
One reason it's not good enough to leave this term up to the reader's
intuition is that, in light of
<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, most readers'
intuitive understanding is likely to be wrong. Intuitively one might
expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
but, whatever the definition is, that isn't it.
<p></p>

<p><i>[
Peter adds:
]</i></p>


<blockquote>
<p>
Or, what is an "empty" <tt>shared_ptr</tt>?
</p>

<ul>
<li>
<p>
Are any other <tt>shared_ptrs</tt> empty?
</p>
<p>
Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
completely specified by the last mutating operation on that instance.
Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
not.
</p>
<blockquote>
(*) If it isn't, this is a legitimate defect.
</blockquote>
</li>

<li>
<p>
For example, is <tt>shared_ptr((T*) 0)</tt> empty?
</p>
<p>
No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
specified to have an <tt>use_count()</tt> of 1.
</p>
</li>

<li>
<p>
What are the properties of an empty <tt>shared_ptr</tt>?
</p>
<p>
The properties of an empty <tt>shared_ptr</tt> can be derived from the
specification. One example is that its destructor is a no-op. Another is
that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
really like.
</p>
</li>

<li>
<p>
We should either clarify this term or stop using it.
</p>
<p>
I don't agree with the imperative tone
</p>
<p>
A clarification would be either a no-op - if it doesn't contradict the
existing wording - or a big mistake if it does.
</p>
<p>
I agree that a clarification that is formally a no-op may add value.
</p>
</li>

<li>
<p>
However, that term is nowhere defined.
</p>
<p>
Terms can be useful without a definition. Consider the following
simplistic example. We have a type <tt>X</tt> with the following operations
defined:
</p>
<blockquote><pre>X x;
X x2(x);
X f(X x);
X g(X x1, X x2);
</pre></blockquote>
<p>
A default-constructed value is green.<br>
A copy has the same color as the original.<br>
<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
</p>

<p>
Given these definitions, you can determine the color of every instance
of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
</p>

<p>
Green and red are "nowhere defined" and completely defined at the same time.
</p>
</li>
</ul>

<p>
Alisdair's wording is fine.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Append the following sentance to 20.9.10.2 [util.smartptr.shared]
</p>
<blockquote>
The <code>shared_ptr</code> class template stores a pointer, usually obtained
via <code>new</code>. <code>shared_ptr</code> implements semantics of
shared ownership; the last remaining owner of the pointer is responsible for
destroying the object, or otherwise releasing  the resources associated with
the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
a pointer is said to be <i>empty</i>.</ins>
</blockquote>





<hr>
<h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
<p><b>Section:</b> 23.4.2 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Move to Open. Alisdair to provide a resolution.
</blockquote>

<p><i>[
Post Summit Daniel provided wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Just after 23.4.2 [vector.bool]/5 add the following prototype and description:
</p>

<blockquote>
<p>
<ins>static void swap(reference x, reference y);</ins>
</p>
<blockquote>
<p>
<ins>-6- <i>Effects:</i> Exchanges the contents of <tt>x</tt> and <tt>y</tt> as-if</ins> by:
</p>
<blockquote><pre><ins>
bool b = x;
x = y;
y = b;
</ins></pre></blockquote>
</blockquote>
</blockquote>





<hr>
<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
<p><b>Section:</b> 20.8.14.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-16 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.inv">issues</a> in [func.wrap.func.inv].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
described in the rvalue core proposal.
</p>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
forwarding can not be obtained because of type erasure. Not everyone
agreed with this diagnosis of forwarding.
</blockquote>

<p><i>[
2009-05-01 Howard adds:
]</i></p>


<blockquote>
<p>
Sebastian Gesemann brought to my attention that the <tt>CopyConstructible</tt>
requirement on <tt>function</tt>'s <tt>ArgTypes...</tt> is an unnecessary
restriction.
</p>

<blockquote><pre>template&lt;Returnable R, <b>CopyConstructible</b>... ArgTypes&gt;
class function&lt;R(ArgTypes...)&gt;
...
</pre></blockquote>

<p>
On further investigation, this complaint seemed to be the same
issue as this one.  I believe the reason <tt>CopyConstructible</tt> was put
on <tt>ArgTypes</tt> in the first place was because of the nature of the
<i>invoke</i> member:
</p>

<blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
R
function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
{
    if (f_ == 0)
        throw bad_function_call();
    return (*f_)(arg...);
}
</pre></blockquote>

<p>
However now with rvalue-refs, "by value" no longer implies <tt>CopyConstructible</tt>
(as Sebastian correctly points out).  If rvalue arguments are supplied, <tt>MoveConstructible</tt>
is sufficient.  Furthermore, the constraint need not be applied in <tt>function</tt>
if I understand correctly.  Rather the client must apply the proper constraints
at the call site.  Therefore, at the very least, I recommend that <tt>CopyConstructible</tt>
be removed from the template class <tt>function</tt>.
</p>

<p>
Furthermore we need to mandate that the <i>invoker</i> is coded as:
</p>

<blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
R
function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
{
    if (f_ == 0)
        throw bad_function_call();
    return (*f_)(<b>std::forward&lt;ArgTypes&gt;(</b>arg<b>)</b>...);
}
</pre></blockquote>

<p>
Note that <tt>ArgTypes&amp;&amp;</tt> (the "perfect forwarding signature") is not 
appropriate here as this is not a deduced context for <tt>ArgTypes</tt>.  Instead
the client's arguments must implicitly convert to the non-deduced <tt>ArgType</tt>
type.  Catching these arguments by value makes sense to enable decay.
</p>

<p>
Next <tt>forward</tt> is used to move the <tt>ArgTypes</tt> as efficiently as
possible, and also with minimum requirements (not <tt>CopyConstructible</tt>)
to the type-erased functor.  For object types, this will be a <tt>move</tt>.  For
reference type <tt>ArgTypes</tt>, this will be a copy.  The end result <em>must</em> be
that the following is a valid program:
</p>

<blockquote><pre>#include &lt;functional&gt;
#include &lt;memory&gt;
#include &lt;cassert&gt;

std::unique_ptr&lt;int&gt;
f(std::unique_ptr&lt;int&gt; p, int&amp; i)
{
    ++i;
    return std::move(p);
}

int main()
{
    int i = 2;
    std::function&lt;std::unique_ptr&lt;int&gt;(std::unique_ptr&lt;int&gt;,
                                       int&amp;&gt; g(f);
    std::unique_ptr&lt;int&gt; p = g(std::unique_ptr&lt;int&gt;(new int(1)), i);
    assert(*p == 1);
    assert(i == 3);
}
</pre></blockquote>

<p><i>[
Tested in pre-concepts rvalue-ref-enabled compiler.
]</i></p>


<p>
In the example above, the first <tt>ArgType</tt> is <tt>unique_ptr&lt;int&gt;</tt>
and the second <tt>ArgType</tt> is <tt>int&amp;</tt>.  Both <em>must</em> work!
</p>

</blockquote>

<p><i>[
2009-05-27 Daniel adds:
]</i></p>


<blockquote>
<p>
in the 2009-05-01 comment of above mentioned issue Howard
</p>

<ol type="a">
<li>
Recommends to replace the <tt>CopyConstructible</tt> requirement by a
<tt>MoveConstructible</tt> requirement
</li>
<li>
Says: "Furthermore, the constraint need not be applied in <tt>function</tt> if I
understand correctly. Rather the client must apply the proper constraints
at the call site"
</li>
</ol>
<p>
I'm fine with (a), but I think comment (b) is incorrect, at least in the
sense I read these sentences. Let's look at Howard's example code:
</p>

<blockquote><pre>function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
{
   if (f_ == 0)
       throw bad_function_call();
   return (*f_)(std::forward&lt;ArgTypes&gt;(arg)...);
}
</pre></blockquote>

<p>
In the constrained scope of this <tt>operator()</tt> overload the expression
"<tt>(*f_)(std::forward&lt;ArgTypes&gt;(arg)...)</tt>" must be valid. How can it
do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>?
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Leave this open and wait until concepts are removed from the Working
Draft so that we know how to write the proposed resolution in terms of
diffs to otherwise stable text.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as open. Howard to provide wording. Howard welcomes any help.
</blockquote>

<p><i>[
2009-12-12 Jonathan Wakely adds:
]</i></p>


<blockquote>
<p>
20.8.14.2 [func.wrap.func] says
</p>

<blockquote>
2  A function object <tt>f</tt> of type <tt>F</tt> is Callable for argument
types <tt>T1, T2, ..., TN</tt> in <tt>ArgTypes</tt> and a return type
<tt>R</tt>, if, given lvalues <tt>t1, t2, ..., tN</tt> of types <tt>T1, T2, ...,
TN</tt>, respectively, <tt>INVOKE (f, t1, t2, ..., tN)</tt> is well formed
(20.7.2) and, if <tt>R</tt> is not <tt>void</tt>, convertible to <tt>R</tt>.
</blockquote>

<p>
N.B. lvalues, which means you can't use <tt>function&lt;R(T&amp;&amp;)&gt;</tt>
or <tt>function&lt;R(unique_ptr&lt;T&gt;)&gt;</tt>
</p>

<p>
I recently implemented rvalue arguments in GCC's <tt>std::function</tt>, all
that was needed was to use <tt>std::forward&lt;ArgTypes&gt;</tt> in a few
places. The example in issue 815 works.
</p>

<p>
I think 815 could be resolved by removing the requirement that the target
function be callable with lvalues.  Saying <tt>ArgTypes</tt> need to be
<tt>CopyConstructible</tt> is wrong, and IMHO saying <tt>MoveConstructible</tt>
is unnecessary, since the by-value signature implies that already, but if it is
needed it should only be on <tt>operator()</tt>, not the whole class (you could
in theory instantiate <tt>std::function&lt;R(noncopyable)&gt;</tt> as long as
you don't invoke the call operator.)
</p>

<p>
I think defining invocation in terms of <tt>INVOKE</tt> already implies perfect
forwarding, so we don't need to say explicitly that <tt>std::forward</tt> should
be used (N.B. the types that are forwarded are those in <tt>ArgTypes</tt>, which
can differ from the actual parameter types of the target function.  The actual
parameter types have gone via type erasure, but that's not a problem - IMHO
forwarding the arguments as <tt>ArgTypes</tt> is the right thing to do anyway.)
</p>

<p>
Is it sufficient to simply replace "lvalues" with "values"? or do we need to say
something like "lvalues when <tt>Ti</tt> is an lvalue-reference and rvalues
otherwise"?  I prefer the former, so I propose the following resolution for 815:
</p>

<p>
Edit 20.8.14.2 [func.wrap.func] paragraph 2:
</p>

<blockquote>
2  A function object <tt>f</tt> of type <tt>F</tt> is Callable for argument
types <tt>T1, T2, ..., TN</tt> in <tt>ArgTypes</tt> and a return type
<tt>R</tt>, if, given <del>l</del>values <tt>t1, t2, ..., tN</tt> of types
<tt>T1, T2, ..., TN</tt>, respectively, <tt>INVOKE (f, t1, t2, ..., tN)</tt> is
well formed (20.7.2) and, if <tt>R</tt> is not <tt>void</tt>, convertible to
<tt>R</tt>.
</blockquote>
</blockquote>

<p><i>[
2009-12-12 Daniel adds:
]</i></p>


<blockquote>
I don't like the reduction to "values" and prefer the alternative solution
suggested using "lvalues when Ti is an lvalue-reference and rvalues otherwise".
The reason why I dislike the shorter version is based on different usages of
"values" as part of defining the semantics of requirement tables via
expressions. E.g. 20.2.1 [utility.arg.requirements]/1 says "<tt>a</tt>,
<tt>b</tt>, and <tt>c</tt> are values of type <tt>const T;</tt>" or similar in
23.2.1 [container.requirements.general]/4 or /14 etc. My current reading
of all these parts is that <em>both</em> rvalues and lvalues are required to be
supported, but this interpretation would violate the intention of the suggested
fix of #815, if I correctly understand Jonathan's rationale.
</blockquote>

<p><i>[
2009-12-12 Howard adds:
]</i></p>


<blockquote>
<blockquote>
"lvalues when Ti is an lvalue-reference and rvalues otherwise"
</blockquote>
<p>
doesn't quite work here because the <tt>Ti</tt> aren't deduced.  They are
specified by the <tt>function</tt> type.  <tt>Ti</tt> might be <tt>const
int&amp;</tt> (an lvalue reference) and a valid <tt>ti</tt> might be <tt>2</tt>
(a non-const rvalue).  I've taken another stab at the wording using
"expressions" and "bindable to".
</p>
</blockquote>

<p><i>[
2010-02-09 Wording updated by Jonathan, Ganesh and Daniel.
]</i></p>


<p><i>[
2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-02-10 Daniel opens to improve wording.
]</i></p>


<p><i>[
2010-02-11 This issue is now addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>.
]</i></p>


<p><i>[
2010-02-12 Moved to Tentatively NAD Editorial after 5 positive votes on
c++std-lib.  Rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Edit 20.8.14.2 [func.wrap.func] paragraph 2:
</p>

<blockquote>
<p>
2  A function object <tt>f</tt> of type <tt>F</tt> is Callable for argument
types <del><tt>T1, T2, ..., TN</tt> in</del> <tt>ArgTypes</tt> and <del>a</del>
return type <tt>R</tt><del>,</del> if<del>, given lvalues <tt>t1, t2, ...,
tN</tt> of types <tt>T1, T2, ..., TN</tt>, respectively,</del> <ins>the
expression</ins> <tt><i>INVOKE</i>(f, <ins>declval&lt;ArgTypes&gt;()...,
R</ins><del>t1, t2, ..., tN</del>)</tt><ins>, considered as an unevaluated
operand (5 [expr]),</ins> is well formed (20.7.2)<del> and, if
<tt>R</tt> is not <tt>void</tt>, convertible to <tt>R</tt></del>.
</p>

</blockquote>





<hr>
<h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
<p><b>Section:</b> 20.8.10.1.2 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-02-08 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
</p>
<p>
However, no guarantees are provided for the copy ctor of the functor
returned by <tt>bind()</tt>.  (It's guaranteed to have a copy ctor, which can
throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4.
Everything without an exception-specification may throw
implementation-defined exceptions unless otherwise specified, C++03
17.4.4.8/3.)
</p>
<p>
Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
to cover both calling <tt>bind()</tt> and copying the returned functor?
</p>

<p><i>[
Howard adds:
]</i></p>


<blockquote>
<tt>tuple</tt> construction should probably have a similar guarantee.
</blockquote>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Howard to provide wording.
</blockquote>

<p><i>[
Post Summit, Anthony provided wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Part of all of this issue appears to be rendered moot
by the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a> (q.v.).
We recommend the issues be considered simultaneously
(or possibly even merged)
to ensure there is no overlap.
Move to Open, and likewise for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a> (see below). Leave Open.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready. Decoupling from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>.
</blockquote>

<p><i>[
2010-02-11 Moved from Ready to Tentatively NAD Editorial, rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
This issue is solved as proposed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#817">817</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add a new sentence to the end of paragraphs 2 and 4 of 20.8.10.1.2 [func.bind.bind]:
</p>

<blockquote>
<p>
-2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable&lt;F cv,V1, V2, ..., VN&gt;::result_type)</tt>, where <i>cv</i>
represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
<tt>v1, v2, ..., vN</tt> are determined as specified below.
<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
in <tt>BoundArgs...</tt> throw an exception.</ins>
</p>
<p>...</p>
<p>
-5- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
in <tt>BoundArgs...</tt> throw an exception.</ins>
</p>

</blockquote>





<hr>
<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
<p><b>Section:</b> 20.8.10.1.2 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US 72, JP 38 and DE 21</b></p>

<p>
The functor returned by <tt>bind()</tt> should have a move constructor that
requires only move construction of its contained functor and bound arguments.
That way move-only functors can be passed to objects such as <tt>thread</tt>.
</p>
<p>
This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#816">816</a>.
</p>

<p>
US 72:
</p>

<blockquote>
<tt>bind</tt> should support move-only functors and bound arguments.
</blockquote>

<p>
JP 38:
</p>

<blockquote>
<p>
add the move requirement for bind's return type.
</p>
<p>
For example, assume following <tt>th1</tt> and <tt>th2</tt>,
</p>

<blockquote><pre>void f(vector&lt;int&gt; v) { }

vector&lt;int&gt; v{ ... };
thread th1([v]{ f(v); });
thread th2(bind(f, v));
</pre></blockquote>

<p>
When function object are set to thread, <tt>v</tt> is moved to <tt>th1</tt>'s lambda
expression in a Move Constructor of lambda expression because <tt>th1</tt>'s lambda
expression has a Move Constructor. But <tt>bind</tt> of <tt>th2</tt>'s
return type doesn't have the requirement of Move, so it may not
moved but copied.
</p>
<p>
Add the requirement of move to get rid of this useless copy.
</p>
<p>
And also, add the <tt>MoveConstructible</tt> as well as <tt>CopyConstructible</tt>.
</p>
</blockquote>

<p>
DE 21
</p>

<blockquote>
The specification for bind claims twice that "the values and types for
the bound arguments v1, v2, ..., vN are determined as specified below".
No such specification appears to exist.
</blockquote>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Howard to provide wording.
</blockquote>

<p><i>[
Post Summit Alisdair and Howard provided wording.
]</i></p>


<blockquote>
<p>
Several issues are being combined in this resolution.  They are all touching the
same words so this is an attempt to keep one issue from stepping on another, and
a place to see the complete solution in one place.
</p>

<ol>
<li>
<tt>bind</tt> needs to be "moved".
</li>
<li>
20.8.10.1.2 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
</li>
<li>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> argues for a way to pass by &amp;&amp; for
efficiency but retain the decaying behavior of pass by value for the
<tt>thread</tt> constructor.  That same solution is applicable here.
</li>
</ol>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We were going to recommend moving this issue to Tentatively Ready
until we noticed potential overlap with issue 816 (q.v.).
</p>
<p>
Move to Open,
and recommend both issues be considered together
(and possibly merged).
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
The proposed resolution uses concepts. Leave Open.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as Open. Howard to provide deconceptified wording.
</blockquote>

<p><i>[
2009-11-07 Howard updates wording.
]</i></p>


<p><i>[
2009-11-15 Further updates by Peter, Chris and Daniel.
]</i></p>


<p><i>[
Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.8 [function.objects] p2:
</p>

<blockquote><pre>template&lt;class F<del>n</del>, class... <del>Types</del> <ins>BoundArgs</ins>&gt;
  <i>unspecified</i> bind(F<del>n</del><ins>&amp;&amp;</ins>, <del>Types</del> <ins>BoundArgs&amp;&amp;</ins>...);
template&lt;class R, class F<del>n</del>, class... <del>Types</del> <ins>BoundArgs</ins>&gt;
  <i>unspecified</i> bind(F<del>n</del><ins>&amp;&amp;</ins>, <del>Types</del> <ins>BoundArgs&amp;&amp;</ins>...);
</pre></blockquote>

<p>
Change 20.8.2 [func.require]:
</p>

<blockquote>
<p>
4 Every call wrapper (20.8.1 [func.def]) shall be
<tt><del>Copy</del><ins>Move</ins>Constructible</tt>. A <i>simple call
wrapper</i> is a call wrapper that is <ins><tt>CopyConstructible</tt> and</ins>
<tt>CopyAssignable</tt> and whose copy constructor<ins>, move constructor</ins> and assignment operator do not
throw exceptions. A <i>forwarding call wrapper</i> is a call wrapper that can be
called with an argument list. [<i>Note:</i> in a typical implementation
forwarding call wrappers have an overloaded function call operator of the form
</p>
<blockquote><pre>template&lt;class... <del>ArgTypes</del><ins>UnBoundsArgs</ins>&gt;
R operator()(<del>ArgTypes</del><ins>UnBoundsArgs</ins>&amp;&amp;... <ins>unbound_</ins>args) cv-qual;
</pre></blockquote>
<p>
� <i>end note</i>]
</p>
</blockquote>

<p>
Change 20.8.10.1.2 [func.bind.bind]:
</p>

<blockquote>
<p><ins>
Within this clause:
</ins></p>

<ul>
<li><ins>
Let <tt>FD</tt> be a synonym for the type <tt>decay&lt;F&gt;::type</tt>.
</ins></li>
<li><ins>
Let <tt>fd</tt> be an lvalue of type <tt>FD</tt> constructed from
<tt>std::forward&lt;F&gt;(f)</tt>.
</ins></li>
<li><ins>
Let <tt>Ti</tt> be a synonym for the i<sup><i>th</i></sup> type in the
template parameter pack <tt>BoundArgs</tt>.
</ins></li>
<li><ins>
Let <tt>TiD</tt> be a synonym for the type <tt>decay&lt;Ti&gt;::type</tt>.
</ins></li>
<li><ins>
Let <tt>ti</tt> be the i<sup><i>th</i></sup> argument in the function parameter
pack <tt>bound_args</tt>.
</ins></li>
<li><ins>
Let <tt>tid</tt> be an lvalue of type <tt>TiD</tt> constructed from
<tt>std::forward&lt;Ti&gt;(ti)</tt>.
</ins></li>
<li><ins>
Let <tt>Uj</tt> be the j<sup><i>th</i></sup> deduced type of the <tt>UnBoundArgs&amp;&amp;...</tt>
parameter of the <tt>operator()</tt> of the forwarding call wrapper.
</ins></li>
<li><ins>
Let <tt>uj</tt> be the j<sup><i>th</i></sup> argument associated with <tt>Uj</tt>.
</ins></li>
</ul>

<pre>template&lt;class F, class... BoundArgs&gt;
  <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
</pre>

<blockquote>
<p>
-1- <i>Requires:</i>
<ins><tt>is_constructible&lt;FD, F&gt;::value</tt>
shall be <tt>true</tt>.</ins>
<ins>For each <tt>Ti</tt> in <tt>BoundArgs</tt>,
<tt>is_constructible&lt;TiD, Ti&gt;::value</tt> shall be
<tt>true</tt></ins>.
<del><tt>F</tt> and each <tt>Ti</tt> in
<tt>BoundArgs</tt> shall be CopyConstructible.</del>
<tt><i>INVOKE</i>(f<ins>d</ins>, w1, w2, ..., wN)</tt> (20.8.2 [func.require]) shall be a valid expression for some values
<i>w1, w2, ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
</p>
<p>
-2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak
result type (20.8.2 [func.require]). The effect of <tt>g(u1, u2,
..., uM)</tt> shall be <tt><i>INVOKE</i>(f<ins>d</ins>, v1, v2, ..., vN,
result_of&lt;F<ins>D</ins> <i>cv</i> (V1, V2, ..., VN)&gt;::type)</tt>, where
<i>cv</i> represents the <i>cv</i>-qualifiers of <tt>g</tt> and the
values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are
determined as specified below.
<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
exception if and only if the corresponding constructor of <tt>FD</tt> or of any of the types
<tt>TiD</tt> throws an exception.</ins>
</p>
<p>
-3- <i>Throws:</i> Nothing unless the <del>copy</del>
construct<ins>ion</ins><del>or</del> of
<tt><del>F</del><ins>fd</ins></tt> or of one of the <ins>values
<tt>tid</tt></ins> <del>types in the <tt>BoundArgs...</tt> pack
expansion</del> throws an exception.
</p>
<p>
<ins>
<i>Remarks:</i> The <i>unspecified</i> return type shall satisfy the
requirements of <tt>MoveConstructible</tt>.  If all of <tt>FD</tt> and
<tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt> then
the <i>unspecified</i> return type shall satisfy the requirements of
<tt>CopyConstructible</tt>. [<i>Note:</i> This implies that all of
<tt>FD</tt> and <tt>TiD</tt> shall be <tt>MoveConstructible</tt> �
<i>end note</i>]
</ins>
</p>
</blockquote>

<pre>template&lt;class R, class F, class... BoundArgs&gt;
  <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
</pre>

<blockquote>
<p>
-4- <i>Requires:</i>
<ins><tt>is_constructible&lt;FD, F&gt;::value</tt>
shall be <tt>true</tt>.</ins>
<ins>For each <tt>Ti</tt> in <tt>BoundArgs</tt>,
<tt>is_constructible&lt;TiD, Ti&gt;::value</tt> shall be
<tt>true</tt></ins>.
<del><tt>F</tt> and each <tt>Ti</tt> in
<tt>BoundArgs</tt> shall be CopyConstructible.</del>
<tt><i>INVOKE</i>(f<ins>d</ins>, w1,
w2, ..., wN)</tt> shall be a valid expression for some values <i>w1, w2,
..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
</p>
<p>
-5- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested
type <tt>result_type</tt> defined as a synonym for <tt>R</tt>. The
effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f<ins>d</ins>, v1,
v2, ..., vN, R)</tt>, where the values and types of the bound arguments
<tt>v1, v2, ..., vN</tt> are determined as specified below.
<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
exception if and only if the corresponding constructor of <tt>FD</tt> or of any of the types
<tt>TiD</tt> throws an exception.</ins>
</p>
<p>
-6- <i>Throws:</i> Nothing unless the <del>copy</del>
construct<ins>ion</ins><del>or</del> of
<tt><del>F</del><ins>fd</ins></tt> or of one of the <ins>values
<tt>tid</tt></ins> <del>types in the <tt>BoundArgs...</tt> pack
expansion</del> throws an exception.
</p>
<p>
<ins>
<i>Remarks:</i> The <i>unspecified</i> return type shall satisfy the
requirements of <tt>MoveConstructible</tt>.  If all of <tt>FD</tt> and
<tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt> then
the <i>unspecified</i> return type shall satisfy the requirements of
<tt>CopyConstructible</tt>. [<i>Note:</i> This implies that all of
<tt>FD</tt> and <tt>TiD</tt> shall be <tt>MoveConstructible</tt> �
<i>end note</i>]
</ins>
</p>
</blockquote>

<p>
-7- The values of the <i>bound arguments</i> <tt>v1, v2, ..., vN</tt> and
their corresponding types <tt>V1, V2, ..., VN</tt> depend on the type<ins>s
<tt>TiD</tt> derived from</ins>
<del>of the corresponding argument <tt>ti</tt> in <tt>bound_args</tt> of type
<tt>Ti</tt> in <tt>BoundArgs</tt> in</del>
the call to <tt>bind</tt> and the
<i>cv</i>-qualifiers <i>cv</i> of the call wrapper <tt>g</tt> as
follows:
</p>

<ul>
<li>
if <tt><del>ti</del> <ins>TiD</ins></tt> is <del>of type</del>
<tt>reference_wrapper&lt;T&gt;</tt> the argument is
<tt>ti<ins>d</ins>.get()</tt> and its type <tt>Vi</tt> is <tt>T&amp;</tt>;
</li>
<li>
if the value of
<tt><del>std::</del>is_bind_expression&lt;Ti<ins>D</ins>&gt;::value</tt> is
<tt>true</tt> the argument is <tt>ti<ins>d</ins>(<ins>std::forward&lt;Uj&gt;(uj)...</ins> <del>u1, u2, ..., uM</del>)</tt>
and its type <tt>Vi</tt> is <tt>result_of&lt;Ti<ins>D</ins> <i>cv</i>
(<ins>Uj...</ins> <del>U1&amp;, U2&amp;, ..., UM&amp;</del>)&gt;::type</tt>;
</li>
<li>
if the value <tt>j</tt> of
<tt><del>std::</del>is_placeholder&lt;Ti<ins>D</ins>&gt;::value</tt> is not zero
the argument is <tt>std::forward&lt;Uj&gt;(uj)</tt> and its type
<tt>Vi</tt> is <tt>Uj&amp;&amp;</tt>;
</li>
<li>
otherwise the value is <tt>ti<ins>d</ins></tt> and its type <tt>Vi</tt>
is <tt>Ti<ins>D</ins> <i>cv</i> &amp;</tt>.
</li>
</ul>

</blockquote>






<hr>
<h3><a name="818"></a>818. wording for memory ordering</h3>
<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
29.3 [atomics.order] p1 says in the table that
</p>

<blockquote>
<table border="1">
<tbody><tr>
<th>Element</th><th>Meaning</th>
</tr>
<tr>
<td><tt>memory_order_acq_rel</tt></td>
<td>the operation has both acquire and release semantics</td>
</tr>
</tbody></table>
</blockquote>

<p>
To my naked eye, that seems to imply that even an atomic read has both
acquire and release semantics.
</p>

<p>
Then, p1 says in the table:
</p>

<blockquote>
<table border="1">
<tbody><tr>
<th>Element</th><th>Meaning</th>
</tr>
<tr>
<td><tt>memory_order_seq_cst</tt></td>
<td>the operation has both acquire and release semantics,
    and, in addition, has sequentially-consistent operation ordering</td>
</tr>
</tbody></table>
</blockquote>

<p>
So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
constraints.
</p>

<p>
I'm then reading p2, where it says:
</p>

<blockquote>
The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
are release operations on the affected locations.
</blockquote>

<p>
That seems to imply that atomic reads only have acquire semantics.  If that
is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
load/store operations as well?
</p>

<p>
Also, the table in p1 contains phrases with "thus" that seem to indicate
consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
normative text, for the fear of redundant or inconsistent specification with
the other normative text.
</p>

<p>
Double-check 29.6 [atomics.types.operations] that each
operation clearly says whether it's a load or a store operation, or
both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
</p>

<p>
29.3 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
1.10 [intro.multithread], it's just used in notes there.
</p>

<p>
And why does 29.6 [atomics.types.operations] p9 for "load" say:
</p>


<blockquote>
<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
nor <tt>memory_order_acq_rel</tt>.
</blockquote>

<p>
(Since this is exactly the same restriction as for "store", it seems to be a typo.)
</p>

<p>
And then: 29.6 [atomics.types.operations] p12:
</p>

<blockquote>
These operations are read-modify-write operations in the sense of the
"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
evaluation that produced the input value synchronize with any evaluation
that reads the updated value.
</blockquote>

<p>
This is redundant with 1.10 [intro.multithread], see above for the reasoning.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Boehm: "I don't think that this changes anything terribly substantive,
but it improves the text."
</p>
<p>
Note that "Rephrase the table in as [sic] follows..." should read
"Replace the table in [atomics.order] with the following...."
</p>
<p>
The proposed resolution needs more work. Crowl volunteered to address
all of the atomics issues in one paper.
</p>

<p>
This issue is addressed in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
edit 29.3 [atomics.order], paragraph 1 as follows.
</p>

<blockquote>
<p>
The enumeration <code>memory_order</code>
specifies the detailed regular (non-atomic) memory synchronization order
as defined in <del>Clause 1.7</del> <ins>section 1.10</ins>
and may provide for operation ordering.
Its enumerated values and their meanings are as follows:
</p>
<blockquote>
<dl>
<dt><ins>For <code>memory_order_relaxed</code>,</ins></dt>
<dd><ins>no operation orders memory.</ins></dd>
<dt><ins>For <code>memory_order_release</code>,
<code>memory_order_acq_rel</code>,
and <code>memory_order_seq_cst</code>,</ins></dt>
<dd><ins>a store operation performs a release operation
on the affected memory location.</ins></dd>
<dt><ins>For <code>memory_order_consume</code>,</ins></dt>
<dd><ins>a load operation performs a consume operation
on the affected memory location.</ins></dd>
<dt><ins>For <code>memory_order_acquire</code>,
<code>memory_order_acq_rel</code>,
and <code>memory_order_seq_cst</code>,</ins></dt>
<dd><ins>a load operation performs an acquire operation
on the affected memory location.</ins></dd>
</dl>
</blockquote>
</blockquote>

<p>
remove table 136 in 29.3 [atomics.order].
</p>

<blockquote>
<table border="1">
<caption><del>Table 136 � memory_order effects</del></caption>
<tbody><tr><th><del>Element</del></th><th><del>Meaning</del></th></tr>
<tr><td valign="top"><del><code>memory_order_relaxed</code></del></td>
<td valign="top"><del>the operation does not order memory</del></td></tr>
<tr><td valign="top"><del><code>memory_order_release</code></del></td>
<td valign="top"><del>the operation
performs a release operation on the affected memory location,
thus making regular memory writes visible to other threads
through the atomic variable to which it is applied</del></td></tr>
<tr><td valign="top"><del><code>memory_order_acquire</code></del></td>
<td valign="top"><del>the operation
performs an acquire operation on the affected memory location,
thus making regular memory writes in other threads
released through the atomic variable to which it is applied
visible to the current thread</del></td></tr>
<tr><td valign="top"><del><code>memory_order_consume</code></del></td>
<td valign="top"><del>the operation
performs a consume operation on the affected memory location,
thus making regular memory writes in other threads
released through the atomic variable to which it is applied
visible to the regular memory reads
that are dependencies of this consume operation.</del></td></tr>
<tr><td valign="top"><del><code>memory_order_acq_rel</code></del></td>
<td valign="top"><del>the operation has both acquire and release semantics</del></td></tr>
<tr><td valign="top"><del><code>memory_order_seq_cst</code></del></td>
<td valign="top"><del>the operation has both acquire and release semantics,
and, in addition, has sequentially-consistent operation ordering</del></td></tr>
</tbody></table>
</blockquote>

<p>
edit 29.3 [atomics.order], paragraph 2 as follows.
</p>

<blockquote>
<p>
<del>The <code>memory_order_seq_cst</code> operations that load a value
are acquire operations on the affected locations.
The <code>memory_order_seq_cst</code> operations that store a value
are release operations on the affected locations.
In addition, in a consistent execution,
there</del> <ins>There</ins> <del>must be</del> <ins>is</ins>
a single total order <var>S</var>
on all <code>memory_order_seq_cst</code> operations,
consistent with the happens before order
and modification orders for all affected locations,
such that each <code>memory_order_seq_cst</code> operation
observes either the last preceding modification
according to this order <var>S</var>,
or the result of an operation that is not <code>memory_order_seq_cst</code>.
[<i>Note:</i>
Although it is not explicitly required that <var>S</var> include locks,
it can always be extended to an order
that does include lock and unlock operations,
since the ordering between those
is already included in the happens before ordering.
�<i>end note</i>]
</p>
</blockquote>






<hr>
<h3><a name="819"></a>819. rethrow_if_nested</h3>
<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
got it quite right.
</p>

<p>
The current wording says:
</p>

<blockquote>
<pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
</pre>
<blockquote>
<p>
<i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
is publicly derived from <tt>nested_exception</tt>.
</p>
</blockquote>
</blockquote>

<p>
This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
required to be sure.  Unfortunately, if <tt>e</tt> is dynamically but not statically
derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Alisdair was volunteered to provide wording.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave as Open. Alisdair to provide wording.
</blockquote>

<p><i>[
2009-11-09 Alisdair provided wording.
]</i></p>


<p><i>[
2010-03-10 Dietmar updated wording.
]</i></p>


<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to Ready for Pittsburgh.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 18.8.6 [except.nested], p8:
</p>

<blockquote><pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
</pre>
<blockquote>
-8- <i>Effects:</i> <del>Calls <tt>e.rethrow_nested()</tt>
o</del><ins>O</ins>nly if <ins>the dynamic type of</ins> <tt>e</tt> is
publicly <ins>and unambiguously</ins> derived from
<tt>nested_exception</tt> <ins>this calls
<tt>dynamic_cast&lt;const nested_exception&amp;&gt;(e).rethrow_nested()</tt></ins>.
</blockquote>
</blockquote>






<hr>
<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-03-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As of N2521, the Working Paper appears to be silent about what
<tt>current_exception()</tt> should do if it tries to copy the currently handled
exception and its copy constructor throws.  18.8.5 [propagation]/7 says "If the
function needs to allocate memory and the attempt fails, it returns an
<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
doesn't say anything about what should happen if memory allocation
succeeds but the actual copying fails.
</p>

<p>
I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
object that refers to an instance of the copy ctor's thrown exception
(but if that has a throwing copy ctor, an infinite loop can occur), or
(3) call <tt>terminate()</tt>.
</p>

<p>
I believe that <tt>terminate()</tt> is the most reasonable course of action, but
before we go implement that, I wanted to raise this issue.
</p>

<p><i>[
Peter's summary:
]</i></p>


<blockquote>
<p>
The current practice is to not have throwing copy constructors in
exception classes, because this can lead to <tt>terminate()</tt> as described in
15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
consistent and does not introduce any new problems.
</p>

<p>
However, the resolution of core issue 475 may relax this requirement:
</p>

<blockquote>
The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
should not be called if that constructor exits with an exception.
</blockquote>

<p>
Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
(3) doesn't seem reasonable as it is deemed too drastic a response in a
recoverable situation.
</p>

<p>
Option (2) cannot be adopted by itself, because a potential infinite
recursion will need to be terminated by one of the other options.
</p>

</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Add the following paragraph after 18.8.5 [propagation]/7:
</p>

<blockquote>
<p>
<i>Returns (continued):</i> If the attempt to copy the current exception
object throws an exception, the function returns an <tt>exception_ptr</tt> that
refers to the thrown exception or, if this is not possible, to an
instance of <tt>bad_exception</tt>.
</p>
<p>
[<i>Note:</i> The copy constructor of the thrown exception may also fail, so
the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
infinite recursion. <i>-- end note.</i>]
</p>
</blockquote>



<p><b>Rationale:</b></p>
<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Pete: there may be an implied assumption in the proposed wording that
current_exception() copies the existing exception object; the
implementation may not actually do that.
</p>
<p>
Pete will make the required editorial tweaks to rectify this.
</p>
</blockquote>





<hr>
<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
<p><b>Section:</b> 20.9.9.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following:
</p>

<blockquote>
<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
</pre>

<p>
-1- <i>Requires:</i> Does not accept pointer types which are convertible
to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
required). [<i>Note:</i> One implementation technique is to create a private
templated overload. <i>-- end note</i>]
</p>
</blockquote>

<p>
This could be cleaned up by mandating the overload as a public deleted
function.  In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
to be a stronger match than the deleted overload. Words...
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add to class template definition in 20.9.9.3 [unique.ptr.runtime]
</p>

<blockquote>
<pre>// modifiers 
pointer release(); 
void reset(pointer p = pointer()); 
<ins>void reset( nullptr_t );</ins>
<ins>template&lt; typename U &gt; void reset( U ) = delete;</ins>
void swap(unique_ptr&amp;&amp; u);
</pre>
</blockquote>

<p>
Update 20.9.9.3.3 [unique.ptr.runtime.modifiers]
</p>

<blockquote>
<pre>void reset(pointer p = pointer());
<ins>void reset(nullptr_t);</ins>
</pre>

<p>
<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
to <tt>pointer</tt> (diagnostic
required). [<i>Note:</i> One implementation technique is to create a private
templated overload. <i>-- end note</i>]</del>
</p>
<p>
<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. 
</p>
<p>...</p>
</blockquote>

<p><i>[
Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (Ready).
]</i></p>






<hr>
<h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2008-04-09 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
N2588 seems to have added an <tt>operator()</tt> member function to the
<tt>identity&lt;&gt;</tt> helper in 20.3.3 [forward].  I believe this change makes it no
longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
</p>

<p>
Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
the member function's presence.
</p>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
</p>
<p>
Alisdair: also consider cv-qualified <tt>void</tt>.
</p>
<p>
Alberto provided proposed wording.
</p>
</blockquote>

<p><i>[
2009-07-30 Daniel reopens:
]</i></p>


<blockquote>
<p>
This issue became closed, because the <tt>ReferentType</tt> requirement
fixed the problem - this is no longer the case. In retrospective it seems
to be that the root of current issues around <tt>std::identity</tt> (823, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>)
is that it was standardized as something very different (an unconditional
type mapper) than traditional usage indicated (a function object that should
derive from <tt>std::unary_function)</tt>, as the SGI definition does. This issue could
be solved, if <tt>std::identity</tt> is removed (one proposal of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>), but until this
has been decided, this issue should remain open. An alternative for
removing it, would be, to do the following:
</p>

<ol type="a">
<li>
<p>
Let <tt>identity</tt> stay as a <em>real</em> function object, which would
now properly
derive from <tt>unary_function</tt>:
</p>

<blockquote><pre>template &lt;class T&gt; struct identity : unary_function&lt;T, T&gt; {
  const T&amp; operator()(const T&amp;) const;
};
</pre></blockquote>
</li>

<li>
<p>
Invent (if needed) a generic type wrapper (corresponding to concept
<tt>IdentityOf</tt>),
e.g. <tt>identity_of</tt>, and move it's prototype description back to 20.3.3 [forward]:
</p>

<blockquote><pre>template &lt;class T&gt; struct identity_of {
  typedef T type;
};
</pre></blockquote>

<p>
and adapt the <tt>std::forward</tt> signature to use <tt>identity_of</tt>
instead of <tt>identity</tt>.
</p>
</li>
</ol>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Mark as <del>NAD Editorial</del><ins>Resolved</ins>, fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#939">939</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change definition of <tt>identity</tt> in 20.3.3 [forward], paragraph 2, to:
</p>

<blockquote><pre>template &lt;class T&gt;  struct identity {
    typedef T type;

    <ins>requires ReferentType&lt;T&gt;</ins>
      const T&amp; operator()(const T&amp; x) const;
  };
</pre></blockquote>
<p>...</p>
<blockquote><pre>  <ins>requires ReferentType&lt;T&gt;</ins>
    const T&amp; operator()(const T&amp; x) const;
</pre></blockquote>


<p><b>Rationale:</b></p>
<p>
The point here is to able to write <tt>T&amp;</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
precisely the concept that guarantees so, according to N2677
(Foundational concepts). Because of this, it seems preferable than an
explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
in Sophia. In particular, Daniel remarked that there may be types other
than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
</p>





<hr>
<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
21.3 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
for <tt>basic_string</tt>.
</p>

<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
 basic_ostream&lt;charT, traits&gt;&amp;
   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
</pre></blockquote>

<p>
The definition in 21.4.8.9 [string.io] lists two:
</p>

<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
 basic_ostream&lt;charT, traits&gt;&amp;
   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);

template&lt;class charT, class traits, class Allocator&gt;
 basic_ostream&lt;charT, traits&gt;&amp;
   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
</pre></blockquote>

<p>
I believe the synopsis in 21.3 [string.classes] is correct, and the first of the two
signatures in 21.4.8.9 [string.io] should be deleted.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Delete the first of the two signatures in 21.4.8.9 [string.io]:
</p>

<blockquote><pre><del>template&lt;class charT, class traits, class Allocator&gt;
 basic_ostream&lt;charT, traits&gt;&amp;
   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);</del>

template&lt;class charT, class traits, class Allocator&gt;
 basic_ostream&lt;charT, traits&gt;&amp;
   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
</pre></blockquote>





<hr>
<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
<p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-11 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
<tt>weak_ptr</tt> and <tt>enable_shared_from_this</tt>) <tt>constexpr</tt>? This would enable
static initialization for <tt>shared_ptr</tt> variables, eliminating another
unfair advantage of raw pointers.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
It's not clear to us that you can initialize a pointer with the literal
0 in a constant expression. We need to ask CWG to make sure this works.
Bjarne has been appointed to do this.
</p>
<p>
Core got back to us and assured as that <tt>nullptr</tt> would do the job
nicely here.
</p>
</blockquote>

<p><i>[
2009-05-01 Alisdair adds:
]</i></p>


<blockquote>
<p>
I don't believe that <tt>constexpr</tt> will buy anything in this case.
<tt>shared_ptr/weak_ptr/enable_shared_from_this</tt> cannot be literal types as they
have a non-trivial copy constructor.  As they do not produce literal types,
then the <tt>constexpr</tt> default constructor will <em>not</em> guarantee constant
initialization, and so not buy the hoped for optimization.
</p>
<p>
I recommend referring this back to Core to see if we can get static
initialization for types with <tt>constexpr</tt> constructors, even if they are not
literal types.  Otherwise this should be closed as NAD.
</p>
</blockquote>

<p><i>[
2009-05-26 Daniel adds:
]</i></p>


<blockquote>
If Alisdair's 2009-05-01 comment is correct, wouldn't that also make
<tt>constexpr mutex()</tt> useless, because this class has a non-trivial
destructor? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>)
</blockquote>

<p><i>[
2009-07-21 Alisdair adds:
]</i></p>


<blockquote>
<p>
The feedback from core is that this and similar uses of <tt>constexpr</tt>
constructors to force static initialization should be supported.  If
there are any problems with this in the working draught, we should file
core issues.
</p>

<p>
Recommend we declare the default constructor <tt>constexpr</tt> as the issue suggests
(proposed wording added).
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.10.2 [util.smartptr.shared] and 20.9.10.2.1 [util.smartptr.shared.const]:
</p>

<blockquote><pre><ins>constexpr</ins> shared_ptr();
</pre></blockquote>

<p>
Change 20.9.10.3 [util.smartptr.weak] and 20.9.10.3.1 [util.smartptr.weak.const]:
</p>

<blockquote><pre><ins>constexpr</ins> weak_ptr();
</pre></blockquote>

<p>
Change 20.9.10.4 [util.smartptr.enab] (2 places):
</p>

<blockquote><pre><ins>constexpr</ins> enable_shared_from_this();
</pre></blockquote>






<hr>
<h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-04-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>Consider this code:</p>

<blockquote>
<pre>exception_ptr xp;</pre>
<pre>try {do_something(); }

catch (const runtime_error&amp; ) {xp = current_exception();}

...

rethrow_exception(xp);</pre>
</blockquote>

<p>
Say <code>do_something()</code> throws an exception object of type <code>
range_error</code>. What is the type of the exception object thrown by <code>
rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>; 
if it were of type <code>runtime_error</code> it still isn't possible to 
propagate an exception and the exception_ptr/current_exception/rethrow_exception 
machinery serves no useful purpose.
</p>

<p>
Unfortunately, the current wording does not explicitly say that. Different 
people read the current wording and come to different conclusions. While it may 
be possible to deduce the correct type from the current wording, it would be 
much clearer to come right out and explicitly say what the type of the referred 
to exception is.
</p>

<p><i>[
Peter adds:
]</i></p>


<blockquote>
<p>
I don't like the proposed resolution of 829. The normative text is
unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
</p>
<p>
A better way to address this is to simply add the non-normative example
in question as a clarification. The term <i>currently handled exception</i>
should be italicized and cross-referenced. A [<i>Note:</i> the currently
handled exception is the exception that a throw expression without an
operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>

<p>
After 18.8.5 [propagation] , paragraph 7, add the indicated text:
</p>

<blockquote>
<pre>exception_ptr current_exception();</pre>

<blockquote>
<p>
<i>Returns:</i> <code>exception_ptr</code> object that refers 
to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled 
exception, or a null <code>exception_ptr</code> object if no exception is being handled. If 
the function needs to allocate memory and the attempt fails, it returns an
<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. 
It is unspecified whether the return values of two successive calls to
<code>current_exception</code> refer to the same exception object. 
[<i>Note:</i> that is, it 
is unspecified whether <code>current_exception</code>
creates a new copy each time it is called.
<i>-- end note</i>]
</p>

<p>
<i>Throws:</i> nothing.
</p>

</blockquote>
</blockquote>






<hr>
<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
<p><b>Section:</b> 20.9.9.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>) proposes a useful
extension point for <tt>unique_ptr</tt> by granting support for an optional
<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
(In the following: <tt>pointer</tt>).
</p>
<p>
Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
impact on at least two key features of <tt>unique_ptr</tt>:
</p>

<ol>
<li>Operational fail-safety.</li>
<li>(Well-)Definedness of expressions.</li>
</ol>

<p>
<tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
operations cannot throw and therefore adds proper wording to the affected
operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
("smart pointers") will be allowed, either *all* throw-nothing clauses have to
be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
an exception"-clauses or it has to be said explicitly that all used
operations of
<tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
to be as near as possible to the advantages of native pointers which cannot
fail and thus strongly favor the second choice. Also, the alternative position
would make it much harder to write safe and simple template code for
<tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
that all of the expressions of <tt>pointer</tt> used to define semantics are required to
be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>).
</p>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector&lt;T&gt;::iterator</tt>.
</p>
<p>
Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
2009-10-15 Alisdair pulls from Ready:
]</i></p>


<blockquote>
<p>
I hate to pull an issue out of Ready status, but I don't think 834 is
fully baked yet.
</p>

<p>
For reference the proposed resolution is to add the following words:
</p>

<blockquote>
<tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be
well-formed, shall have well defined behavior, and shall not throw
exceptions.
</blockquote>

<p>
This leaves me with a big question : which operations?
</p>

<p>
Are all pointer operations required to be nothrow, including operations
that have nothing to do with interactions with <tt>unique_ptr</tt>?  This was
much simpler with concepts where we could point to operations within a
certain concept, and so nail down the interactions.
</p>
</blockquote>

<p><i>[
2009-10-15 Daniel adds:
]</i></p>


<blockquote>
I volunteer to prepare a more fine-grained solution, but I would like
to ask for feedback that helps me doing so. If this question is asked
early in the meeting I might be able to fix it within the week, but I
cannot promise that now.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Leave in open. Daniel to provide wording as already suggested.
</blockquote>

<p><i>[
2009-12-22 Daniel provided wording and rationale.
]</i></p>


<p><i>[
2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
The here proposed resolution has considerable overlap with the requirements that
are used in the allocator requirements.
</p>

<p>
This might be a convincing argument to isolate the common subset into one
requirement. The reason I did not do that is basically because we might find out
that they are either over-constraining or under-constraining at this late point
of specification. Note also that as a result of the idea of a general
requirement set I added the requirement
</p>

<blockquote>
A default-initialized object may have a singular value
</blockquote>

<p>
even though this does not play a relevant role for <tt>unique_ptr</tt>.
</p>

<p>
One further characteristics of the resolution is that availability of relational
operators of <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is not part of the basic
requirements, which is in sync with the allocator requirements on pointer-like
(this means that <tt>unique_ptr</tt> can hold a <tt>void_pointer</tt> or
<tt>const_void_pointer</tt>).
</p>

<p>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
</p>



<p><b>Proposed resolution:</b></p>

<ol>

<li>
<p>
Change 20.9.9.2 [unique.ptr.single]/1 as indicated: <i>[The intent is to
replace the coupling between <tt>T*</tt> and the deleter's <tt>operator()</tt>
by a coupling between <tt>unique_ptr&lt;T, D&gt;::pointer</tt> and this
<tt>operator()</tt>]</i>
</p>

<blockquote>
1 - The default type for the template parameter <tt>D</tt> is
<tt>default_delete</tt>. A client-supplied template argument <tt>D</tt> shall be
a function pointer or functor for which, given a value <tt>d</tt> of type
<tt>D</tt> and a <del>pointer</del> <ins>value</ins> <tt>ptr</tt> of type
<tt><del>T*</del> <ins>unique_ptr&lt;T, D&gt;::pointer</ins></tt>, the
expression <tt>d(ptr)</tt> is valid and has the effect of deallocating the
pointer as appropriate for that deleter. <tt>D</tt> may also be an
lvalue-reference to a deleter.
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2 [unique.ptr.single]/3 as indicated:
</p>

<blockquote>
<p>
3 - If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt> exists, then
<tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be a synonym for
<tt>remove_reference&lt;D&gt;::type::pointer</tt>. Otherwise
<tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be a synonym for <tt>T*</tt>. The
type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall <del>be</del> <ins>satisfy
the requirements of <tt>EqualityComparable</tt>,
<tt>DefaultConstructible</tt>,</ins> <tt>CopyConstructible</tt> <del>(Table 34)
and</del><ins>,</ins> <tt>CopyAssignable</tt> <del>(Table 36)</del><ins>,
<tt>Swappable</tt>, and <tt>Destructible</tt> (20.2.1 [utility.arg.requirements]). A default-initialized object may have a
singular value.  A value-initialized object produces the null value of the type.
The null value shall be equivalent only to itself. An object of this type can be
copy-initialized with a value of type <tt>nullptr_t</tt>, compared for equality
with a value of type <tt>nullptr_t</tt>, and assigned a value of type
<tt>nullptr_t</tt>. The effect shall be as if a value-initialized object had
been used in place of the null pointer constant. An object <tt>p</tt> of this
type can be contextually converted to <tt>bool</tt>. The effect shall be as if
<tt>p != nullptr</tt> had been evaluated in place of <tt>p</tt>. No operation on
this type which is part of the above mentioned requirements shall exit via an
exception.
</ins>
</p>
<p><ins>
[<i>Note:</i> Given an allocator type <tt>X</tt> (20.2.5 [allocator.requirements]), the types <tt>X::pointer</tt>,
<tt>X::const_pointer</tt>, <tt>X::void_pointer</tt>, and
<tt>X::const_void_pointer</tt> may be used as <tt>unique_ptr&lt;T,
D&gt;::pointer</tt> � <i>end note</i>]
</ins></p>

<p><ins>
In addition to being available via inclusion of the <tt>&lt;utility&gt;</tt>
header, the <tt>swap</tt> function template in 20.3.2 [utility.swap] is
also available within the definition of <tt>unique_ptr</tt>'s <tt>swap</tt>
function.
</ins></p>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]/2+3 as indicated: <i>[The first
change ensures that we explicitly say, how the stored pointer is initialized.
This is important for a <tt>constexpr</tt> function, because this may make a
difference for user-defined pointer-like types]</i>
</p>

<blockquote><pre>constexpr unique_ptr();
</pre>
<blockquote>
<p>...</p>
<p>
2 - <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns nothing<ins>,
value-initializing the stored pointer</ins>.
</p>

<p>
3 - <i>Postconditions:</i> <tt>get() == <del>0</del> <ins>nullptr</ins></tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]/6+7 as indicated: <i>[This is a
step-by-fix to ensure consistency to the changes of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2976.html">N2976</a>]</i>
</p>

<blockquote><pre>unique_ptr(pointer p);
</pre>
<blockquote>
<p>...</p>
<p>
6 - <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns <tt>p</tt><ins>,
initializing the stored pointer with <tt>p</tt></ins>.
</p>

<p>
7 - <i>Postconditions:</i> <tt>get() == p</tt>. <tt>get_deleter()</tt> returns a
reference to a <del>default constructed</del> <ins>value-initialized</ins>
deleter <tt>D</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Insert a new effects clause in 20.9.9.2.1 [unique.ptr.single.ctor] just
before p. 14: <i>[The intent is to fix the current lack of specification in
which way the stored pointer is initialized]</i>
</p>

<blockquote><pre>unique_ptr(pointer p, <i><del>implementation-defined</del> <ins>see below</ins></i> d1);
unique_ptr(pointer p, <i><del>implementation-defined</del> <ins>see below</ins></i> d2);
</pre>
<blockquote>
<p>...</p>
<p><ins>
<i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns <tt>p</tt>,
initializing the stored pointer with <tt>p</tt> and the initializing the deleter
as described above.
</ins></p>

<p>
14 - <i>Postconditions:</i> <tt>get() == p</tt>. <tt>get_deleter()</tt> returns a
reference to the internally stored deleter. If <tt>D</tt> is a reference type
then <tt>get_deleter()</tt> returns a reference to the lvalue <tt>d</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]/18+22 as indicated: <i>[The intent
is to clarify that the moved-from source must contain a null pointer, there is
no other choice left]</i>
</p>

<blockquote><pre>unique_ptr(unique_ptr&amp;&amp; u);
</pre>
<blockquote>
<p>
[..]
</p>

<p>
18 - <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before the
construction<ins> and <tt>u.get() == nullptr</tt></ins>. <tt>get_deleter()</tt>
returns a reference to the internally stored deleter which was constructed from
<tt>u.get_deleter()</tt>. If <tt>D</tt> is a reference type then
<tt>get_deleter()</tt> and <tt>u.get_deleter()</tt> both reference the same
lvalue deleter.
</p>

</blockquote>

<pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
</pre>

<blockquote>

<p>
[..]
</p>

<p>
22 - <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before the
construction, modulo any required offset adjustments resulting from the cast
from <tt>unique_ptr&lt;U, E&gt;::pointer</tt> to <tt>pointer</tt><ins> and
<tt>u.get() == nullptr</tt></ins>. <tt>get_deleter()</tt> returns a reference to
the internally stored deleter which was constructed from
<tt>u.get_deleter()</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]/20 as indicated: <i>[With the
possibility of user-defined pointer-like types the implication does only exist,
if those are built-in pointers. Note that this change should also be applied
with the acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>]</i>
</p>

<blockquote><pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
</pre>
<blockquote>
20 - <i>Requires:</i> If <tt>D</tt> is not a reference type, construction of the
deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well formed and
shall not throw an exception. If <tt>D</tt> is a reference type, then <tt>E</tt>
shall be the same type as <tt>D</tt> (diagnostic required). <tt>unique_ptr&lt;U,
E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
<del>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> are
complete types. � <i>end note</i>]</del>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.2 [unique.ptr.single.dtor]/2 as indicated:
</p>

<blockquote><pre>~unique_ptr();
</pre>
<blockquote>
<p>...</p>
<p>
2 - <i>Effects:</i> If <tt>get() == <del>0</del> <ins>nullptr</ins></tt> there
are no effects. Otherwise <tt>get_deleter()(get())</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.3 [unique.ptr.single.asgn]/3+8 as indicated: <i>[The intent is to
clarify that the moved-from source must contain a null pointer, there
is no other choice left]</i>
</p>

<blockquote><pre>unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
</pre>
<blockquote>
<p>[..]</p>
<p>
3 - <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer which <tt>u</tt>
owned, and <tt>u</tt> no longer owns it<ins>, <tt>u.get() == nullptr</tt></ins>.
[<i>Note:</i> If <tt>D</tt> is a reference type, then the referenced lvalue deleters
are move assigned. � <i>end note</i>]
</p>
</blockquote>

<pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>[..]</p>

<p>
8 - <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer which
<tt>u</tt> owned, and <tt>u</tt> no longer owns it<ins>, <tt>u.get() ==
nullptr</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.3 [unique.ptr.single.asgn]/6 as indicated: <i>[With the
possibility of user-defined pointer-like types the implication does only exist,
if those are built-in pointers. Note that this change should also be applied
with the acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>]</i>
</p>

<blockquote><pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>[..]</p>
<p>
6 - <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
<tt>D</tt> shall not throw an exception. <tt>unique_ptr&lt;U,
E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
<del>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> are
complete types. � <i>end note</i>]</del>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.3 [unique.ptr.single.asgn] before p. 11 and p. 12 as
indicated: <i>[The first change is a simple typo fix]</i>
</p>

<blockquote><pre>unique_ptr&amp; operator=(nullptr_t<del>}</del><ins>)</ins>;
</pre>

<blockquote>
<p>
11 - <i>Effects:</i> <tt>reset()</tt>.
</p>

<p>
12 - <i>Postcondition:</i> <tt>get() == <del>0</del> <ins>nullptr</ins></tt>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.4 [unique.ptr.single.observers]/1+4+12 as indicated:
</p>

<blockquote><pre>typename add_lvalue_reference&lt;T&gt;::type operator*() const;
</pre>
<blockquote>
<p>
1 - <i>Requires:</i> <tt>get() != <del>0</del> <ins>nullptr</ins></tt>. <ins>The
variable definition <tt>add_lvalue_reference&lt;T&gt;::type t = *get()</tt>
shall be well formed, shall have well-defined behavior, and shall not exit via
an exception.</ins>
</p>
<p>
[..]
</p>

</blockquote>

<pre>pointer operator-&gt;() const;
</pre>

<blockquote>
<p>
4 - <i>Requires:</i> <tt>get() != <del>0</del> <ins>nullptr</ins></tt>.
</p>

<p>
[..]
</p>

</blockquote>

<pre>explicit operator bool() const;
</pre>

<blockquote>
12 - <i>Returns:</i> <tt>get() != <del>0</del><ins>nullptr</ins></tt>.
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.5 [unique.ptr.single.modifiers]/1 as indicated:
</p>

<blockquote><pre>pointer release();
</pre>

<blockquote>
1 - <i>Postcondition:</i> <tt>get() == <del>0</del> <ins>nullptr</ins></tt>.
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2.5 [unique.ptr.single.modifiers]/9 as indicated: <i>[The
intent is to ensure that potentially user-defined swaps are used. A side-step
fix and harmonization with the specification of the the deleter is realized.
Please note the additional requirement in bullet 2 of this proposed resolution
regarding the availability of the generic <tt>swap</tt> templates within the
member <tt>swap</tt> function.]</i>
</p>

<blockquote><pre>void swap(unique_ptr&amp; u);
</pre>

<blockquote>
<p>
8 - <i>Requires:</i> The deleter <tt>D</tt> shall be <tt>Swappable</tt> and
shall not throw an exception under <tt>swap</tt>.
</p>

<p>
9 - <i>Effects:</i> The stored pointers of <tt><ins>*</ins>this</tt> and
<tt>u</tt> are exchanged <ins>by an unqualified call to non-member
<tt>swap</tt></ins>. The stored deleters are <del><tt>swap</tt>'d
(unqualified)</del> <ins>exchanged by an unqualified call to non-member
<tt>swap</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.3.2 [unique.ptr.runtime.observers]/1 as indicated:
</p>

<blockquote><pre>T&amp; operator[](size_t i) const;
</pre>
<blockquote>
<i>Requires:</i> <tt>i &lt;</tt> the size of the array to which the stored
pointer points. <ins>The variable definition <tt>T&amp; t = get()[i]</tt> shall
be well formed, shall have well-defined behavior, and shall not exit via an
exception.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.3.3 [unique.ptr.runtime.modifiers]/1 as indicated:
</p>

<blockquote><pre>void reset(pointer p = pointer());
void reset(nullptr_t p);
</pre>

<blockquote>
1 - <i>Effects:</i> If <tt>get() == <del>0</del> <ins>nullptr</ins></tt> there
are no effects. Otherwise <tt>get_deleter()(get())</tt>.
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.4 [unique.ptr.special] as indicated: <i>[We don't add the
relational operators to the basic requirement set, therefore we need special
handling here]</i>
</p>

<blockquote>
<pre>template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator==(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> The variable definition <tt>bool b = x.get() ==
y.get();</tt> shall be well formed, shall have well-defined behavior, and shall
not exit via an exception.</ins>
</p>

<p>
2 - <i>Returns:</i> <tt>x.get() == y.get()</tt>.
</p>

<p><ins>
<i>Throws:</i> nothing.
</ins></p>
</blockquote>

<pre>template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator!=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote>
<p>
<ins>Requires: The variable definition <tt>bool b = x.get() != y.get();</tt>
shall be well formed, shall have well-defined behavior, and shall not exit via
an exception.</ins>
</p>

<p>
3 - <i>Returns:</i> <tt>x.get() != y.get()</tt>.
</p>

<p><ins>
<i>Throws:</i> nothing.
</ins></p>
</blockquote>

<pre>template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&lt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote>
<p>
<ins>Requires: The variable definition <tt>bool b = x.get() &lt; y.get()</tt>;
shall be well formed, shall have well-defined behavior, and shall not exit via
an exception.</ins>
</p>

<p>
4 - <i>Returns:</i> <tt>x.get() &lt; y.get()</tt>.
</p>

<p><ins>
<i>Throws:</i> nothing.
</ins></p>
</blockquote>

<pre>template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&lt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote>
<p>
<ins>Requires: The variable definition <tt>bool b = x.get() &lt;= y.get();</tt>
shall be well formed, shall have well-defined behavior, and shall not exit via
an exception.</ins>
</p>

<p>
5 - <i>Returns:</i> <tt>x.get() &lt;= y.get()</tt>.
</p>

<p><ins>
<i>Throws:</i> nothing.
</ins></p>
</blockquote>

<pre>template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&gt;(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote>
<p>
<ins>Requires: The variable definition <tt>bool b = x.get() &gt; y.get();</tt>
shall be well formed, shall have well-defined behavior, and shall not exit via
an exception.</ins>
</p>

<p>
6 - <i>Returns:</i> <tt>x.get() &gt; y.get()</tt>.
</p>

<p><ins>
<i>Throws:</i> nothing.
</ins></p>
</blockquote>

<pre>template &lt;class T1, class D1, class T2, class D2&gt;
  bool operator&gt;=(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);
</pre>

<blockquote>
<p>
<ins>Requires: The variable definition <tt>bool b = x.get() &gt;= y.get();</tt>
shall be well formed, shall have well-defined behavior, and shall not exit via
an exception.</ins>
</p>

<p>
7 - <i>Returns:</i> <tt>x.get() &gt;= y.get()</tt>.
</p>

<p><ins>
<i>Throws:</i> nothing.
</ins></p>
</blockquote>

</blockquote>
</li>

</ol>







<hr>
<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
       <p>

The fix for
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
now integrated into the working paper, overlooks a couple of minor
problems.

       </p>
       <p>

First, being an unformatted function once again, <code>flush()</code>
is required to create a sentry object whose constructor must, among
other things, flush the tied stream. When two streams are tied
together, either directly or through another intermediate stream
object, flushing one will also cause a call to <code>flush()</code> on
the other tied stream(s) and vice versa, ad infinitum. The program
below demonstrates the problem.

       </p>
       <p>

Second, as Bo Persson notes in his
comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
for streams with the <code>unitbuf</code> flag set such
as <code>std::stderr</code>, the destructor of the sentry object will
again call <code>flush()</code>. This seems to create an infinite
recursion for <code>std::cerr &lt;&lt; std::flush;</code>

       </p>
       <blockquote>
           <pre>#include &lt;iostream&gt;

int main ()
{
   std::cout.tie (&amp;std::cerr);
   std::cerr.tie (&amp;std::cout);
   std::cout &lt;&lt; "cout\n";
   std::cerr &lt;&lt; "cerr\n";
} 
</pre>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Review.
</blockquote>

<p><i>[
2009-05-26 Daniel adds:
]</i></p>


<blockquote>
<p>
I think that the most recently suggested change in
27.7.2.4 [ostream::sentry] need some further word-smithing. As
written, it would make the behavior undefined, if under
conditions when <tt>pubsync()</tt> should be called, but when
in this scenario <tt>os.rdbuf()</tt> returns 0.
</p>
<p>
This case is explicitly handled in <tt>flush()</tt> and needs to be
taken care of. My suggested fix is:
</p>

<blockquote>
If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()</tt>
<ins><tt>&amp;&amp; os.rdbuf() != 0</tt></ins>) is true, calls <del><tt>os.flush()</tt></del>
<ins><tt>os.rdbuf()-&gt;pubsync()</tt></ins>.
</blockquote>

<p>
Two secondary questions are:
</p>

<ol>
<li>
Should <tt>pubsync()</tt> be invoked in any case or shouldn't a
base requirement for this trial be that <tt>os.good() == true</tt>
as required in the original <tt>flush()</tt> case?
</li>
<li>
Since <tt>uncaught_exception()</tt> is explicitly tested, shouldn't
a return value of -1 of <tt>pubsync()</tt> produce <tt>setstate(badbit)</tt>
(which may throw <tt>ios_base::failure</tt>)?
</li>
</ol>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
Daniel volunteered to modify the proposed resolution to address his two questions.
</p>
<p>
Move back to Open.
</p>
</blockquote>

<p><i>[
2009-07-26 Daniel provided wording.  Moved to Review.
]</i></p>


<p><i>[
2009-10-13 Daniel adds:
]</i></p>


<blockquote>
This proposed wording is written to match the outcome
of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a>.
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to Open. Martin to propose updated wording that will also resolve
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#397">397</a> consistently.
</blockquote>

<p><i>[
2010-02-15 Martin provided wording.
]</i></p>


<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to Ready for Pittsburgh.
</blockquote>



<p><b>Proposed resolution:</b></p>

<ol>
<li>
<p>
Just before 27.5.4.2 [basic.ios.members]/2 insert a new paragraph:
</p>

<blockquote>
<ins><i>Requires:</i> If <tt>(tiestr != 0)</tt> is <tt>true</tt>,
<tt>tiestr</tt> must not be reachable by traversing the linked list of tied
stream objects starting from <tt>tiestr-&gt;tie()</tt>.</ins>
</blockquote>
</li>

<li>
<p>
Change 27.7.2.4 [ostream::sentry]/4 as indicated:
</p>

<blockquote>
If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()
<ins>&amp;&amp; os.good()</ins>)</tt> is <tt>true</tt>, calls
<del><tt>os.flush()</tt></del> <ins><tt>os.rdbuf()-&gt;pubsync()</tt>. If that
function returns -1 sets <tt>badbit</tt> in <tt>os.rdstate()</tt> without
propagating an exception</ins>.
</blockquote>
</li>

<li>
<p>
Add after 27.7.2.4 [ostream::sentry] p17, the following paragraph:
</p>

<blockquote>
<ins><i>Throws:</i> Nothing.</ins>
</blockquote>

</li>

</ol>


   



<hr>
<h3><a name="836"></a>836. 
       effects of <code>money_base::space</code> and
       <code>money_base::none</code> on <code>money_get</code>
   </h3>
<p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a></p>
<p><b>Discussion:</b></p>

       <p>

In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following:

       </p>
       <blockquote>

Where <code>space</code> or <code>none</code> appears in the format
pattern, except at the end, optional white space (as recognized
by <code>ct.is</code>) is consumed after any required space.

       </blockquote>
       <p>

This requirement can be (and has been) interpreted two mutually
exclusive ways by different readers. One possible interpretation
is that:

       </p>
       <blockquote>
           <ol>
               <li>

where <code>money_base::space</code> appears in the format, at least
one space is required, and

               </li>
               <li>

where <code>money_base::none</code> appears in the format, space is
allowed but not required.

               </li>
           </ol>
       </blockquote>
       <p>

The other is that:

       </p>
       <blockquote>

where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.

       </blockquote>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Martin will revise the proposed resolution.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
There is a noun missing from the proposed resolution. It's not clear
that the last sentence would be helpful, even if the word were not
missing:
</p>
<blockquote>
In either case, any required MISSINGWORD followed by all optional whitespace (as recognized by ct.is()) is consumed.
</blockquote>
<p>
Strike this sentence and move to Review.
</p>

<p><i>[
Howard: done.
]</i></p>

</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

   

   <p><b>Proposed resolution:</b></p>
       <p>

I propose to change the text to make it clear that the first
interpretation is intended, that is, to make following change to
22.4.6.1.2 [locale.money.get.virtuals], p2:

       </p>

       <blockquote>

When <code><ins>money_base::</ins>space</code>
or <code><ins>money_base::</ins>none</code> appears <ins>as the last
element </ins>in the format pattern, <del>except at the end, optional
white space (as recognized by <code>ct.is</code>) is consumed after
any required space.</del> <ins>no white space is consumed. Otherwise,
where <code>money_base::space</code> appears in any of the initial
elements of the format pattern, at least one white space character is
required. Where <code>money_base::none</code> appears in any of the
initial elements of the format pattern, white space is allowed but not
required.</ins>
If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...

       </blockquote>
   



<hr>
<h3><a name="838"></a>838. 
   can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
 </h3>
<p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
   <p>

From message c++std-lib-20003...

   </p>
   <p>

The description of <code>istream_iterator</code> in
24.6.1 [istream.iterator], p1 specifies that objects of the
class become the <i>end-of-stream</i> (EOS) iterators under the
following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a> another problem
with this paragraph):

   </p>
   <blockquote>

If the end of stream is reached (<code>operator void*()</code> on the
stream returns <code>false</code>), the iterator becomes equal to
the <i>end-of-stream</i> iterator value.

   </blockquote>
   <p>

One possible implementation approach that has been used in practice is
for the iterator to set its <code>in_stream</code> pointer to 0 when
it reaches the end of the stream, just like the default ctor does on
initialization. The problem with this approach is that
the <i>Effects</i> clause for <code>operator++()</code> says the
iterator unconditionally extracts the next value from the stream by
evaluating <code>*in_stream &gt;&gt; value</code>, without checking
for <code>(in_stream == 0)</code>.

   </p>
   <p>

Conformance to the requirement outlined in the <i>Effects</i> clause
can easily be verified in programs by setting <code>eofbit</code>
or <code>failbit</code> in <code>exceptions()</code> of the associated
stream and attempting to iterate past the end of the stream: each
past-the-end access should trigger an exception. This suggests that
some other, more elaborate technique might be intended.

   </p>
   <p>

Another approach, one that allows <code>operator++()</code> to attempt
to extract the value even for EOS iterators (just as long
as <code>in_stream</code> is non-0) is for the iterator to maintain a
flag indicating whether it has reached the end of the stream. This
technique would satisfy the presumed requirement implied by
the <i>Effects</i> clause mentioned above, but it isn't supported by
the exposition-only members of the class (no such flag is shown). This
approach is also found in existing practice.

   </p>
   <p>

The inconsistency between existing implementations raises the question
of whether the intent of the specification is that a non-EOS iterator
that has reached the EOS become a non-EOS one again after the
stream's <code>eofbit</code> flag has been cleared? That is, are the
assertions in the program below expected to pass?

   </p>
   <blockquote>
     <pre>   sstream strm ("1 ");
   istream_iterator eos;
   istream_iterator it (strm);
   int i;
   i = *it++
   assert (it == eos);
   strm.clear ();
   strm &lt;&lt; "2 3 ";
   assert (it != eos);
   i = *++it;
   assert (3 == i);
     </pre>
   </blockquote>
   <p>

Or is it intended that once an iterator becomes EOS it stays EOS until
the end of its lifetime?

   </p>
 
 <p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
We like the direction of the proposed resolution. We're not sure about
the wording, and we need more time to reflect on it,
</p>
<p>
Move to Open. Detlef to rewrite the proposed resolution in such a way
that no reference is made to exposition only members of
<tt>istream_iterator</tt>.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



 <p><b>Proposed resolution:</b></p>
   <p>

The discussion of this issue on the reflector suggests that the intent
of the standard is for an <code>istreambuf_iterator</code> that has
reached the EOS to remain in the EOS state until the end of its
lifetime. Implementations that permit EOS iterators to return to a
non-EOS state may only do so as an extension, and only as a result of
calling <code>istream_iterator</code> member functions on EOS
iterators whose behavior is in this case undefined.

   </p>
   <p>

To this end we propose to change 24.6.1 [istream.iterator], p1,
as follows:

   </p>
   <blockquote>

The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
is not defined. For any other iterator value a <code>const T*</code>
is returned.<ins> Invoking <code>operator++()</code> on
an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
to store things into istream iterators...

   </blockquote>
   <p>

Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:

   </p>
   <blockquote>

<pre>istream_iterator();</pre>

<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>

<pre>istream_iterator(istream_type &amp;s);</pre>

<i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
may be initialized during construction or the first time it is
referenced.<br>
<ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>

<pre>istream_iterator(const istream_iterator &amp;x);</pre>

<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>

<pre>istream_iterator&amp; operator++();</pre>

<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
<i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.

<pre>istream_iterator&amp; operator++(int);</pre>

<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
<i>Effects</i>:
   <blockquote><pre>istream_iterator tmp (*this);
*in_stream &gt;&gt; value;
return tmp;
     </pre>
     </blockquote>
   </blockquote>
 



<hr>
<h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
<p><b>Section:</b> 23.2 [container.requirements], 23.4.2 [vector.bool], 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.2 [container.requirements]/p3 says:
</p>

<blockquote>
Objects stored in these components shall be constructed using
<tt>construct_element</tt> (20.6.9). For each operation that inserts an
element of type <tt>T</tt> into a container (<tt>insert</tt>,
<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
as described in table 88. [<i>Note:</i> If the component is instantiated
with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
<tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
<tt>construct_element</tt> may pass an inner allocator argument to
<tt>T</tt>'s constructor. <i>-- end note</i>]
</blockquote>

<p>
However <tt>vector&lt;bool, A&gt;</tt> (23.4.2 [vector.bool]) and <tt>bitset&lt;N&gt;</tt> 
(20.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset&lt;N&gt;</tt>
does not even have an allocator.  But these containers are governed by this clause.  Clearly this
is not implementable.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 23.2 [container.requirements]/p3:
</p>

<blockquote>
Objects stored in these components shall be constructed using
<tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
For each operation that inserts an
element of type <tt>T</tt> into a container (<tt>insert</tt>,
<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
as described in table 88. [<i>Note:</i> If the component is instantiated
with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
<tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
<tt>construct_element</tt> may pass an inner allocator argument to
<tt>T</tt>'s constructor. <i>-- end note</i>]
</blockquote>

<p>
Change 23.4.2 [vector.bool]/p2:
</p>

<blockquote>
Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template, 
except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
and <tt>construct_element</tt> (23.2 [container.requirements]) is not used to construct these values</ins>.
</blockquote>

<p>
Move 20.5 [template.bitset] to clause 20.
</p>






<hr>
<h3><a name="843"></a>843.  Reference Closure</h3>
<p><b>Section:</b> X [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>std::reference_closure</tt> type has a deleted copy assignment operator
under the theory that references cannot be assigned, and hence the
assignment of its reference member must necessarily be ill-formed.
</p>
<p>
However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
provide for the "copying of references", and thus the current definition
of <tt>std::reference_closure</tt> seems unnecessarily restrictive.  In particular,
it should be possible to write generic functions using both <tt>std::function</tt>
and <tt>std::reference_closure</tt>, but this generality is much harder when
one such type does not support assignment.
</p>
<p>
The definition of <tt>reference_closure</tt> does not necessarily imply direct
implementation via reference types.  Indeed, the <tt>reference_closure</tt> is
best implemented via a frame pointer, for which there is no standard
type.
</p>
<p>
The semantics of assignment are effectively obtained by use of the
default destructor and default copy assignment operator via
</p>

<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
</pre></blockquote>

<p>
So the copy assignment operator generates no significant real burden
to the implementation.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In  [func.referenceclosure] Class template reference_closure,
replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
with <tt>=default</tt>.
</p>

<blockquote><pre>template&lt;class R , class... ArgTypes &gt; 
  class reference_closure&lt;R (ArgTypes...)&gt; { 
  public:
     ...
     reference_closure&amp; operator=(const reference_closure&amp;) = <del>delete</del> <ins>default</ins>;
     ...
</pre></blockquote>

<p>
In X [func.referenceclosure.cons] Construct, copy, destroy,
add the member function description
</p>

<blockquote>
<pre>reference_closure&amp; operator=(const reference_closure&amp; f)
</pre>
<blockquote>
<p>
<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
</p>
<p>
<i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>







<hr>
<h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current working draft is in an inconsistent state.
</p>

<p>
26.4.8 [complex.transcendentals] says that:
</p>

<blockquote>
<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;float&gt;</tt>.
</blockquote>

<p>
26.4.9 [cmplx.over] says that:
</p>

<blockquote>
<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;double&gt;</tt>.
</blockquote>

<p><i>[
Sophia Antipolis:
]</i></p>


<blockquote>
<p>
Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
overload for <tt>pow</tt>, the C99 result is <tt>complex&lt;double&gt;</tt>, see also C99
7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
</p>
<p>
Special note: ask P.J. Plauger.
</p>
<blockquote>
Looks fine.
</blockquote>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Strike this <tt>pow</tt> overload in 26.4.1 [complex.syn] and in 26.4.8 [complex.transcendentals]:
</p>

<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; pow(const complex&lt;T&gt;&amp; x, int y);</del>
</pre></blockquote>





<hr>
<h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
<p><b>Section:</b> X [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The atomic classes (and class templates) are required to support aggregate
initialization (29.5.1 [atomics.types.integral]p2 / 29.5.2 [atomics.types.address]p1)
yet also have user declared constructors, so cannot be aggregates.
</p>
<p>
This problem might be solved with the introduction of the proposed
initialization syntax at Antipolis, but the wording above should be altered.
Either strike the sentence as redundant with new syntax, or refer to 'brace
initialization'.
</p>

<p><i>[
Jens adds:
]</i></p>


<blockquote>
<p>
Note that
</p>
<blockquote><pre>atomic_itype a1 = { 5 };
</pre></blockquote>
<p>
would be aggregate-initialization syntax (now coming under the disguise
of brace initialization), but would be ill-formed, because the corresponding
constructor for atomic_itype is explicit.  This works, though:
</p>
<blockquote><pre>atomic_itype a2 { 6 };
</pre></blockquote>

</blockquote>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
The preferred approach to resolving this is to remove the explicit
specifiers from the atomic integral type constructors.
</p>
<p>
Lawrence will provide wording.
</p>
<p>
This issue is addressed in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
within the synopsis in 29.5.1 [atomics.types.integral] edit as follows.
</p>

<blockquote><pre><code>
....
typedef struct atomic_bool {
....
  constexpr <del>explicit</del> atomic_bool(bool);
....
typedef struct atomic_<var>itype</var> {
....
  constexpr <del>explicit</del> atomic_<var>itype</var>(<var>integral</var>);
....
</code></pre></blockquote>

<p>
edit 29.5.1 [atomics.types.integral] paragraph 2 as follows.
</p>

<blockquote>
The atomic integral types shall have standard layout.
They shall each have a trivial default constructor,
a constexpr <del>explicit</del> value constructor,
a deleted copy constructor,
a deleted copy assignment operator,
and a trivial destructor.
They shall each support aggregate initialization syntax.
</blockquote>

<p>
within the synopsis of 29.5.2 [atomics.types.address] edit as follows.
</p>

<blockquote><pre><code>
....
typedef struct atomic_address {
....
  constexpr <del>explicit</del> atomic_address(void*);
....
</code></pre></blockquote>

<p>
edit 29.5.2 [atomics.types.address] paragraph 1 as follows.
</p>

<blockquote>
The type <code>atomic_address</code> shall have standard layout.
It shall have a trivial default constructor,
a constexpr <del>explicit</del> value constructor,
a deleted copy constructor,
a deleted copy assignment operator,
and a trivial destructor.
It shall support aggregate initialization syntax.
</blockquote>

<p>
within the synopsis of 29.5 [atomics.types.generic] edit as follows.
</p>

<blockquote><pre><code>
....
template &lt;class T&gt; struct atomic {
....
  constexpr <del>explicit</del> atomic(T);
....
template &lt;&gt; struct atomic&lt;<var>integral</var>&gt; : atomic_<var>itype</var> {
....
  constexpr <del>explicit</del> atomic(<var>integral</var>);
....
template &lt;&gt; struct atomic&lt;T*&gt; : atomic_address {
....
  constexpr <del>explicit</del> atomic(T*);
....
</code></pre></blockquote>

<p>
edit 29.5 [atomics.types.generic] paragraph 2 as follows.
</p>

<blockquote>
Specializations of the <code>atomic</code> template
shall have a deleted copy constructor,
a deleted copy assignment operator,
and a constexpr <del>explicit</del> value constructor.
</blockquote>






<hr>
<h3><a name="846"></a>846. No definition for constructor</h3>
<p><b>Section:</b> X [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The atomic classes and class templates (29.5.1 [atomics.types.integral] /
29.5.2 [atomics.types.address]) have a constexpr
constructor taking a value of the appropriate type for that atomic.
However, neither clause provides semantics or a definition for this
constructor.  I'm not sure if the initialization is implied by use of
constexpr keyword (which restricts the form of a constructor) but even if
that is the case, I think it is worth spelling out explicitly as the
inference would be far too subtle in that case.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Lawrence will provide wording.
</p>
<p>
This issue is addressed in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>

<p>
before the description of ...<code>is_lock_free</code>,
that is before 29.6 [atomics.types.operations] paragraph 4,
add the following description.
</p>

<blockquote>
<pre><code>
constexpr <var>A</var>::<var>A</var>(<var>C</var> desired);
</code></pre>
<dl>
<dt><i>Effects:</i></dt>
<dd>
Initializes the object with the value <code>desired</code>.
[<i>Note:</i>
Construction is not atomic.
�<i>end note</i>]
</dd>
</dl>
</blockquote>





<hr>
<h3><a name="847"></a>847. string exception safety guarantees</h3>
<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Herv� Br�nnimann <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In March, on comp.lang.c++.moderated, I asked what were the
string exception safety guarantees are, because I cannot see
*any* in the working paper, and any implementation I know offers
the strong exception safety guarantee (string unchanged if a
member throws exception). The closest the current draft comes to
offering any guarantees is 21.4 [basic.string], para 3:
</p>

<blockquote>
The class template <tt>basic_string</tt> conforms to the requirements
for a Sequence Container (23.1.1), for a Reversible Container (23.1),
and for an Allocator-aware container (91). The iterators supported by
<tt>basic_string</tt> are random access iterators (24.1.5).
</blockquote>

<p>
However, the chapter 23 only says, on the topic of exceptions:  23.2 [container.requirements],
para 10:
</p>

<blockquote>
<p>
Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following 
additional requirements:
</p>

<ul>
<li>if an exception is thrown by...</li>
</ul>
</blockquote>

<p>
I take it  as saying that this paragraph has *no* implication on
<tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
this paragraph does not define a *requirement* of Sequence
nor Reversible Container, just of the models defined in Clause 23.
In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a> proposes to remove 23.2 [container.requirements], para 3.
</p>

<p>
Finally, the fact that no operation on Traits should throw
exceptions has no bearing, except to suggest (since the only
other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
that the strong exception guarantee can be achieved.
</p>

<p>
The reaction in that group by Niels Dekker, Martin Sebor, and
Bo Persson, was all that this would be worth an LWG issue.
</p>

<p>
A related issue is that <tt>erase()</tt> does not throw.  This should be
stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1
applies here).
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Implementors will study this to confirm that it is actually possible.
</blockquote>

<p><i>[
Daniel adds 2009-02-14:
]</i></p>


<blockquote>
The proposed resolution of paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
interacts with this issue (the paper does not refer to this issue).
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add a blanket statement in 21.4.1 [string.require]:
</p>

<blockquote>
<p>
- if any member function or operator of <tt>basic_string&lt;charT, traits, Allocator&gt;</tt>
throws, that function or operator has no effect.
</p>
<p>
- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
</p>
</blockquote>

<p>
As far as I can tell, this is achieved by any implementation.  If I made a
mistake and it is not possible to offer this guarantee, then
either state all the functions for which this is possible
(certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
or add paragraphs to Effects clauses wherever appropriate.
</p>





<hr>
<h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector&lt;bool&gt;</tt></h3>
<p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the current working draft, <tt>std::hash&lt;T&gt;</tt> is specialized for builtin
types and a few other types. Bitsets seems like one that is missing from
the list, not because it cannot not be done by the user, but because it
is hard or impossible to write an efficient implementation that works on
32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
encapsulated in this respect.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add the following to the synopsis in 20.8 [function.objects]/2:
</p>

<blockquote><pre>template&lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool,Allocator&gt;&gt;;
template&lt;size_t N&gt; struct hash&lt;std::bitset&lt;N&gt;&gt;;
</pre></blockquote>

<p>
Modify the last sentence of 20.8.15 [unord.hash]/1 to end with:
</p>

<blockquote>
... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
<tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector&lt;bool&gt;</tt>.
</blockquote>






<hr>
<h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
<p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>.
It did not yet deal with <tt>std::deque</tt>, because of the fundamental
difference between <tt>std::deque</tt> and the other two container types. The
need for <tt>std::deque</tt> may seem less evident, because one might think that
for this container, the overhead is a small map, and some number of
blocks that's bounded by a small constant.
</p>
<p>
The container overhead can in fact be arbitrarily large (i.e. is not
necessarily O(N) where N is the number of elements currently held by the
<tt>deque</tt>).  As Bill Plauger noted in a reflector message, unless the map of
block pointers is shrunk, it must hold at least maxN/B pointers where
maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
creation.  This is independent of how the map is implemented
(<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
the number of elements it currently holds.
</p>
<p>
Herv� Br�nnimann reports a situation where a <tt>deque</tt> of requests grew very
large due to some temporary backup (the front request hanging), and the
map of the <tt>deque</tt> grew quite large before getting back to normal.  Just
to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
steady regime, that held, at some point in its lifetime, maxN=10M
pointers, with one block holding 128 elements, the spine must be at
least (maxN / 128), in that case 100K.   In that case, shrink-to-fit
would allow to reuse about 100K which would otherwise never be reclaimed
in the lifetime of the <tt>deque</tt>.
</p>
<p>
An added bonus would be that it *allows* implementations to hang on to
empty blocks at the end (but does not care if they do or not).  A
<tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
most O(B) space is used in addition to the storage to hold the N
elements and the N/B block pointers.
</p>


<p><b>Proposed resolution:</b></p>
<p>
To Class template deque 23.3.2 [deque] synopsis, add:
</p>
<blockquote><pre>void shrink_to_fit();
</pre></blockquote>

<p>
To deque capacity 23.3.2.2 [deque.capacity], add:
</p>
<blockquote><pre>void shrink_to_fit();
</pre>

<blockquote>
<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
use. [<i>Note:</i> The request is non-binding to allow latitude for
implementation-specific optimizations. -- <i>end note</i>]
</blockquote>
</blockquote>





<hr>
<h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
<p><b>Section:</b> 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2008-06-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
</p>

<blockquote><pre>local_iterator begin(size_type n) const;
</pre></blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis in 23.7.1 [unord.map], 23.7.2 [unord.multimap], and 23.7.4 [unord.multiset]:
</p>

<blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
</pre></blockquote>





<hr>
<h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
<p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update
the three newer <tt>to_string</tt> overloads.
</p>

<p><i>[
post San Francisco:
]</i></p>


<blockquote>
Daniel found problems with the wording and provided fixes.  Moved from Ready
to Review.
</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Alisdair: suggest to not repeat the default arguments in B, C, D
(definition of to_string members)
</p>
<p>
Walter: This is not really a definition.
</p>
<p>
Consensus: Add note to the editor: Please apply editor's judgement
whether default arguments should be repeated for B, C, D changes.
</p>
<p>
Recommend Tentatively Ready.
</p>
</blockquote>

<p><i>[
2009-05-09:  See alternative solution in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1113">1113</a>.
]</i></p>




<p><b>Proposed resolution:</b></p>
<ol type="A">
<li>
<p>replace in 20.5 [template.bitset]/1 (class <tt>bitset</tt>)
</p>
<blockquote><pre>template &lt;class charT, class traits&gt;
  basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
  to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
template &lt;class charT&gt;
  basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
  to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
  to_string(<ins>char zero = '0', char one = '1'</ins>) const;
</pre></blockquote>
</li>
<li>
<p>
replace in 20.5.2 [bitset.members]/37
</p>
<blockquote><pre>template &lt;class charT, class traits&gt;
  basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
  to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
</pre>
<blockquote>
37 <i>Returns:</i> <tt>to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;(<ins>zero, one</ins>)</tt>.
</blockquote>
</blockquote>
</li>
<li>
<p>
replace in 20.5.2 [bitset.members]/38
</p>

<blockquote><pre>template &lt;class charT&gt;
  basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
  to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
</pre>
<blockquote>
38 <i>Returns:</i> <tt>to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;(<ins>zero, one</ins>)</tt>.
</blockquote>
</blockquote>
</li>

<li>
<p>
replace in 20.5.2 [bitset.members]/39
</p>

<blockquote><pre>basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
  to_string(<ins>char zero = '0', char one = '1'</ins>) const;
</pre>
<blockquote>
39 <i>Returns:</i> <tt>to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;(<ins>zero, one</ins>)</tt>.
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
<p><b>Section:</b> 20.9.9.1.2 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.dltr.dflt">issues</a> in [unique.ptr.dltr.dflt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
</p>
<p>
Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor&lt;T&gt;</tt>;
the latter should also become a concept.
</p>
<p>
Rules out cross-casting.
</p>
<p>
The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
</p>

<p><i>[
Howard adds 2008-11-26:
]</i></p>


<blockquote>
<p>
I believe we need to be careful to not outlaw the following use case, and
I believe the current proposed wording
(<tt>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>) does so:
</p>

<blockquote><pre>#include &lt;memory&gt;

int main()
{
    std::unique_ptr&lt;int&gt; p1(new int(1));
    std::unique_ptr&lt;const int&gt; p2(move(p1));
    int i = *p2;
<font color="#C80000">//    *p2 = i;  // should not compile</font>
}
</pre></blockquote>

<p>
I've removed "<tt>&amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>" from the
<tt>requires</tt> clause in the proposed wording.
</p>

</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Alisdair: This issue has to stay in review pending a paper constraining
<tt>unique_ptr</tt>.
</p>
<p>
Consensus: We agree with the resolution, but <tt>unique_ptr</tt> needs
to be constrained, too.
</p>
<p>
Recommend Keep in Review.
</p>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Keep in Review status for the reasons cited.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
The proposed resolution uses concepts. Howard needs to rewrite the
proposed resolution.
</p>
<p>
Move back to Open.
</p>
</blockquote>

<p><i>[
2009-07-26 Howard provided rewritten proposed wording and moved to Review.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add after 20.9.9.1.2 [unique.ptr.dltr.dflt], p1:
</p>

<blockquote><pre>template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp; other);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> ...
</p>
<p><ins>
<i>Remarks:</i> This constructor shall participate in overload resolution
if and only if <tt>U*</tt> is implicitly convertible to <tt>T*</tt>.
</ins></p>
</blockquote>
</blockquote>






<hr>
<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
<p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-06-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
With the arrival of extended unions 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
there is no
known use of <tt>aligned_union</tt> that couldn't be handled by
the "extended unions" core-language facility.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Remove the following signature from 20.7.2 [meta.type.synop]:
</p>
<blockquote><pre>template &lt;std::size_t Len, class... Types&gt; struct aligned_union;
</pre></blockquote>

<p>
Remove the second row from table 51 in 20.7.7.6 [meta.trans.other],
starting with:
</p>

<blockquote><pre>template &lt;std::size_t Len,
class... Types&gt;
struct aligned_union;
</pre></blockquote>





<hr>
<h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-06-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
obscure that even the class' designer can't deduce it correctly. Several
people have independently stumbled on this issue.
</p>
<p>
It might be simpler to change the return type to a scoped enum:
</p>
<blockquote><pre>enum class timeout { not_reached, reached };
</pre></blockquote>

<p>
That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
</p>

<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
  throw time_out();
</pre></blockquote>

<p><i>[
Beman to supply exact wording.
]</i></p>


<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
There is concern that the enumeration names are just as confusing, if
not more so, as the bool. You might have awoken because of a signal or a
spurious wakeup, for example.
</p>
<p>
Group feels that this is a defect that needs fixing.
</p>
<p>
Group prefers returning an enum over a void return.
</p>
<p>
Howard to provide wording.
</p>
</blockquote>

<p><i>[
2009-06-14 Beman provided wording.
]</i></p>


<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change Condition variables 30.5 [thread.condition], Header
condition_variable synopsis, as indicated:
</p>

<blockquote><pre>namespace std {
  class condition_variable;
  class condition_variable_any;

  <ins>enum class cv_status { no_timeout, timeout };</ins>
}
</pre></blockquote>

<p>
Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
</p>

<blockquote><pre>class condition_variable { 
public:
  ...
  template &lt;class Clock, class Duration&gt;
    <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
  template &lt;class Clock, class Duration, class Predicate&gt;
    bool wait_until(unique_lock&lt;mutex&gt;&amp; lock,
                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
                    Predicate pred);

  template &lt;class Rep, class Period&gt;
    <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
  template &lt;class Rep, class Period, class Predicate&gt;
    bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
                  Predicate pred);
  ...
};

...

template &lt;class Clock, class Duration&gt;
  <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre>
<blockquote>
<p>
-15- <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
</p>
<ul>
<li>
no other thread is waiting on this <tt>condition_variable</tt> object or
</li>
<li>
<tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
<tt>wait_for</tt> or <tt>wait_until</tt>.).
</li>
</ul>

<p>
-16- <i>Effects:</i>
</p>

<ul>
<li>
Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
</li>
<li>
When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
</li>
<li>
The function will unblock when signaled by a call to <tt>notify_one()</tt>,
a call to <tt>notify_all()</tt>, <del>by 
the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
or spuriously.
</li>
<li>
If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
to exiting the function scope.
</li>
</ul>

<p>
-17- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
</p>

<p>
-18- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
</p>

<p>
-19- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
cannot be achieved.
</p>

<p>
-20- <i>Error conditions:</i>
</p>

<ul>
<li>
<tt>operation_not_permitted</tt> � if the thread does not own the lock.
</li>
<li>
equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</li>
</ul>
</blockquote>

<pre>template &lt;class Rep, class Period&gt;
  <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);

</pre>
<blockquote>
<p>
-21- <i><del>Effects</del> <ins>Returns</ins>:</i>
</p>
<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
</pre></blockquote>
<p>
<del>-22- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
duration specified by <tt>rel_time</tt> has elapsed, 
otherwise <tt>true</tt>.</del>
</p>

<p><i>[
This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> in detail, but does
not do so in spirit.  If both issues are accepted, there is a logical merge.
]</i></p>

</blockquote>

<pre>template &lt;class Clock, class Duration, class Predicate&gt; 
  bool wait_until(unique_lock&lt;mutex&gt;&amp; lock, 
                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time, 
                  Predicate pred);
</pre>

<blockquote>
<p>
-23- <i>Effects:</i>
</p>
<blockquote><pre>while (!pred()) 
  if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) 
    return pred(); 
return true;
</pre></blockquote>

<p>
-24- <i>Returns:</i> <tt>pred()</tt>.
</p>

<p>
-25- [<i>Note:</i>
The returned value indicates whether the predicate evaluates to
<tt>true</tt> regardless of whether the timeout was triggered.
� <i>end note</i>].
</p>
</blockquote>
</blockquote>

<p>
Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated:
</p>

<blockquote><pre>class condition_variable_any {
public:
  ...
  template &lt;class Lock, class Clock, class Duration&gt;
    <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
  template &lt;class Lock, class Clock, class Duration, class Predicate&gt;
    bool wait_until(Lock&amp; lock,
                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
                    Predicate pred);

  template &lt;class Lock, class Rep, class Period&gt;
    <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
  template &lt;class Lock, class Rep, class Period, class Predicate&gt;
    bool wait_for(Lock&amp; lock,
                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
                  Predicate pred);
  ...
};

...

template &lt;class Lock, class Clock, class Duration&gt;
  <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre>

<blockquote>

<p>
-13- <i>Effects:</i>
</p>

<ul>
<li>
Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
</li>
<li>
When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
</li>
<li>
The function will unblock when signaled by a call to <tt>notify_one()</tt>,
a call to <tt>notify_all()</tt>, <del>by 
the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
or spuriously.
</li>
<li>
If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
to exiting the function scope.
</li>
</ul>

<p>
-14- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
</p>

<p>
-15- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
</p>

<p>
-16- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
cannot be achieved.
</p>

<p>
-17- <i>Error conditions:</i>
</p>

<ul>
<li>
equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</li>
</ul>
</blockquote>

<pre>template &lt;class Lock, class Rep, class Period&gt;
  <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);

</pre>

<blockquote>
<p>
-18- <i><del>Effects</del> <ins>Returns</ins>:</i>
</p>
<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
</pre></blockquote>

<p>
<del>-19- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
duration specified by <tt>rel_time</tt> has elapsed, 
otherwise <tt>true</tt>.</del>
</p>

<p><i>[
This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> in detail, but does
not do so in spirit.  If both issues are accepted, there is a logical merge.
]</i></p>


</blockquote>

<pre>template &lt;class Lock, class Clock, class Duration, class Predicate&gt; 
  bool wait_until(Lock&amp; lock, 
                  const chrono::time_point&lt;Clock, Duration&gt;&amp; <del>rel_time</del> <ins>abs_time</ins>, 
                  Predicate pred);
</pre>

<blockquote>
<p>
-20- <i>Effects:</i>
</p>
<blockquote><pre>while (!pred()) 
  if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) 
    return pred(); 
return true;
</pre></blockquote>

<p>
-21- <i>Returns:</i> <tt>pred()</tt>.
</p>

<p>
-22- [<i>Note:</i>
The returned value indicates whether the predicate evaluates to
<tt>true</tt> regardless of whether the timeout was triggered.
� <i>end note</i>].
</p>
</blockquote>

</blockquote>






<hr>
<h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
<p><b>Section:</b> 20.9.11 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Pete Becker  <b>Opened:</b> 2008-06-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
to be missing some words. I can't parse
</p>
<blockquote>
... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
</blockquote>
<p>
I take it the intent is that <tt>undeclare_reachable</tt> should be called only
when there has been a corresponding call to <tt>declare_reachable</tt>. In
particular, although the wording seems to allow it, I assume that code
shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
twice.
</p>
<p>
I don't know what "shall be live" in the Requires clause means.
</p>
<p>
In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
deallocated" mean? Is this different from "will not be able to collect"?
</p>

<p>
For the wording on nesting of <tt>declare_reachable</tt> and
<tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
mutexes probably are a good model.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Nick: what does "shall be live" mean?
</p>
<p>
Hans: I can provide an appropriate cross-reference to the Project Editor
to clarify the intent.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 20.9.11 [util.dynamic.safety]
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm">N2670</a>,
Minimal Support for Garbage Collection)
</p>
<p>
Add at the beginning, before paragraph 39
</p>

<blockquote>
A complete object is <i>declared reachable</i> while the number of calls
to <tt>declare_reachable</tt> with an argument referencing the object exceeds the
number of <tt>undeclare_reachable</tt> calls with pointers to the same complete
object.
</blockquote>

<p>
Change paragraph 42 (Requires clause for <tt>undeclare_reachable</tt>)
</p>

<blockquote>
If <tt>p</tt> is not null, <del><tt>declare_reachable(p)</tt> was previously called</del>
<ins>the complete object referenced by <tt>p</tt> shall have
been previously declared reachable</ins>, and shall
be live <ins>(3.8 [basic.life])</ins> from the time of the call until the last <tt>undeclare_reachable(p)</tt>
call on the object.
</blockquote>

<p>
Change the first sentence in paragraph 44 (Effects clause for
<tt>undeclare_reachable</tt>):
</p>

<blockquote>
<i>Effects:</i> 
<del>Once the number of calls to
<tt>undeclare_reachable(p)</tt> equals the number of calls to
<tt>declare_reachable(p)</tt>
for all non-null <tt>p</tt> referencing
the argument is no longer declared reachable.  When this happens,
pointers to the object referenced by p may not be subsequently
dereferenced.</del>
<ins>
After a call to <tt>undeclare_reachable(p)</tt>, if <tt>p</tt> is not null and the object <tt>q</tt>
referenced by <tt>p</tt> is no longer declared reachable, then
dereferencing any pointer to <tt>q</tt> that is not safely derived
results in undefined behavior.
</ins> ...
</blockquote>

<p>
Change the final note:
</p>
<p>
[<i>Note:</i> It is expected that calls to <tt>declare_reachable(p)</tt>
will consume a small amount of memory<ins>, in addition to that occupied
by the referenced object, </ins> until the matching call to
<tt>undeclare_reachable(p)</tt> is encountered. <del>In addition, the
referenced object cannot be deallocated during this period, and garbage
collecting implementations will not be able to collect the object while
it is declared reachable.</del> Long running programs should arrange
that calls <ins>for short-lived objects</ins> are matched. <i>--end
note</i>]
</p>






<hr>
<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#959">959</a>.</p>

<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
says that there is a class named <tt>monotonic_clock</tt>. It also says that this
name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
supported. So the actual requirement is that it can be monotonic or not,
and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
all (since it's conditionally supported). Okay, maybe too much
flexibility, but so be it.
</p>
<p>
A problem comes up in the threading specification, where several
variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
meaning of an effects clause that says
</p>

<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
</pre></blockquote>

<p>
when <tt>monotonic_clock</tt> is not required to exist?
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Nick: maybe instead of saying that chrono::monotonic_clock is
conditionally supported, we could say that it's always there, but not
necessarily supported..
</p>
<p>
Beman: I'd prefer a typedef that identifies the best clock to use for
wait_for locks.
</p>
<p>
Tom: combine the two concepts; create a duration clock type, but keep
the is_monotonic test.
</p>
<p>
Howard: if we create a duration_clock type, is it a typedef or an
entirely true type?
</p>
<p>
There was broad preference for a typedef.
</p>
<p>
Move to Open. Howard to provide wording to add a typedef for
duration_clock and to replace all uses of monotonic_clock in function
calls and signatures with duration_clock.
</p>
</blockquote>

<p><i>[
Howard notes post-San Francisco:
]</i></p>


<blockquote>
<p>
After further thought I do not believe that creating a <tt>duration_clock typedef</tt>
is the best way to proceed.  An implementation may not need to use a
<tt>time_point</tt> to implement the <tt>wait_for</tt> functions.
</p>

<p>
For example, on POSIX systems <tt>sleep_for</tt> can be implemented in terms of
<tt>nanosleep</tt> which takes only a duration in terms of nanoseconds.  The current
working paper does not describe <tt>sleep_for</tt> in terms of <tt>sleep_until</tt>.
And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging
implementations to use monotonic clocks for <tt>sleep_for</tt>:
</p>

<blockquote>
2 The member functions whose names end in <tt>_for</tt> take an argument that
specifies a relative time. Implementations should use a monotonic clock to
measure time for these functions.
</blockquote>

<p>
I believe the approach taken in describing the effects of <tt>sleep_for</tt>
and <tt>try_lock_for</tt> is also appropriate for <tt>wait_for</tt>.  I.e. these
are not described in terms of their <tt>_until</tt> variants.
</p>

</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
Beman will send some suggested wording changes to Howard.
</p>
<p>
Move to Ready.
</p>
</blockquote>

<p><i>[
2009-07-21 Beman added the requested wording changes to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 30.5.1 [thread.condition.condvar], p21-22:
</p>

<blockquote>
<pre>template &lt;class Rep, class Period&gt; 
  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote>
<p><ins>
<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
</ins></p>
<ul>
<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
</ul>
<p>
21 <i>Effects:</i>
</p>
<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
</pre></blockquote>
<ul>
<li><ins>
Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
</ins></li>

<li><ins>
When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
</ins></li>

<li><ins>
The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call
to <tt>notify_all()</tt>, by 
the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
or spuriously.
</ins></li>

<li><ins>
If the function exits via an exception, <tt>lock.unlock()</tt> shall be called 
prior to exiting the function scope.
</ins></li>
</ul>

<p><ins>
<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
</ins></p>


<p>
22 <i>Returns:</i> <tt>false</tt> if the call is returning because the time
duration specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
</p>

<p><i>[
This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a> in detail, but does
not do so in spirit.  If both issues are accepted, there is a logical merge.
]</i></p>


<p><ins>
<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
</ins></p>

<p><ins>
<i>Error conditions:</i>
</ins></p>

<ul>
<li><ins>
<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
</ins></li>
<li><ins>
equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</ins></li>
</ul>

</blockquote>
</blockquote>

<p>
Change 30.5.1 [thread.condition.condvar], p26-p29:
</p>

<blockquote>
<pre>template &lt;class Rep, class Period, class Predicate&gt; 
  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
                Predicate pred);
</pre>
<blockquote>
<p><ins>
<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
</ins></p>
<ul>
<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
</ul>
<p>
<i>26 Effects:</i>
</p>
<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
</pre>
<ul>
<li><ins>
Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
</ins></li>
<li><ins>
Atomically calls <tt>lock.unlock()</tt>
and blocks on <tt>*this</tt>.
</ins></li>
<li><ins>
When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
</ins></li>
<li><ins>
The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
[thread.req.timing]), or spuriously.
</ins></li>
<li><ins>
If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
prior to exiting the function scope.
</ins></li>
<li><ins>
The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
duration specified by <tt>rel_time</tt> has elapsed.
</ins></li>
</ul>
</blockquote>

<p>
27 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
even if the timeout has already expired. <i>-- end note</i>]
</p>

<p><ins>
<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
</ins></p>

<p>
28 <i>Returns:</i> <tt>pred()</tt>
</p>

<p>
29 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
</p>

<p><ins>
<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
</ins></p>

<p><ins>
<i>Error conditions:</i>
</ins></p>

<ul>
<li><ins>
<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
</ins></li>
<li><ins>
equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</ins></li>
</ul>

</blockquote>
</blockquote>

<p>
Change 30.5.2 [thread.condition.condvarany], p18-19:
</p>

<blockquote>
<pre>template &lt;class Lock, class Rep, class Period&gt; 
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote>
<p>
18 <i>Effects:</i>
</p>
<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
</pre></blockquote>

<ul>
<li><ins>
Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
</ins></li>

<li><ins>
When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
</ins></li>

<li><ins>
The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call to
<tt>notify_all()</tt>, by
the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
or spuriously.
</ins></li>

<li><ins>
If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
prior to exiting the function scope.
</ins></li>
</ul>

<p><ins>
<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
</ins></p>

<p>
19 <i>Returns:</i> <tt>false</tt> if the call is returning because the time duration
specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
</p>

<p><ins>
<i>Throws:</i> <tt>std::system_error</tt> when the returned value, effects,
or postcondition cannot be achieved.
</ins></p>

<p><ins>
<i>Error conditions:</i>
</ins></p>

<ul>
<li><ins>
equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</ins></li>
</ul>
</blockquote>
</blockquote>

<p>
Change 30.5.2 [thread.condition.condvarany], p23-p26:
</p>

<blockquote>
<pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
</pre>
<blockquote>
<p><ins>
<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
</ins></p>
<ul>
<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
</ul>
<p>
<i>23 Effects:</i>
</p>
<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
</pre>
<ul>
<li><ins>
Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
</ins></li>
<li><ins>
Atomically calls <tt>lock.unlock()</tt>
and blocks on <tt>*this</tt>.
</ins></li>
<li><ins>
When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
</ins></li>
<li><ins>
The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
[thread.req.timing]), or spuriously.
</ins></li>
<li><ins>
If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
prior to exiting the function scope.
</ins></li>
<li><ins>
The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
duration specified by <tt>rel_time</tt> has elapsed.
</ins></li>
</ul>
</blockquote>

<p>
24 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
even if the timeout has already expired. <i>-- end note</i>]
</p>

<p><ins>
<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
</ins></p>

<p>
25 <i>Returns:</i> <tt>pred()</tt>
</p>

<p>
26 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
</p>

<p><ins>
<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
</ins></p>

<p><ins>
<i>Error conditions:</i>
</ins></p>

<ul>
<li><ins>
<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
</ins></li>
<li><ins>
equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
</ins></li>
</ul>

</blockquote>
</blockquote>







<hr>
<h3><a name="860"></a>860. Floating-Point State</h3>
<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are a number of functions that affect the floating point state.
These function need to be thread-safe, but I'm unsure of the right
approach in the standard, as we inherit them from C.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Nick: I think we already say that these functions do not introduce data
races; see 17.6.5.6/20
</p>
<p>
Pete: there's more to it than not introducing data races; are these
states maintained per thread?
</p>
<p>
Howard: 21.5/14 says that strtok and strerror are not required to avoid
data races, and 20.9/2 says the same about asctime, gmtime, ctime, and
gmtime.
</p>
<p>
Nick: POSIX has a list of not-safe functions. All other functions are
implicitly thread safe.
</p>
<p>
Lawrence is to form a group between meetings to attack this issue. Nick
and Tom volunteered to work with Lawrence.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
</p>
<p>
Nick: Default wording seems to cover this? Hole in POSIX, these
functions need to be added to list of thread-unsafe functions.
</p>
<p>
Lawrence: Not sufficient, not "thread-safe" per our definition, but
think of state as a thread-local variable. Need something like "these
functions only affect state in the current thread."
</p>
<p>
Hans: Suggest the following wording: "The floating point environment is
maintained per-thread."
</p>
<p>
Walter: Any other examples of state being thread safe that are not
already covered elsewhere?
</p>
<p>
Have thread unsafe functions paper which needs to be updated. Should
just fold in 26.3 [cfenv] functions.
</p>
<p>
Recommend Open. Lawrence instead suggests leaving it open until we have
suitable wording that may or may not include the thread local
commentary.
</p>
</blockquote>

<p><i>[
2009-09-23 Hans provided wording.
]</i></p>


<blockquote>
If I understand the history correctly, Nick, as the Posix liaison,
should probably get a veto on this, since I think it came from Posix (?)
via WG14 and should probably really be addressed there (?).  But I think
we are basically in agreement that there is no other sane way to do
this, and hence we don't have to worry too much about stepping on toes. 
As far as I can tell, this same issue also exists in the latest Posix
standard (?).
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add at the end of 26.3.1 [cfenv.syn]:
</p>

<blockquote>
<p>
2 The header defines all functions, types, and macros the same as C99 7.6.
</p>

<p><ins>
A separate floating point environment shall be maintained for each
thread.  Each function accesses the environment corresponding to its
calling thread.
</ins></p>
</blockquote>





<hr>
<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-06-24 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
</p>

<blockquote>
<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &amp;&amp;
equal(a.begin(), a.end(), b.begin()</tt>
</blockquote>

<p>
The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
</p>
<p>
Other parts of the (sequence) container requirements do also depend on
<tt>size()</tt>, e.g. <tt>empty()</tt>
or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
<tt>EqualityComparable</tt> specification,
because of the special design choices of <tt>forward_list</tt>.
</p>
<p>
I propose to apply one of the following resolutions, which are described as:
</p>

<ol type="A">
<li>
Provide a definition, which is optimal for this special container without
previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
with the corresponding container ranges and instead uses a special
<tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
</li>
<li>
The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
by <tt>distance</tt> with corresponding performance disadvantages.
</li>
</ol>
<p>
Both proposal choices are discussed, the preferred choice of the author is
to apply (A).
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
There's an Option C: change the requirements table to use distance().
</p>
<p>
LWG found Option C acceptable.
</p>
<p>
Martin will draft the wording for Option C.
</p>
</blockquote>

<p><i>[
post San Francisco:
]</i></p>


<blockquote>
Martin provided wording for Option C.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Other operational semantics (see, for example, Tables 82 and 83) are
written in terms of a container's size() member. Daniel to update
proposed resolution C.
</p>
<p><i>[
Howard: Commented out options A and B.
]</i></p>

</blockquote>

<p><i>[
2009-07-26 Daniel updated proposed resolution C.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Mark NAD Editorial. Addressed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Reopened.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>
was rejected in full committee on procedural grounds.
</blockquote>

<p><i>[
2010-01-30 Howard updated Table numbers.
]</i></p>


<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to Ready for Pittsburgh.
</blockquote>



<p><b>Proposed resolution:</b></p>


<p>
Option (C):
</p>
<blockquote>

<ol>
<li>
<p>
In 23.2.1 [container.requirements.general] change Table 90 -- Container requirements as indicated:
</p>

<ol type="a">
<li>
<p>
Change the text in the Assertion/note column in the row for "<tt>X u</tt>;"
as follows:
</p>

<blockquote>
post: <tt>u.<del>size() == 0</del><ins>empty() == true</ins></tt>
</blockquote>
</li>

<li>
<p>
Change the text in the Assertion/note column in the row for "<tt>X();</tt>"
as follows:
</p>

<blockquote>
<tt>X().<del>size() == 0</del><ins>empty() == true</ins></tt>
</blockquote>
</li>

<li>
<p>
Change the text in the Operational Semantics column in the row for
"<tt>a == b</tt>" as follows:
</p>
<blockquote>
<tt>==</tt> is an equivalence relation.
<tt><del>a.size()</del><ins>distance(a.begin(), a.end())</ins> ==
   <del>b.size()</del><ins>distance(b.begin(), b.end())</ins> &amp;&amp;
equal(a.begin(), a.end(), b.begin())</tt>
</blockquote>
</li>

<li>
<p>
Add text in the Ass./Note/pre-/post-condition column in the row for
"<tt>a == b</tt>" as follows:
</p>
<blockquote><ins>
<i>Requires:</i> <tt>T</tt> is <tt>EqualityComparable</tt>
</ins></blockquote>
</li>

<li>
<p>
Change the text in the Operational Semantics column in the row for
"<tt>a.size()</tt>" as follows:
</p>

<blockquote>
<tt><del>a.end() - a.begin()</del><ins>distance(a.begin(), a.end())</ins></tt>
</blockquote>
</li>

<li>
<p>
Change the text in the Operational Semantics column in the row for
"<tt>a.max_size()</tt>" as follows:
</p>

<blockquote>
<tt><del>size()</del><ins>distance(begin(), end())</ins></tt> of the largest
possible container
</blockquote>
</li>

<li>
<p>
Change the text in the Operational Semantics column in the row for
"<tt>a.empty()</tt>" as follows:
</p>

<blockquote>
<tt><del>a.size() == 0</del><ins>a.begin() == a.end()</ins></tt>
</blockquote>
</li>
</ol>
</li>

<li>
<p>
In 23.2.1 [container.requirements.general] change Table 93 -- Allocator-aware container requirements as indicated:
</p>

<ol type="a">
<li>
<p>
Change the text in the Assertion/note column in the row for "<tt>X() /
X u;</tt>" as follows:
</p>

<blockquote>
<i>Requires:</i> <tt>A</tt> is <tt>DefaultConstructible</tt> post: <tt><del>u.size() ==
0</del><ins>u.empty() == true</ins></tt>, <tt>get_allocator() == A()</tt>
</blockquote>
</li>

<li>
<p>
Change the text in the Assertion/note column in the row for "<tt>X(m) /
X u(m);</tt>" as follows:
</p>

<blockquote>
post: <tt><del>u.size() == 0</del><ins>u.empty() == true</ins>,
get_allocator() == m</tt>
</blockquote>
</li>
</ol>
</li>

<li>
<p>
In 23.2.3 [sequence.reqmts] change Table 94 -- Sequence container requirements as indicated:
</p>

<ol type="a">
<li>
<p>
Change the text in the Assertion/note column in the row for "<tt>X(n,
t) / X a(n, t)</tt>" as follows:
</p>

<blockquote>
post: <tt><del>size()</del><ins>distance(begin(), end())</ins> == n [..]</tt>
</blockquote>
</li>

<li>
<p>
Change the text in the Assertion/note column in the row for "<tt>X(i,
j) / X a(i, j)</tt>" as follows:
</p>

<blockquote>
[..] post: <del><tt>size() ==</tt> distance between <tt>i</tt> and
<tt>j</tt></del><ins><tt>distance(begin(), end()) == distance(i, j)</tt></ins> [..]
</blockquote>
</li>

<li>
<p>
Change the text in the Assertion/note column in the row for
"<tt>a.clear()</tt>" as follows:
</p>
<blockquote>
<tt><ins>a.</ins>erase(<ins>a.</ins>begin(), <ins>a.</ins>end())</tt> post:
<tt><del>size() == 0</del><ins>a.empty() == true</ins></tt>
</blockquote>
</li>
</ol>
</li>

<li>
<p>
In 23.2.4 [associative.reqmts] change Table 96 -- Associative container requirements as indicated:
</p>

<p><i>[
Not every occurrence of <tt>size()</tt> was replaced, because all current
associative containers
have a <tt>size</tt>. The following changes ensure consistency regarding the
semantics of "<tt>erase</tt>"
for all tables and adds some missing objects
]</i></p>


<ol type="a">

<li>
<p>
Change the text in the Complexity column in the row for <tt>X(i,j,c)/X
a(i,j,c);</tt> as follows:
</p>

<blockquote>
<tt>N</tt> log <tt>N</tt> in general (<tt>N</tt> <ins><tt> == distance(i,
j)</tt></ins><del>is the distance from <tt>i</tt> to <tt>j</tt></del>); ...
</blockquote>

</li>

<li>
<p>
Change the text in the Complexity column in the row for
"<tt>a.insert(i, j)</tt>" as follows:
</p>
<blockquote>
<tt>N log(<ins>a.</ins>size() + N)</tt> <del>(<tt>N</tt> is the distance from <tt>i</tt> to
<tt>j</tt>)</del><ins> where <tt>N == distance(i, j)</tt></ins>
</blockquote>
</li>

<li>
<p>
Change the text in the Complexity column in the row for
"<tt>a.erase(k)</tt>" as follows:
</p>
<blockquote>
<tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
</blockquote>
</li>

<li>
<p>
Change the text in the Complexity column in the row for
"<tt>a.erase(q1, q2)</tt>" as follows:
</p>

<blockquote>
<tt>log(<ins>a.</ins>size()) + N</tt> where <tt>N</tt> <del>is the distance from <tt>q1</tt>
to <tt>q2</tt></del>
   <ins><tt>== distance(q1, q2)</tt></ins>.
</blockquote>
</li>

<li>
<p>
Change the text in the Assertion/note column in the row for
"<tt>a.clear()</tt>" as follows:
</p>

<blockquote>
<tt><ins>a.</ins>erase(a.begin(),a.end())</tt> post: <tt><del>size() ==
0</del><ins>a.empty() == true</ins></tt>
</blockquote>
</li>

<li>
<p>
Change the text in the Complexity column in the row for "<tt>a.clear()</tt>"
as follows:
</p>

<blockquote>
linear in <tt><ins>a.</ins>size()</tt>
</blockquote>
</li>

<li>
<p>
Change the text in the Complexity column in the row for
"<tt>a.count(k)</tt>" as follows:
</p>

<blockquote>
<tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
</blockquote>
</li>
</ol>
</li>

<li>
<p>
In 23.2.5 [unord.req] change Table 98 -- Unordered associative container requirements as indicated:
</p>
<p><i>[
The same rational as for Table 96 applies here
]</i></p>


<ol type="a">
<li>
<p>
Change the text in the Assertion/note column in the row for
"<tt>a.clear()</tt>" as follows:
</p>

<blockquote>
[..] Post: <tt>a.<del>size() == 0</del><ins>empty() == true</ins></tt>
</blockquote>
</li>
</ol>
</li>
</ol>


</blockquote>





<hr>
<h3><a name="865"></a>865. More algorithms that throw away information</h3>
<p><b>Section:</b> 25.3.6 [alg.fill], 25.3.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-07-13 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
unnecessarily throw away information. These are typically algorithms,
which sequentially write into an <tt>OutputIterator</tt>, but do not return the
final value of this output iterator. These cases are:
</p>

<ol>
<li>
<pre>template&lt;class OutputIterator, class Size, class T&gt;
void fill_n(OutputIterator first, Size n, const T&amp; value);</pre></li>

<li>
<pre>template&lt;class OutputIterator, class Size, class Generator&gt;
void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
</ol>
<p>
In both cases the minimum requirements on the iterator are
<tt>OutputIterator</tt>, which means according to the requirements of
24.2.4 [output.iterators]/2 that only single-pass iterations are guaranteed.
So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
available, they have no chance to continue pushing further values
into it, which seems to be a severe limitation to me.
</p>

<p><i>[
Post Summit Daniel "conceptualized" the wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Alisdair likes the idea, but has concerns about the specific wording
about the returns clauses.
</p>
<p>
Alan notes this is a feature request.
</p>
<p>
Bill notes we have made similar changes to other algorithms.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
We have a consensus for moving forward on this issue, but Daniel needs
to deconceptify it.
</blockquote>

<p><i>[
2009-07-25 Daniel provided non-concepts wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>

<ol>
<li>
<p>
Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
<tt>&lt;algorithm&gt;</tt> synopsis and in 25.3.6 [alg.fill] by
</p>

<blockquote><pre>template&lt;class OutputIterator, class Size, class T&gt;
  <del>void</del><ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T&amp; value);
</pre></blockquote>

<p>
Just after the effects clause add a new returns clause saying:
</p>

<blockquote>
<ins><i>Returns:</i> For <tt>fill_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
returns <tt>first</tt> for <tt>fill_n</tt>.</ins>
</blockquote>
</li>

<li>
<p>
Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2,
header <tt>&lt;algorithm&gt;</tt> synopsis and in 25.3.7 [alg.generate] by
</p>

<blockquote><pre>template&lt;class OutputIterator, class Size, class Generator&gt;
  <del>void</del><ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
</pre></blockquote>

<p>
Just after the effects clause add a new returns clause saying:
</p>

<blockquote>
<ins>For <tt>generate_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
returns <tt>first</tt> for <tt>generate_n</tt>.</ins>
</blockquote>
</li>
</ol>







<hr>
<h3><a name="866"></a>866. Qualification of placement new-expressions</h3>
<p><b>Section:</b> 20.9.8 [specialized.algorithms], 20.9.10.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.algorithms].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement
new-expression in 20.9.5.1 [allocator.members]. I believe the rationale
given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts:
</p>
<ul>
<li>
<p>
in 20.9.8 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
<tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
the unqualified placement new-expression in some variation of the form:
</p>
<blockquote><pre>new  (static_cast&lt;void*&gt;(&amp;*result)) typename  iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
</pre></blockquote>
</li>
<li>
<p>
in 20.9.10.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
</p>
<blockquote><pre>new  (pv)  T(std::forward&lt;Args&gt;(args)...),
</pre></blockquote>
</li>
</ul>
<p>
I suggest to add qualification in all those places. As far as I know,
these are all the remaining places in the whole library that explicitly
use a placement new-expression. Should other uses come out, they should
be qualified as well.
</p>
<p>
As an aside, a qualified placement new-expression does not need
additional requirements to be compiled in a constrained context. By
adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
would no longer be needed by library and
should therefore be removed.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Detlef: If we move this to Ready, it's likely that we'll forget about
the side comment about the <tt>HasPlacementNew</tt> concept.
</blockquote>

<p><i>[
post San Francisco:
]</i></p>


<blockquote>
Daniel:  <tt>HasPlacementNew</tt> has been removed from
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774 (Foundational Concepts)</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
</p>
<ul>
<li>
20.9.8.2 [uninitialized.copy], paragraphs 1 and 3
</li>
<li>
20.9.8.3 [uninitialized.fill]  paragraph 1
</li>
<li>
20.9.8.4 [uninitialized.fill.n] paragraph 1
</li>
<li>
20.9.10.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
</li>
</ul>






<hr>
<h3><a name="868"></a>868. default construction and value-initialization</h3>
<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The term "default constructed" is often used in wording that predates
the introduction of the concept of value-initialization. In a few such
places the concept of value-initialization is more correct than the
current wording (for example when the type involved can be a built-in)
so a replacement is in order. Two of such places are already covered by
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>. This issue deliberately addresses the hopefully
non-controversial changes in the attempt of being approved more quickly.
A few other occurrences (for example in <tt>std::tuple</tt>,
<tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>. This issue is
related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#724">724</a>.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
The list provided in the proposed resolution is not complete. James
Dennett will review the library and provide a complete list and will
double-check the vocabulary.
</p>
<p>
This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a> tuple construction
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
The proposed resolution is incomplete.
</p>
<p>
Move to Tentatively NAD Future. Howard will contact Ganesh for wording.
If wording is forthcoming, Howard will move it back to Review.
</p>
</blockquote>

<p><i>[
2009-07-18 Ganesh updated the proposed wording.
]</i></p>


<blockquote>
<p>
Howard:  Moved back to Review.  Note that 20.2.1 [utility.arg.requirements]
refers to a section that is not in the current working paper, but does refer to
a section that we expect to reappear after the de-concepts merge.  This was a
point of confusion we did not recognize when we reviewed this issue in Frankfurt.
</p>
<p>
Howard:  Ganesh also includes a survey of places in the WP surveyed for changes
of this nature and purposefully <em>not</em> treated:
</p>

<blockquote>
<p>
Places where changes are <u>not</u> being
proposed
</p>
<p>
In the following paragraphs, we are not proposing changes because
it's not clear whether we actually prefer value-initialization over
default-initialization (now partially covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>):
</p>
<ul>
    <li><p>20.9.9.2.1 [unique.ptr.single.ctor] para 3 e 7</p></li>
    <li><p>24.5.1.3.1 [reverse.iter.cons] para 1</p></li>
    <li><p>24.5.3.3.1 [move.iter.op.const] para 1</p></li>
</ul>
<p>In the following paragraphs, the expression "default
constructed" need not be changed, because the relevant type does
not depend on a template parameter and has a user-provided
constructor:</p>
<ul>
    <li><p> [func.referenceclosure.invoke] para 12, type:
    reference_closure</p></li>
    <li><p>30.3.1.2 [thread.thread.constr] para 30, type: thread</p></li>
    <li><p>30.3.1.5 [thread.thread.member] para 52, type: thread_id</p></li>
    <li><p>30.3.2 [thread.thread.this], para 1, type: thread_id</p></li>
</ul>
</blockquote>

</blockquote>

<p><i>[
2009-08-18 Daniel adds:
]</i></p>


<blockquote>
<p>
I have no objections against the currently suggested changes, but I
also cross-checked
with the list regarding intentionally excluded changes, and from this
I miss the discussion
of
</p>

<ol>
<li>
<p>
21.4.1 [string.require]/2:
</p>

<blockquote>
"[..] The <tt>Allocator</tt> object used shall be a copy of the <tt>Allocator&gt;</tt>
object passed to the <tt>basic_string</tt> object's
constructor or, if the constructor does not take an <tt>Allocator</tt>
argument, a copy of a default-constructed
<tt>Allocator</tt> object."
</blockquote>
</li>

<li>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
26.5.1.4 [rand.req.eng], Table 109, expression "<tt>T()</tt>":
</p>
<blockquote>
Pre-/post-condition: "Creates an engine with the same initial state as
all other default-constructed engines of type <tt>X</tt>."
</blockquote>

<p>
as well as in 26.5.5 [rand.predef]/1-9 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>), 26.5.7.1 [rand.util.seedseq]/3, 27.7.1.1.1 [istream.cons]/3, 27.7.2.2 [ostream.cons]/9 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>), 28.13 [re.grammar]/2, 30.3.1.4 [thread.thread.assign]/1 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>),
</p>
<p><i>[
Candidates for the "the expression "default constructed" need not be
changed" list
]</i></p>


<p>
I'm fine, if these would be added to the intentionally exclusion list,
but mentioning them makes it
easier for other potential reviewers to decide on the relevance or
not-relevance of them for this issue.
</p>
</li>

<li>
<p>
I suggest to remove the reference of  [func.referenceclosure.invoke]
in the "it's not clear" list, because
this component does no longer exist.
</p>
</li>

<li>
<p>
I also suggest to add a short comment that all paragraphs in the
resolution whether they refer to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> or to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a> numbering, because e.g. "Change 23.3.2.1 [deque.cons] para 5" is an <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> coordinate, while "Change 23.3.2.2 [deque.capacity] para 1" is an <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a> coordinate. Even better would be to use one default document
for the numbering (probably <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>) and mention special cases (e.g. "Change 20.2.1 [utility.arg.requirements] para 2" as referring to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> numbering).
</p>
</li>
</ol>

</blockquote>

<p><i>[
2009-08-18 Alisdair adds:
]</i></p>


<blockquote>
<p>
I strongly believe the term "default constructed" should not appear in
the library clauses unless we very clearly define a meaning for it, and
I am not sure what that would be.
</p>

<p>
In those cases where we do not want to replace "default constructed"
with "vale initialized" we should be using "default initialized".  If we
have a term that could mean either, we reduce portability of programs.
</p>

<p>
I have not done an exhaustive review to clarify if that is a vendor
freedom we have reason to support (e.g. value-init in debug,
default-init in release) so I may yet be convinced that LWG has reason
to define this new term of art, but generally C++ initialization is
confusing enough without supporting further ill-defined terms.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to review in order to enable conflict resolution with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#704">704</a>.
</blockquote>

<p><i>[
2010-03-26 Daniel harmonized the wording with the upcoming FCD.
]</i></p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.2.1 [utility.arg.requirements] para 2:
</p>

<blockquote>
2 In general, a default constructor is
not required. Certain container class member function signatures
specify <del>the default constructor</del><ins>T()</ins>
as a default argument. T() shall be a well-defined expression (8.5)
if one of those signatures is called using the default argument
(8.3.6).
</blockquote>

<p>
Change 23.3.2.1 [deque.cons] para 3:
</p>

<blockquote>
3 <i>Effects:</i> Constructs a deque with n
<del>default constructed</del><ins>value-initialized</ins>
elements. 
</blockquote>

<p>
Change 23.3.2.2 [deque.capacity] para 1:
</p>

<blockquote>
1 <i>Effects:</i> If sz &lt; size(), equivalent
to erase(begin() + sz, end());. If size() &lt; sz, appends sz -
size() <del>default
constructed</del><ins>value-initialized</ins>
elements to the sequence.
</blockquote>

<p>
Change 23.3.3.1 [forwardlist.cons] para 3:
</p>

<blockquote>
3 <i>Effects:</i> Constructs a forward_list object with n <del>default
constructed</del><ins>value-initialized</ins>
elements.
</blockquote>

<p>
Change 23.3.3.4 [forwardlist.modifiers] para 22:
</p>

<blockquote>
22 <i>Effects:</i> [...] For the first signature
the inserted elements are <del>default
constructed</del><ins>value-initialized</ins>,
and for the second signature they are copies of c.
</blockquote>

<p>
Change 23.3.4.1 [list.cons] para 3:
</p>

<blockquote>
3 <i>Effects:</i> Constructs a list with n <del>default
constructed</del><ins>value-initialized</ins>
elements. 
</blockquote>

<p>
Change 23.3.4.2 [list.capacity] para 1:
</p>

<blockquote>
1 <i>Effects:</i> If sz &lt; size(), equivalent
to list&lt;T&gt;::iterator it = begin(); advance(it, sz); erase(it,
end());. If size() &lt; sz, appends sz - size() <del>default
constructed</del><ins>value-initialized</ins>
elements to the sequence.
</blockquote>

<p>
Change 23.4.1.1 [vector.cons] para 3:
</p>

<blockquote>
3 <i>Effects:</i> Constructs a vector with n
<del>default constructed</del><ins>value-initialized</ins>
elements. 
</blockquote>

<p>
Change 23.4.1.2 [vector.capacity] para 9:
</p>

<blockquote>
9 <i>Effects:</i> If sz &lt; size(), equivalent
to erase(begin() + sz, end());. If size() &lt; sz, appends sz -
size() <del>default
constructed</del><ins>value-initialized</ins>
elements to the sequence.
</blockquote>






<hr>
<h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is there any language in the current draft specifying the behaviour of the following snippet?
</p>

<blockquote><pre>unordered_set&lt;int&gt; s;
unordered_set&lt;int&gt;::local_iterator it = s.end(0);

// Iterate past end - the unspecified part
it++;
</pre></blockquote>

<p>
I don't think there is anything about <tt>s.end(n)</tt> being considered an
iterator for the past-the-end value though (I think) it should be.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
We believe that this is not a substantive change, but the proposed
change to the wording is clearer than what we have now.
</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change Table 97 "Unordered associative container requirements" in 23.2.5 [unord.req]:
</p>

<blockquote>
<table border="1">
<caption>Table 97: Unordered associative container requirements</caption>
<tbody><tr>
<th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
</tr>
<tr>
<td><tt>b.begin(n)</tt></td>
<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
<td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
<ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
<td>Constant</td>
</tr>
<tr>
<td><tt>b.end(n)</tt></td>
<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
<td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
<ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
<td>Constant</td>
</tr>
</tbody></table>
</blockquote>






<hr>
<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-08-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Good ol' associative containers allow both function pointers and
function objects as feasible
comparators, as described in 23.2.4 [associative.reqmts]/2:
</p>

<blockquote>
Each associative container is parameterized on <tt>Key</tt> and an ordering
relation <tt>Compare</tt> that
induces a strict weak ordering (25.3) on elements of Key. [..]. The
object of type <tt>Compare</tt> is
called the comparison object of a container. This comparison object
may be a pointer to
function or an object of a type with an appropriate function call operator.[..]
</blockquote>

<p>
The corresponding wording for unordered containers is not so clear,
but I read it to disallow
function pointers for the hasher and I miss a clear statement for the
equality predicate, see
23.2.5 [unord.req]/3+4+5:
</p>

<blockquote>
<p>
Each unordered associative container is parameterized by <tt>Key</tt>, by a
function object <tt>Hash</tt> that
acts as a hash function for values of type <tt>Key</tt>, and by a binary
predicate <tt>Pred</tt> that induces an
equivalence relation on values of type <tt>Key</tt>.[..]
</p>
<p>
A hash function is a function object that takes a single argument of
type <tt>Key</tt> and returns a
value of type <tt>std::size_t</tt>.
</p>
<p>
Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
container's equality function object
returns <tt>true</tt> when passed those values.[..]
</p>
</blockquote>

<p>
and table 97 says in the column "assertion...post-condition" for the
expression X::hasher:
</p>

<blockquote>
<tt>Hash</tt> shall be a unary function object type such that the expression
<tt>hf(k)</tt> has type <tt>std::size_t</tt>.
</blockquote>

<p>
Note that 20.8 [function.objects]/1 defines as "Function objects are
objects with an <tt>operator()</tt> defined.[..]"
</p>
<p>
Does this restriction exist by design or is it an oversight? If an
oversight, I suggest that to apply
the following
</p>

<p><i>[
2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Ask Daniel to provide proposed wording that: makes it explicit that
function pointers are function objects at the beginning of 20.8 [function.objects]; fixes the "requirements" for typedefs in
20.8.4 [refwrap] to instead state that the function objects
defined in that clause have these typedefs, but not that these typedefs
are requirements on function objects; remove the wording that explicitly
calls out that associative container comparators may be function
pointers.
</blockquote>

<p><i>[
2009-12-19 Daniel updates wording and rationale.
]</i></p>


<p><i>[
2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Rationale:</b></p>

<p>
The below provided wording also affects some part of the library which is
involved with <em>callable types</em> (20.8.1 [func.def]/3). Reason for
this is that <em>callable objects</em> do have a lot in common with <em>function
objects</em>. A simple formula seems to be:
</p>

<blockquote>
callable objects = function objects + pointers to member
</blockquote>

<p>
The latter group is excluded from function objects because of the
expression-based usage of <em>function objects</em> in the algorithm clause,
which is incompatible with the notation to dereference pointers to member
without a concept map available in the language.
</p>

<p>
This analysis showed some currently existing normative definition differences
between the above subset of callable objects and function objects which seem to
be unintended: Backed by the Santa Cruz outcome function objects should include
both function pointers and "object[s] with an operator() defined". This clearly
excludes class types with a conversion function to a function pointer or all
similar conversion function situations described in 13.3 [over.match]/2
b. 2. In contrast to this, the wording for callable types seems to be less
constrained (20.8.1 [func.def]/3):
</p>

<blockquote>
A callable type is a [..] class type whose objects can appear immediately to the
left of a function call operator.
</blockquote>

<p>
The rationale given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1673.html#fn2">N1673</a>
and a recent private communication with Peter Dimov revealed that the intention
of this wording was to cover the above mentioned class types with conversion
functions as well. To me the current wording of callable types can be read
either way and I suggest to make the intention more explicit by replacing
</p>

<blockquote>
[..] class type whose objects can appear immediately to the left of a function
call operator
</blockquote>

by

<blockquote>
[..] class type whose objects can appear as the leftmost subexpression of a
function call expression 5.2.2 [expr.call].
</blockquote>

<p>
and to use the same definition for the class type part of <em>function
objects</em>, because there is no reason to exclude class types with a
conversion function to e.g. pointer to function from being used in algorithms.
</p>

<p>
Now this last term "function objects" itself brings us to a third unsatisfactory
state: The term is used both for objects (e.g. "Function objects are
objects[..]" in 20.8 [function.objects]/1) and for types (e.g. "Each
unordered associative container is parameterized [..] by a function object Hash
that acts as a hash function [..]" in 23.2.5 [unord.req]/3). This
impreciseness should be fixed and I suggest to introduce the term <em>function
object type</em> as the counter part to <em>callable type</em>. This word seems
to be a quite natural choice, because the library already uses it here and there
(e.g. "Hash shall be a unary function object type such that the expression
<tt>hf(k)</tt> has type <tt>std::size_t</tt>." in Table 98, "<tt>X::hasher</tt>"
or "Requires: <tt>T</tt> shall be a function object type [..]" in 20.8.14.2.5 [func.wrap.func.targ]/3).
</p>

<p>
Finally I would like to add that part of the issue 870 discussion related to the
requirements for typedefs in 20.8.4 [refwrap] during the Santa Cruz
meeting is now handled by the new issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1290">1290</a>.
</p>

<p>
Obsolete rationale:
</p>

<blockquote>
<p><i>[
San Francisco:
]</i></p>


<blockquote>
This is fixed by
<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
</blockquote>

</blockquote>



<p><b>Proposed resolution:</b></p>

<ol>

<li>
<p>
Change 20.8 [function.objects]/1 as indicated:
</p>

<blockquote>
<p>
1 <del>Function objects are objects with an <tt>operator()</tt>
defined.</del> <ins>An object type (3.9 [basic.types]) that can be the
type of the <em>postfix-expression</em> in a function call (5.2.2 [expr.call], 13.3.1.1 [over.match.call]) is called a <em>function
object type</em><sup>*</sup>. A <em>function object</em> is an object of a
<em>function object type</em>.</ins> In the places where one would expect to
pass a pointer to a function to an algorithmic template (Clause 25 [algorithms]), the interface is specified to accept <del>an object with
an <tt>operator()</tt> defined</del><ins>a function object</ins>. This not only
makes algorithmic templates work with pointers to functions, but also enables
them to work with arbitrary function objects.
</p>
<blockquote><ins>
* Such a type is either a function pointer or a class type which often has a
member <tt>operator()</tt>, but in some cases it can omit that member and
provide a conversion to a pointer to function.
</ins></blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.8.1 [func.def]/3 as indicated: <i>[The intent is to make the
commonality of callable types and function object
types more explicit and to get rid of wording redundancies]</i>
</p>

<blockquote>
3 A <i>callable type</i> is <del>a pointer to function,</del> a pointer to
member <del>function, a pointer to member data,</del> or a <del>class type whose
objects can appear immediately to the left of a function call operator</del>
<ins><em>function object type</em> (20.8 [function.objects])</ins>.
</blockquote>
</li>

<li>
<p>
Change 20.8.10 [bind]/1 as indicated:
</p>

<blockquote>
1 The function template <tt>bind</tt> returns an object that binds a
<del>function</del> <ins>callable</ins> object passed as an argument to
additional arguments.
</blockquote>
</li>

<li>
<p>
Change 20.8.10.1 [func.bind]/1 as indicated:
</p>

<blockquote>
1 This subclause describes a uniform mechanism for binding arguments of
<del>function</del> <ins>callable</ins> objects.
</blockquote>
</li>

<li>
<p>
Change 20.8.14 [func.wrap]/1 as indicated:
</p>

<blockquote>
1 This subclause describes a polymorphic wrapper class that encapsulates
arbitrary <del>function</del> <ins>callable</ins> objects.
</blockquote>
</li>

<li>
<p>
Change 20.8.14.2 [func.wrap.func]/2 as indicated <i>[The reason for this
change is that 20.8.14.2 [func.wrap.func]/1 clearly says that all callable
types may be wrapped by <tt>std::function</tt> and current implementations
indeed do provide support for pointer to members as well. One further suggested
improvement is to set the below definition of Callable in italics]</i>:
</p>

<blockquote>
2 A <del>function</del><ins>callable</ins> object <tt>f</tt> of type <tt>F</tt>
is <del>Callable</del> <ins><em>Callable</em></ins> for argument types
<del><tt>T1, T2, ..., TN</tt> in</del> <tt>ArgTypes</tt> and <del>a</del> return
type <tt>R</tt><del>,</del> if<del>, given lvalues <tt>t1, t2, ..., tN</tt> of
types <tt>T1, T2, ..., TN</tt>, respectively,</del> <ins>the expression</ins>
<tt><i>INVOKE</i>(f, <ins>declval&lt;ArgTypes&gt;()..., R</ins><del>t1, t2, ...,
tN</del>)</tt><ins>, considered as an unevaluated operand (5 [expr]),</ins> is well formed (20.7.2)<del> and, if <tt>R</tt> is not
<tt>void</tt>, convertible to <tt>R</tt></del>.
</blockquote>
</li>



<li>
<p>
Change 20.8.14.2.1 [func.wrap.func.con]/7 as indicated:
</p>

<blockquote><pre>function(const function&amp; f);
template &lt;class A&gt; function(allocator_arg_t, const A&amp; a, const function&amp; f);
</pre>
<blockquote>
<p>...</p>
<p>
7 <i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
pointer or a <del>function</del> <ins>callable</ins> object passed via
<tt>reference_wrapper</tt>. Otherwise, may throw <tt>bad_alloc</tt> or any
exception thrown by the copy constructor of the stored <del>function</del>
<ins>callable</ins> object. [<i>Note:</i> Implementations are encouraged to
avoid the use of dynamically allocated memory for small <del>function</del>
<ins>callable</ins> objects, e.g., where <tt>f</tt>'s target is an object
holding only a pointer or reference to an object and a member function pointer.
� <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.8.14.2.1 [func.wrap.func.con]/11 as indicated:
</p>

<blockquote><pre>template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>...</p>
<p>
11 [..] [<i>Note:</i> implementations are encouraged to avoid the use of dynamically
allocated memory for small <del>function</del> <ins>callable</ins> objects, for
example, where <tt>f</tt>'s target is an object holding only a pointer or
reference to an object and a member function pointer. � <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.8.14.2.4 [func.wrap.func.inv]/3 as indicated:
</p>

<blockquote><pre>R operator()(ArgTypes... args) const
</pre>
<blockquote>
<p>...</p>
<p>
3 <i>Throws:</i> <tt>bad_function_call</tt> if <tt>!*this</tt>; otherwise, any
exception thrown by the wrapped <del>function</del> <ins>callable</ins> object.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.8.14.2.5 [func.wrap.func.targ]/3 as indicated:
</p>

<blockquote><pre>template&lt;typename T&gt;       T* target();
template&lt;typename T&gt; const T* target() const;
</pre>
<blockquote>
<p>...</p>
<p>
3 <i>Requires:</i> <tt>T</tt> shall be a <del>function object</del> type that is
Callable (20.8.14.2 [func.wrap.func]) for parameter types <tt>ArgTypes</tt>
and return type <tt>R</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.2.4 [associative.reqmts]/2 as indicated: <i>[The suggested
removal seems harmless, because 25.4 [alg.sorting]1 already clarifies
that <tt>Compare</tt> is a function object type. Nevertheless it is recommended,
because the explicit naming of "pointer to function" is misleading]</i>
</p>

<blockquote>
2 Each associative container is parameterized on <tt>Key</tt> and an ordering
relation <tt>Compare</tt> that induces a strict weak ordering (25.4 [alg.sorting]) on elements of <tt>Key</tt>. In addition, <tt>map</tt>
and <tt>multimap</tt> associate an arbitrary type <tt>T</tt> with the
<tt>Key</tt>. The object of type <tt>Compare</tt> is called the comparison
object of a container. <del>This comparison object may be a pointer to function
or an object of a type with an appropriate function call operator.</del>
</blockquote>
</li>

<li>
<p>
Change 23.2.5 [unord.req]/3 as indicated:
</p>

<blockquote>
3 Each unordered associative container is parameterized by <tt>Key</tt>, by a
function object <ins>type</ins> <tt>Hash</tt> that acts as a hash function for
values of type <tt>Key</tt>, and by a binary predicate <tt>Pred</tt> that
induces an equivalence relation on values of type Key. [..]
</blockquote>
</li>

<li>
<p>
Change 25.1 [algorithms.general]/7 as indicated: <i>[The intent is to
bring this part in sync with 20.8 [function.objects]]</i>
</p>

<blockquote>
7 The <tt>Predicate</tt> parameter is used whenever an algorithm expects a
function object <ins>(20.8 [function.objects])</ins> that when applied
to the result of dereferencing the corresponding iterator returns a value
testable as <tt>true</tt>. In other words, if an algorithm takes <tt>Predicate
pred</tt> as its argument and <tt>first</tt> as its iterator argument, it should
work correctly in the construct <tt>if (pred(*first)){...}</tt>. The function
object <tt>pred</tt> shall not apply any nonconstant function through the
dereferenced iterator. <del>This function object may be a pointer to function,
or an object of a type with an appropriate function call operator.</del>
</blockquote>
</li>

<li>
<p>
Change 20.9.9.2 [unique.ptr.single]/1 as indicated:
</p>

<blockquote>
1 The default type for the template parameter <tt>D</tt> is
<tt>default_delete</tt>. A client-supplied template argument <tt>D</tt> shall be
a function <del>pointer or functor</del> <ins>object type</ins> for which, given
a value <tt>d</tt> of type <tt>D</tt> and a pointer <tt>ptr</tt> of type
<tt>T*</tt>, the expression <tt>d(ptr)</tt> is valid and has the effect of
deallocating the pointer as appropriate for that deleter. <tt>D</tt> may also be
an lvalue-reference to a deleter.
</blockquote>
</li>

</ol>








<hr>
<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
<p><b>Section:</b> 26.7.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-08-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to the recent WP
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
26.7.5 [numeric.iota]/1, the requires clause
of <tt>std::iota</tt> says:
</p>

<blockquote>
<tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
</blockquote>

<p>
Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
seems to be the correct choice. I guess the current wording resulted as an
artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
</p>

<p>
Note: If this function will be conceptualized, the here proposed
<tt>MoveConstructible</tt>
requirement can be removed, because this is an implied requirement of
function arguments, see
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
</p>

<p><i>[
post San Francisco:
]</i></p>


<blockquote>
Issue pulled by author prior to review.
</blockquote>

<p><i>[
2009-07-30 Daniel reopened:
]</i></p>


<blockquote>
with the absence of concepts, this issue (closed) is valid again and I
suggest to reopen it.
I also revised by proposed resolution based on N2723 wording:
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Change 'convertible' to 'assignable', Move To Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change the first sentence of 26.7.5 [numeric.iota]/1:
</p>

<blockquote>
<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of <tt>CopyConstructible</tt> and
<tt>Assignable</tt> types, and shall</del> be
assignable to <tt>ForwardIterator</tt>'s value type. [..]
</blockquote>








<hr>
<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
<p><b>Section:</b> 24.5.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-08-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
</p>

<blockquote><pre>reference operator[](difference_type n) const;
</pre></blockquote>

<p>
This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
implicit conversion to <tt>value_type&amp;&amp;</tt> could end up referencing a temporary
that has already been destroyed. This is essentially the same issue that
we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
</p>

<p><i>[
2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
]</i></p>


<p><i>[
2009-08-15 Howard adds:
]</i></p>


<blockquote>
I recommend closing this as  a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> which addresses
this issue for both <tt>move_iterator</tt> and <tt>reverse_iterator</tt>.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready. Note that if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> is reopened, it may yield a
better resolution, but <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a> is currently marked NAD.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In 24.5.3.1 [move.iterator] and 24.5.3.3.12 [move.iter.op.index], change the declaration of
<tt>move_iterator</tt>'s <tt>operator[]</tt> to:
</p>

<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
</pre></blockquote>



<p><b>Rationale:</b></p>
<p><i>[
San Francisco:
]</i></p>


<blockquote>
NAD Editorial, see
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf">N2777</a>.
</blockquote>




<hr>
<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
During the Sophia Antipolis meeting it was decided to split-off some
parts of the
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
("Concurrency modifications for <tt>basic_string</tt>")
proposal into a separate issue, because these weren't actually
concurrency-related. The here proposed changes refer to the recent
update document
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
and attempt to take advantage of the
stricter structural requirements.
</p>
<p>
Indeed there exists some leeway for more guarantees that would be
very useful for programmers, especially if interaction with transactionary
or exception-unaware C API code is important. This would also allow
compilers to take advantage of more performance optimizations, because
more functions can have throw() specifications. This proposal uses the
form of "Throws: Nothing" clauses to reach the same effect, because
there already exists a different issue in progress to clean-up the current
existing "schizophrenia" of the standard in this regard.
</p>
<p>
Due to earlier support for copy-on-write, we find the following
unnecessary limitations for C++0x:
</p>

<ol>
<li>
Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
a pointer to their guts, which is a non-failure operation. This should
be spelled out. It is also noteworthy to mention that the same
guarantees should also be given by the size query functions,
because the combination of pointer to content and the length is
typically needed during interaction with low-level API.
</li>
<li>
Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
a pointer to their guts, which is guaranteed O(1). This should be
spelled out.
</li>
<li>
Missing reading access to the terminating character: Only the
const overload of <tt>operator[]</tt> allows reading access to the terminator
char. For more intuitive usage of strings, reading access to this
position should be extended to the non-const case. In contrast
to C++03 this reading access should now be homogeneously
an lvalue access.
</li>
</ol>

<p>
The proposed resolution is split into a main part (A) and a
secondary part (B) (earlier called "Adjunct Adjunct Proposal").
(B) extends (A) by also making access to index position
size() of the at() overloads a no-throw operation. This was
separated, because this part is theoretically observable in
specifically designed test programs.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
We oppose part 1 of the issue but hope to address <tt>size()</tt> in
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.
</p>
<p>
We do not support part B. 4 of the issue because of the breaking API change.
</p>
<p>
We support part A. 2 of the issue.
</p>
<p>
On support part A. 3 of the issue:
</p>
<blockquote>
Pete's broader comment: now that we know that basic_string will be a
block of contiguous memory, we should just rewrite its specification
with that in mind. The expression of the specification will be simpler
and probably more correct as a result.
</blockquote>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Move proposed resolution A to Ready.
</p>
<p><i>[
Howard: Commented out part B.
]</i></p>

</blockquote>



<p><b>Proposed resolution:</b></p>
<ol type="A">
<li>
<ol>
<li>
<p>In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
</p>
<blockquote>
<i>Throws:</i> Nothing.
</blockquote>

</li>
<li>
<p>
In 21.4.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
</p>

<blockquote>
<p>
<i>Requires:</i> <tt>pos &#8804; size()</tt>.
</p>
<p>
<i>Returns:</i> If <tt>pos &lt; size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
a reference to a <tt>charT()</tt> that shall not be modified.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
<p>
<i>Complexity:</i> Constant time.
</p>
</blockquote>

</li>
<li>
<p>
In 21.4.7.1 [string.accessors] replace the now <em>common</em> returns
clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
</p>
<blockquote>
<p>
<i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &amp;operator[](i)</tt> for each <tt>i</tt>
in <tt>[0, size()]</tt>.
</p>
<p>
<i>Throws:</i> Nothing.
</p>
<p>
<i>Complexity:</i> Constant time.
</p>
</blockquote>
</li>
</ol>
</li>

</ol>






<hr>
<h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
<p><b>Section:</b> 23.3.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist">issues</a> in [forwardlist].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
       <p>

<tt>forward_list</tt> member functions that take
a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
function signatures) argument have the following precondition:

       </p>
       <blockquote>

<i>Requires:</i> <tt>position</tt> is dereferenceable or equal
to <tt>before_begin()</tt>.

       </blockquote>
       <p>

I believe what's actually intended is this:

       </p>
       <blockquote>

<i>Requires:</i> <tt>position</tt> is in the range
[<tt>before_begin()</tt>, <tt>end()</tt>).

       </blockquote>
       <p>

That is, when it's dereferenceable, <tt>position</tt> must point
into <tt>*this</tt>, not just any <tt>forward_list</tt> object.

       </p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Robert suggested alternate proposed wording which had large support.
</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Walter: "position is before_begin() or a dereferenceable": add "is" after the "or"
</p>
<p>
With that minor update, Recommend Tentatively Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
       <p>

Change the <i>Requires</i> clauses
 [forwardlist] , p21, p24, p26, p29, and,
23.3.3.5 [forwardlist.ops], p39, p43, p47
as follows:

       </p>
       <blockquote>

<i>Requires:</i> <tt>position</tt> is <ins><tt>before_begin()</tt> or is a</ins>
dereferenceable
<ins>iterator in the range <tt>[begin(), end())</tt></ins>
<del>or equal to <tt>before_begin()</tt></del>. ...

       </blockquote>
   



<hr>
<h3><a name="881"></a>881. shared_ptr conversion issue</h3>
<p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-08-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We've changed <tt>shared_ptr&lt;Y&gt;</tt> to not convert to <tt>shared_ptr&lt;T&gt;</tt> when <tt>Y*</tt>
doesn't convert to <tt>T*</tt> by resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>. This only fixed the
converting copy constructor though.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
later added move support, and
the converting move constructor is not constrained.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
We might be able to move this to NAD, Editorial once shared_ptr is
conceptualized, but we want to revisit this issue to make sure.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Moved to Ready.
</p>
<p>
This issue now represents the favored format for specifying constrained templates.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
We need to change the Requires clause of the move constructor:
</p>

<blockquote><pre>shared_ptr(shared_ptr&amp;&amp; r); 
template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r); 
</pre>
<blockquote>
<i><del>Requires</del> <ins>Remarks</ins>:</i> <del>For the second constructor <tt>Y*</tt> shall be
convertible to <tt>T*</tt>.</del>
<ins>
The second constructor shall not participate in overload resolution
unless <tt>Y*</tt> is convertible to <tt>T*</tt>.
</ins>
</blockquote>
</blockquote>

<p>
in order to actually make the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a> compile
(it now resolves to the move constructor).
</p>






<hr>
<h3><a name="882"></a>882. <tt>duration</tt> non-member arithmetic requirements</h3>
<p><b>Section:</b> 20.11.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
specified the following requirements for the non-member <tt>duration</tt>
arithmetic:
</p>

<blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of <tt>Rep1</tt> and
<tt>Rep2</tt>.  Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible
to CR, diagnostic required.
</blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
</pre>

<blockquote>
<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of
<tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt>
shall be implicitly convertible to <tt>CR</tt>, diagnostic required.
</blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>

<blockquote>
<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of
<tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be
implicitly convertible to <tt>CR</tt>, and <tt>Rep2</tt> shall not be an
instantiation of <tt>duration</tt>, diagnostic required.
</blockquote>

</blockquote>

<p>
During transcription into the working paper, the requirements clauses on these
three functions was changed to:
</p>

<blockquote>
<i>Requires:</i> <tt>CR(Rep1, Rep2)</tt> shall exist. Diagnostic required.
</blockquote>

<p>
This is a non editorial change with respect to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
as user written representations which are used in <tt>duration</tt> need not be
implicitly convertible to or from arithmetic types in order to interoperate with
<tt>duration</tt>s based on arithmetic types.  An explicit conversion will do
fine for most expressions as long as there exists a <tt>common_type</tt> specialization
relating the user written representation and the arithmetic type.  For example:
</p>

<blockquote><pre>class saturate
{
public:
  explicit saturate(long long i);
  ...
};

namespace std {

template &lt;&gt;
struct common_type&lt;saturate, long long&gt;
{
    typedef saturate type;
};

template &lt;&gt;
struct common_type&lt;long long, saturate&gt;
{
    typedef saturate type;
};

}  // std

millisecond ms(3);  // integral-based duration
duration&lt;saturate, milli&gt; my_ms = ms;  // ok, even with explicit conversions
my_ms = my_ms + ms;                    // ok, even with explicit conversions
</pre></blockquote>

<p>
However, when dealing with multiplication of a duration and its representation,
implicit convertibility is required between the rhs and the lhs's representation
for the member <tt>*=</tt> operator:
</p>

<blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt; 
class duration { 
public: 
   ...
   duration&amp; operator*=(const rep&amp; rhs);
   ...
};
...
ms *= 2;               // ok, 2 is implicitly convertible to long long
my_ms *= saturate(2);  // ok, rhs is lhs's representation
my_ms *= 2;            // error, 2 is not implicitly convertible to saturate
</pre></blockquote>

<p>
The last line does not (and should not) compile.  And we want non-member multiplication
to have the same behavior as member arithmetic:
</p>

<blockquote><pre>my_ms = my_ms * saturate(2);  // ok, rhs is lhs's representation
my_ms = my_ms * 2;            // <em>should be</em> error, 2 is not implicitly convertible to saturate
</pre></blockquote>

<p>
The requirements clauses of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
make the last line an error as expected.  However the latest working draft at
this time
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
allows the last line to compile.
</p>

<p>
All that being said, there does appear to be an error in these requirements clauses
as specified by 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>.
</p>

<blockquote>
<i>Requires:</i> ... <em>Both</em> <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible
to CR, diagnostic required.
</blockquote>

<p>
It is not necessary for both <tt>Rep</tt>s to be <i>implicitly</i> convertible to
the <tt>CR</tt>.  It is only necessary for the rhs <tt>Rep</tt> to be implicitly
convertible to the <tt>CR</tt>.  The <tt>Rep</tt> within the <tt>duration</tt>
should be allowed to only be explicitly convertible to the <tt>CR</tt>.  The
explicit-conversion-requirement is covered under 20.11.3.7 [time.duration.cast].
</p>



<p><b>Proposed resolution:</b></p>
<p>
Change the requirements clauses under 20.11.3.5 [time.duration.nonmember]:
</p>

<blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>

<blockquote>
<i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del>
<ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins>
Diagnostic required.
</blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
</pre>

<blockquote>
<i>Require<ins>s</ins><del>d behavior</del>:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del>
<ins><tt>Rep1</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins>
Diagnostic required.
</blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>

<blockquote>
<i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist</del>
<ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt></ins>
and <tt>Rep2</tt> shall not
be an instantiation of <tt>duration</tt>. Diagnostic required.
</blockquote>

</blockquote>





<hr>
<h3><a name="883"></a>883. swap circular definition</h3>
<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Note in particular that Table 90 "Container Requirements" gives
semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, yet for all
containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a
circular definition.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
Robert to propose a resolution along the lines of "Postcondition: "a =
b, b = a" This will be a little tricky for the hash containers, since
they don't have <tt>operator==</tt>.
</blockquote>

<p><i>[
Post Summit Anthony Williams provided proposed wording.
]</i></p>


<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved to Ready with minor edits (which have been made).
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In table 80 in section 23.2.1 [container.requirements.general],
replace the postcondition of <tt>a.swap(b)</tt> with the following:
</p>

<blockquote>
<table border="1">
<caption>Table 80 -- Container requirements</caption>
<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion/note pre-/post-conidtion</th>
<th>Complexity</th>
</tr>
<tr>
<td>...</td>
<td>...</td>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>
<tr>
<td><tt>a.swap(b);</tt></td>
<td><tt>void</tt></td>
<td>&nbsp;</td>
<td><del><tt>swap(a,b)</tt></del>
<ins>Exchange the contents of <tt>a</tt> and <tt>b</tt>.</ins></td>
<td>(Note A)</td>
</tr>
</tbody></table>
</blockquote>

<p>
Remove the reference to swap from the paragraph following the table.
</p>

<blockquote>
Notes: the algorithms <del><tt>swap()</tt>, </del><tt>equal()</tt> and
<tt>lexicographical_compare()</tt> are defined in Clause 25. ...
</blockquote>





<hr>
<h3><a name="884"></a>884. shared_ptr swap</h3>
<p><b>Section:</b> 20.9.10.2.4 [util.smartptr.shared.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<blockquote><pre>#include &lt;memory&gt;
#include &lt;cassert&gt;

struct A { };
struct B : A { };

int main()
{
    std::shared_ptr&lt;A&gt; pa(new A);
    std::shared_ptr&lt;B&gt; pb(new B);
    std::swap&lt;A&gt;(pa, pb);  // N.B. no argument deduction
    assert( pa.get() == pb.get() );
    return 0;
}
</pre></blockquote>

<p>
Is this behaviour correct (I believe it is) and if so, is it
unavoidable, or not worth worrying about?
</p>

<p>
This calls the lvalue/rvalue swap overload for <tt>shared_ptr</tt>:
</p>

<blockquote><pre>template&lt;class T&gt; void swap( shared_ptr&lt;T&gt; &amp; a, shared_ptr&lt;T&gt; &amp;&amp; b );
</pre></blockquote>

<p>
silently converting the second argument from <tt>shared_ptr&lt;B&gt;</tt> to
<tt>shared_ptr&lt;A&gt;</tt> and binding the rvalue ref to the produced temporary.
</p>

<p>
This is not, in my opinion, a <tt>shared_ptr</tt> problem; it is a general issue
with the rvalue swap overloads. Do we want to prevent this code from
compiling? If so, how?
</p>

<p>
Perhaps we should limit rvalue args to swap to those types that would
benefit from the "swap trick".  Or, since we now have <tt>shrink_to_fit()</tt>, just
eliminate the rvalue swap overloads altogether.  The original motivation
was:
</p>

<blockquote><pre>vector&lt;A&gt; v = ...;
...
swap(v, vector&lt;A&gt;(v));
</pre></blockquote>

<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Improved%20swap%20Interface">N1690</a>.

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to <del>NAD Editorial</del><ins>Resolved</ins>.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Recommend <del>NAD Editorial</del><ins>Resolved</ins>, fixed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
</p>





<hr>
<h3><a name="885"></a>885. pair assignment</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<blockquote><pre>20.2.3 pairs
Missing assignemnt operator:
template&lt;class U , class V&gt;
  requires CopyAssignable&lt;T1, U&gt; &amp;&amp; CopyAssignable&lt;T2, V&gt;
    pair&amp; operator=(pair&lt;U , V&gt; const &amp; p );
</pre></blockquote>

<p>
Well, that's interesting. This assignment operator isn't in the
current working paper, either. Perhaps we deemed it acceptable to
build a temporary of type <tt>pair</tt> from <tt>pair&lt;U, V&gt;</tt>, then move-assign
from that temporary?
</p>
<p>
It sounds more like an issue waiting to be opened, unless you want to plug
it now.  As written we risk moving from lvalues.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Would be NAD if better ctors fixed it.
</p>
<p>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>.
</p>
</blockquote>

<p><i>[
post San Francisco:
]</i></p>


<blockquote>
Possibly NAD Editorial, solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
</blockquote>

<p><i>[
2009-05-25 Alisdair adds:
]</i></p>


<blockquote>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#885">885</a> was something I reported while reviewing the library concepts
documents ahead of San Francisco.  The missing operator was added as part of
the paper adopted at that meeting
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>)
and I can confirm this operator is
present in the current working paper.  I recommend NAD.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
We agree with the intent, but we need to wait for the dust to settle on concepts.
</blockquote>

<p><i>[
2010-03-11 Stefanus provided wording.
]</i></p>


<p><i>[
2010 Pittsburgh:  Moved to Ready for Pittsburgh.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add the following declaration 20.3.5.2 [pairs.pair], before the
declaration of <tt>pair&amp; operator=(pair&amp;&amp; p);</tt>:
</p>
 
<blockquote><pre>template&lt;class U, class V&gt; pair&amp; operator=(const pair&lt;U, V&gt;&amp; p);
</pre></blockquote>

<p>
Add the following description to 20.3.5.2 [pairs.pair] after paragraph 11 (before
the description of <tt>pair&amp; operator=(pair&amp;&amp; p);)</tt>:
</p>
 
<blockquote><pre>template&lt;class U, class V&gt; pair&amp; operator=(const pair&lt;U, V&gt;&amp; p);
</pre>
<blockquote>
<p>
<i>Requires:</i> <tt>T1</tt> shall satisfy the requirements of
<tt>CopyAssignable</tt> from <tt>U</tt>. <tt>T2</tt> shall
satisfy the requirements of <tt>CopyAssignable</tt> from <tt>V</tt>.
</p>
<p>
<i>Effects:</i> Assigns <tt>p.first</tt> to <tt>first</tt> and 
<tt>p.second</tt> to <tt>second</tt>.
</p>
<p>
<i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="886"></a>886. tuple construction</h3>
<p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.4.2.1 [tuple.cnstr]:
</p>
<blockquote>
<i>Effects:</i> Default initializes each element.
</blockquote>

<p>
Could be clarified to state each "non-trivial" element.  Otherwise
we have a conflict with Core deinfition of default initialization -
trivial types do not get initialized (rather than initialization
having no effect)
</p>

<p>
I'm going to punt on this one, because it's not an issue that's
related to concepts. I suggest bringing it to Howard's attention on
the reflector.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Text in draft doesn't mean anything, changing to "non-trivial" makes it
meaningful.
</p>
<p>
We prefer "value initializes". Present implementations use
value-initialization. Users who don't want value initialization have
alternatives.
</p>
<p>
Request resolution text from Alisdair.
</p>

<p>
This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#868">868</a> default construction and value-initialization.
</p>
</blockquote>

<p><i>[
2009-05-04 Alisdair provided wording and adds:
]</i></p>


<blockquote>
<p>
Note: This <em>IS</em> a change of semantic from TR1, although one the room agreed
with during the discussion.  To preserve TR1 semantics, this would have been
worded:
</p>
<blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
</pre>
<blockquote>
-2-   <i>Effects:</i> Default-initializes each non-trivial element.
</blockquote>
</blockquote>


</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change p2 in Construction 20.4.2.1 [tuple.cnstr]:
</p>

<blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
</pre>
<blockquote>
<p>
-2- <i>Effects:</i> <del>Default</del> <ins>Value-</ins>initializes each element.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="888"></a>888. this_thread::yield too strong</h3>
<p><b>Section:</b> 30.3.2 [thread.thread.this] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.this">active issues</a> in [thread.thread.this].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.this">issues</a> in [thread.thread.this].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I never thought I'd say this, but <tt>this_thread::yield</tt> seems to be too
strong in specification.  The issue is that some systems distinguish
between yielding to another thread in the same process and yielding
to another process.  Given that the C++ standard only talks about
a single program, one can infer that the specification allows yielding
only to another thread within the same program.  Posix has no
facility for that behavior.  Can you please file an issue to weaken
the wording.  Perhaps "Offers the operating system the opportunity
to reschedule."
</p>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend move to Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 30.3.2 [thread.thread.this]/3:
</p>

<blockquote>
<pre>void this_thread::yield();
</pre>
<blockquote>
<i>Effects:</i> Offers the <del>operating system</del> <ins>implementation</ins>
the opportunity to <ins>re</ins>schedule.
<del>another thread.</del>
</blockquote>
</blockquote>





<hr>
<h3><a name="890"></a>890. Improving <tt>&lt;system_error&gt;</tt> initialization</h3>
<p><b>Section:</b> 19.5.1 [syserr.errcat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-09-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>static const error_category</tt> objects <tt>generic_category</tt> and
<tt>system_category</tt> in header <tt>&lt;system_error&gt;</tt> are currently declared:
</p>

<blockquote><pre>const error_category&amp; get_generic_category();
const error_category&amp; get_system_category();

static const error_category&amp; generic_category = get_generic_category();
static const error_category&amp; system_category = get_system_category();
</pre></blockquote>

<p>
This formulation has several problems:
</p>

<ul>
<li>
Implementation details are exposed, since initialization is specified in
the interface. This over-constrains implementations without offsetting
user benefits. The form of initialization specified may be less than
maximally efficient on some platforms.
</li>
<li>
Use of the objects is more expensive in terms of number of machine level
instructions. See <i>Implementation experience</i> below.
</li>
<li>
Depending on the compiler, some cost may be incurred by each translation unit
that includes the header, even if the objects are not used. This is a
common scenario in user code, since the header is included by other
standard library headers. It should be mentioned that at least one
compilers is able to optimize this cost away, however.
</li>
</ul>

<p>
IO streams uses a somewhat different formulation for iostream_category, but 
still suffer much the same problems.
</p>

<p>
The original plan was to eliminate these problems by applying the C++0x
<tt>constexpr</tt> feature. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>. However, that approach turned out
to be unimplementable, since it would require a <tt>constexpr</tt> object of a
class with virtual functions, and that is not allowed by the core
language.
</p>

<p>
The proposed resolution was developed as an alternative. It mitigates the above 
problems by removing initialization from the visible interface, allowing 
implementations flexibility.
</p>

<p>
<b>Implementation experience:</b>
</p>

<p>
Prototype implementations of the current WP interface and proposed
resolution interface were tested with recent Codegear, GCC, Intel, and Microsoft 
compilers on Windows. The code generated by the Microsoft compiler was studied 
at length; the WP and proposal versions generated very similar code. For both versions 
the compiler did make use of static
initialization; apparently the compiler applied an implicit <tt>constexpr</tt>
where useful, even in cases where <tt>constexpr</tt> would not be permitted by
the language!
</p>

<p>
<b>Acknowledgements:</b>
</p>

<p>
Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Martin: prefers not to create more file-scope static objects, and would
like to see <tt>get_*</tt> functions instead.
</p>
</blockquote>


<p><i>[Pre-Summit:]</i></p>

<blockquote>


<p>
Beman: The proposed resolution has been reworked to remove the file-scope 
static objects, per Martin's suggestions. The <tt>get_</tt> prefix has been 
eliminated from the function names as no longer necessary and to conform with 
standard library naming practice.
</p>

</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Agreement that this is wise and essential, text provided works and has
been implemented. Seems to be widespread consensus. Move to Tentative Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>

<p>Change 17.6.4.14 [value.error.codes] Value of error codes as indicated:</p>
<blockquote>
 <p>Certain functions in the C++ standard library report errors via a 
 <tt>std::error_code</tt> (19.4.2.2) object. That object's <tt>category()</tt> member shall 
 return <del>a reference to</del> <code>std::system_category</code><tt><ins><code>()</code></ins></tt> for errors originating from the 
 operating system, or a reference to an implementation-defined error_category 
 object for errors originating elsewhere. The implementation shall define the 
 possible values of value() for each of these error categories. [<i>Example:</i> For 
 operating systems that are based on POSIX, implementations are encouraged to 
 define the <code>std::system_category</code><tt><ins><code>()</code></ins></tt> values as identical to the POSIX <tt>errno</tt> values, 
 with additional values as defined by the operating system's documentation. 
 Implementations for operating systems that are not based on POSIX are 
 encouraged to define values identical to the operating system's values. For 
 errors that do not originate from the operating system, the implementation may 
 provide enums for the associated values --<i>end example</i>]</p>
</blockquote>

<p>
Change 19.5.1.1 [syserr.errcat.overview] Class <tt>error_category</tt> overview
<tt>error_category</tt> synopsis as indicated:
</p>

<blockquote>
<pre>const error_category&amp; <del>get_</del>generic_category();
const error_category&amp; <del>get_</del>system_category();

<del>static storage-class-specifier const error_category&amp; generic_category = get_generic_category();
static storage-class-specifier const error_category&amp; system_category = get_system_category();</del>
</pre>
</blockquote>

<p>
Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
</p>

<blockquote>
<pre>const error_category&amp; <del>get_</del>generic_category();
</pre>

<blockquote>

<p>
<i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
</p>

<p>
<i>Remarks:</i> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
functions shall behave as specified for the class <tt>error_category</tt>. The
object's <tt>name</tt> virtual function shall return a pointer to the string
<tt>"GENERIC"</tt>.
</p>
</blockquote>

<pre>const error_category&amp; <del>get_</del>system_category();
</pre>

<blockquote>
<p>
<i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
</p>

<p>
<i>Remarks:</i> The object's <tt>equivalent</tt> virtual functions shall behave as
specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
shall return a pointer to the string <tt>"system"</tt>. The object's
<tt>default_error_condition</tt> virtual function shall behave as follows:
</p>
<blockquote>
If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
shall return <tt>error_condition(posv, generic_category<ins>()</ins>)</tt>. Otherwise, the
function shall return <tt>error_condition(ev, system_category<ins>()</ins>)</tt>. What
constitutes correspondence for any given operating system is
unspecified. [<i>Note:</i> The number of potential system error codes is large
and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
Thus implementations are given latitude in determining correspondence.
<i>-- end note</i>]
</blockquote>
</blockquote>

</blockquote>

<p>Change 19.5.2.2 [syserr.errcode.constructors] Class error_code constructors 
as indicated:</p>
<blockquote>
 <pre>error_code();</pre>
 <blockquote>
 <p><i>Effects:</i> Constructs an object of type error_code.</p>
 <p><i>Postconditions:</i> <code>val_ == 0 </code>and <code>cat_ == &amp;system_category</code><tt><ins>()</ins></tt>.</p>
 </blockquote>
</blockquote>
<p>Change 19.5.2.3 [syserr.errcode.modifiers] Class error_code modifiers as 
indicated:</p>
<blockquote>
 <pre>void clear();</pre>
 <blockquote>
 <p>Postconditions: <code>value() == 0</code> and <code>category() == 
 system_category</code><tt><ins>()</ins></tt>.</p>
 </blockquote>
</blockquote>
<p>Change 19.5.2.5 [syserr.errcode.nonmembers] Class error_code non-member 
functions as indicated:</p>
<blockquote>
 <pre>error_code make_error_code(errc e);</pre>
 <blockquote>
 <p><i>Returns:</i> <code>error_code(static_cast&lt;int&gt;(e), generic_category</code><tt><ins>()</ins></tt><code>)</code>.</p>
 </blockquote>
</blockquote>
<p>Change 19.5.3.2 [syserr.errcondition.constructors] Class error_condition 
constructors as indicated:</p>
<blockquote>
 <pre>error_condition();</pre>
 <blockquote>
 <p><i>Effects:</i> Constructs an object of type <code>error_condition</code>.</p>
 <p><i>Postconditions:</i> <code>val_ == 0</code> and <code>cat_ == &amp;generic_category</code><tt><ins>()</ins></tt>.</p>
 </blockquote>
</blockquote>
<p>Change 19.5.3.3 [syserr.errcondition.modifiers] Class error_condition 
modifiers as indicated:</p>
<blockquote>
 <pre>void clear();</pre>
 <blockquote>
 <p><i>Postconditions:</i> <code>value() == 0</code> and <code>category() == 
 generic_category</code><tt><ins>()</ins></tt>.</p>
 </blockquote>
</blockquote>
<p>Change 19.5.3.5 [syserr.errcondition.nonmembers] Class error_condition 
non-member functions as indicated:</p>
<blockquote>
 <pre>error_condition make_error_condition(errc e);</pre>
 <blockquote>
 <p><i>Returns:</i> <tt>error_condition(static_cast&lt;int&gt;(e), generic_category<ins>()</ins>)</tt>.</p>
 </blockquote>
</blockquote>
 <p>Change 27.5 [iostreams.base] Iostreams base classes, Header &lt;ios&gt; 
 synopsis as indicated:</p>
<blockquote>
 <pre>concept_map ErrorCodeEnum&lt;io_errc&gt; { };
error_code make_error_code(io_errc e);
error_condition make_error_condition(io_errc e);
<del>storage-class-specifier</del> const error_category&amp; iostream_category<ins>()</ins>;</pre>
</blockquote>
<p>Change 27.5.2.1.1 [ios::failure] Class ios_base::failure, paragraph 2 as 
indicated:</p>
<blockquote>
<p>When throwing ios_base::failure exceptions, implementations should provide 
values of ec that identify the specific reason for the failure. [ Note: Errors 
arising from the operating system would typically be reported as <tt>
system_category</tt><tt><ins>()</ins></tt> errors with an error value of the 
error number reported by the operating system. Errors arising from within the 
stream library would typically be reported as <tt>error_code(io_errc::stream, 
iostream_category<ins>()</ins>)</tt>. --end note ]</p>
</blockquote>
<p>Change 27.5.5.5 [error.reporting] Error reporting as indicated:</p>
<blockquote>
 <pre>error_code make_error_code(io_errc e);</pre>
 <blockquote>
 <p><i>Returns:</i> <code>error_code(static_cast&lt;int&gt;(e), iostream_category</code><ins>()</ins><code>)</code>.</p>
 </blockquote>
 <pre>error_condition make_error_condition(io_errc e);</pre>
 <blockquote>
 <p><i>Returns:</i> <code>error_condition(static_cast&lt;int&gt;(e), 
 iostream_category</code><ins>()</ins><code>)</code>.</p>
 </blockquote>
 <pre><del>storage-class-specifier</del> const error_category&amp; iostream_category<ins>()</ins>;</pre>
 <blockquote>
 <del><p>The implementation shall initialize iostream_category. Its storage-class-specifier 
 may be static or extern. It is unspecified whether initialization is static 
 or dynamic (3.6.2). If initialization is dynamic, it shall occur before 
 completion of the dynamic initialization of the first translation unit 
 dynamically initialized that includes header &lt;system_error&gt;.</p></del>
<p>
<ins><i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.</ins>
</p>
<p><i>Remarks:</i> The object's default_error_condition and equivalent virtual functions shall 
behave as specified for the class error_category. The object's name virtual 
function shall return a pointer to the string "iostream".</p>
 </blockquote>
</blockquote>







<hr>
<h3><a name="891"></a>891. std::thread, std::call_once issue</h3>
<p><b>Section:</b> 30.3.1.2 [thread.thread.constr], 30.4.4.2 [thread.once.callonce] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I notice that the vararg overloads of <tt>std::thread</tt> and <tt>std::call_once</tt>
(N2723 30.3.1.2 [thread.thread.constr] and 30.4.4.2 [thread.once.callonce]) are no longer specified in terms of
<tt>std::bind</tt>; instead, some of the <tt>std::bind</tt> wording has been inlined into
the specification.
</p>
<p>
There are two problems with this.
</p>
<p>
First, the specification (and implementation) in terms of <tt>std::bind</tt> allows, for example:
</p>

<blockquote><pre>std::thread th( f, 1, std::bind( g ) );
</pre></blockquote>

<p>
which executes <tt>f( 1, g() )</tt> in a thread. This can be useful. The
"inlined" formulation changes it to execute <tt>f( 1, bind(g) )</tt> in a thread.
</p>
<p>
Second, assuming that we don't want the above, the specification has copied the wording
</p>

<blockquote>
<tt>INVOKE(func, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid
expression for some values <tt>w1, w2, ..., wN</tt>
</blockquote>

<p>
but this is not needed since we know that our argument list is args; it should simply be
</p>

<blockquote>
<tt>INVOKE(func, args...)</tt> (20.6.2) shall be a valid expression
</blockquote>

<p><i>[
Summit:
]</i></p>


<blockquote>
Move to open.
</blockquote>

<p><i>[
Post Summit Anthony provided proposed wording.
]</i></p>


<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Leave Open. Await decision for thread variadic constructor.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
See proposed wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> for this, for the formulation
on how to solve this.  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> modifies the thread constructor to
have "pass by value" behavior with pass by reference efficiency through the use
of the <tt>decay</tt> trait.  This same formula would be useful for <tt>call_once</tt>.
</blockquote>

<p><i>[
2010-02-11 Anthony updates wording.
]</i></p>


<p><i>[
2010-02-12 Moved to Tentatively Ready after 5 postive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Modify 30.4.4.2 [thread.once.callonce] p1-p2 with the following:
</p>

<blockquote>
<pre>template&lt;class Callable, class ...Args&gt;
  void call_once(once_flag&amp; flag, Callable<ins>&amp;&amp;</ins> func, Args&amp;&amp;... args);</pre>
<blockquote>

<p><ins>
Given a function as follows:
</ins></p>

<blockquote><pre><ins>
template&lt;typename T&gt; typename decay&lt;T&gt;::type decay_copy(T&amp;&amp; v)
   { return std::forward&lt;T&gt;(v); }
</ins></pre></blockquote>

<p>
1 <i>Requires:</i> <del>The template parameters</del> <tt>Callable</tt> and each
<tt>Ti</tt> in <tt>Args</tt> shall <del>be <tt>CopyConstructible</tt> if an
lvalue and otherwise</del> <ins>satisfy the</ins>
<tt>MoveConstructible</tt> <ins>requirements</ins>.
<tt><i>INVOKE</i>(<ins>decay_copy(std::forward&lt;Callable&gt;(</ins>func<ins>)</ins>,
<del>w1, w2, ..., wN</del>
<ins>decay_copy(std::forward&lt;Args&gt;(args))...</ins>)</tt> (20.8.2 [func.require]) shall be a valid expression<del> for some values <tt>w1,
w2, ..., wN</tt>, where <tt>N == sizeof...(Args)</tt></del>.
</p>

<p>
2 <i>Effects:</i> Calls to <tt>call_once</tt> on the same <tt>once_flag</tt>
object are serialized. If there has been a prior effective call to
<tt>call_once</tt> on the same <tt>once_flag</tt> object, the call to
<tt>call_once</tt> returns without invoking <tt>func</tt>. If there has been no
prior effective call to <tt>call_once</tt> on the same <tt>once_flag</tt>
object, <del>the argument <tt>func</tt> (or a copy thereof) is called as if by
invoking <tt>func(args)</tt></del>
<ins><tt><i>INVOKE</i>(decay_copy(std::forward&lt;Callable&gt;(func)),
decay_copy(std::forward&lt;Args&gt;(args))...)</tt> is executed</ins>. The call
to <tt>call_once</tt> is effective if and only if <del><tt>func(args)</tt></del>
<ins><tt><i>INVOKE</i>(decay_copy(std::forward&lt;Callable&gt;(func)),
decay_copy(std::forward&lt;Args&gt;(args))...)</tt></ins> returns without
throwing an exception. If an exception is thrown it is propagated to the caller.
</p>

</blockquote>

</blockquote>







<hr>
<h3><a name="893"></a>893. std::mutex issue</h3>
<p><b>Section:</b> 30.4.1.2.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a></p>
<p><b>Discussion:</b></p>
<p>
30.4.1.2.1 [thread.mutex.class]/27 (in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
says that the behavior is undefined if:
</p>
<ul>
<li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or
<tt>try_lock()</tt> on that object</li>
</ul>
<p>
I don't believe that this is right. Calling <tt>lock()</tt> or <tt>try_lock()</tt> on a
locked <tt>mutex</tt> is well defined in the general case. <tt>try_lock()</tt> is required
to fail and return <tt>false</tt>. <tt>lock()</tt> is required to either throw an
exception (and is allowed to do so if it detects deadlock) or to block
until the <tt>mutex</tt> is free. These general requirements apply regardless of
the current owner of the <tt>mutex</tt>; they should apply even if it's owned by
the current thread.
</p>
<p>
Making double <tt>lock()</tt> undefined behavior probably can be justified (even
though I'd still disagree with the justification), but <tt>try_lock()</tt> on a
locked <tt>mutex</tt> must fail.
</p>

<p><i>[
Summit:
]</i></p>

<blockquote>
<p>
Move to open. Proposed resolution:
</p>
<ul>
<li>
In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error
condition for <tt>resource_deadlock_would_occur</tt> to: "if the implementation
detects that a deadlock would occur"
</li>
<li>
Strike 30.4.1.2.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object
calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or"
</li>
</ul>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Move to Review. Alisdair to provide note.
</blockquote>

<p><i>[
2009-07-31 Alisdair provided note.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>

<p><i>[
2009-11-18 Peter Opens:
]</i></p>


<blockquote>
<p>
I don't believe that the proposed note:
</p>

<blockquote>
[<i>Note:</i> a program may deadlock if the thread that owns a <tt>mutex</tt>
object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object. If the program can
detect the deadlock, a <tt>resource_deadlock_would_occur</tt> error condition may
be observed. � <i>end note</i>]
</blockquote>

<p>
is entirely correct. "or <tt>try_lock()</tt>" should be removed, because
<tt>try_lock</tt> is non-blocking and doesn't deadlock; it just returns
<tt>false</tt> when it fails to lock the mutex.
</p>

<p><i>[
Howard: I've set to Open and updated the wording per Peter's suggestion.
]</i></p>


</blockquote>

<p><i>[
2009-11-18 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
</p>

<blockquote>
<ul>
<li>...</li>
<li>
<tt>resource_deadlock_would_occur</tt> -- if the <del>current thread already owns the mutex and is able 
to detect it</del> <ins>implementation detects that a deadlock would occur</ins>.
</li>
<li>...</li>
</ul>
</blockquote>

<p>
Strike 30.4.1.2.1 [thread.mutex.class] paragraph 3 bullet 2:
</p>
<blockquote>
<p>
-3- The behavior of a program is undefined if:
</p>
<ul>
<li>...</li>
<li>
<del>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</del>
</li>
<li>...</li>
</ul>
</blockquote>

<p>
Add the following note after p3 30.4.1.2.1 [thread.mutex.class]
</p>

<blockquote>
[<i>Note:</i> a program may deadlock if the thread that owns a <tt>mutex</tt>
object calls <tt>lock()</tt> on that object. If the implementation can detect the
deadlock, a <tt>resource_deadlock_would_occur</tt> error condition may be
observed. � <i>end note</i>]
</blockquote>






<hr>
<h3><a name="894"></a>894. longjmp and destructors</h3>
<p><b>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Lawrence Crowl, Alisdair Meredith <b>Opened:</b> 2008-09-17 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.runtime">issues</a> in [support.runtime].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The interaction between <tt>longjmp</tt> and exceptions seems unnecessarily
restrictive and not in keeping with existing practice.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Edit paragraph 4 of 18.10 [support.runtime] as follows:
</p>

<blockquote>
The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
restricted behavior in this International Standard. A
<tt>setjmp/longjmp</tt> call pair has undefined behavior if replacing the
<tt>setjmp</tt> and <tt>longjmp</tt> by <tt>catch</tt> and
<tt>throw</tt> would <del>destroy</del>
<ins>invoke any non-trivial destructors for</ins>
any automatic objects.
</blockquote>





<hr>
<h3><a name="896"></a>896. Library thread safety issue</h3>
<p><b>Section:</b> 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is unclear whether <tt>shared_ptr</tt> is thread-safe in the sense that
multiple threads may simultaneously copy a <tt>shared_ptr</tt>.  However this
is a critical piece of information for the client, and it has significant
impact on usability for many applications.  (Detlef Vollman thinks it
is currently clear that it is not thread-safe.  Hans Boehm thinks
it currently requires thread safety, since the <tt>use_count</tt> is not an
explicit field, and constructors and assignment take a const reference
to an existing <tt>shared_ptr</tt>.)
</p>

<p>
Pro thread-safety:
</p>
<p>
Many multi-threaded usages are impossible.  A thread-safe version can
be used to destroy an object when the last thread drops it, something
that is often required, and for which we have no other easy mechanism.
</p>
<p>
Against thread-safety:
</p>
<p>
The thread-safe version is well-known to be far more expensive, even
if used by a single thread.  Many applications, including all single-threaded
ones, do not care.
</p>

<p><i>[
San Francisco:
]</i></p>


<blockquote>
<p>
Beman: this is a complicated issue, and would like to move this to Open
and await comment from Peter Dimov; we need very careful and complete
rationale for any decision we make; let's go slow
</p>
<p>
Detlef: I think that <tt>shared_ptr</tt> should not be thread-safe.
</p>
<p>
Hans: When you create a thread with a lambda, it in some cases makes it
very difficult for the lambda to reference anything in the heap. It's
currently ambiguous as to whether you can use a <tt>shared_ptr</tt> to get at an
object.
</p>
<p>
Leave in Open. Detlef will submit an alternative proposed resolution
that makes <tt>shared_ptr</tt> explicitly unsafe.
</p>
<p>
A third option is to support both threadsafe and non-safe share_ptrs,
and to let the programmer decide which behavior they want.
</p>

<p>
Beman:  Peter, do you support the PR?
</p>

<p>
Peter:
</p>
<blockquote>
<p>
Yes, I support the proposed resolution, and I certainly oppose any
attempts to <tt>make shared_ptr</tt> thread-unsafe.
</p>
<p>
I'd mildly prefer if
</p>
<blockquote>
[<i>Note:</i> This is true in spite of that fact that such functions often
modify <tt>use_count()</tt> <i>--end note</i>]
</blockquote>
<p>
is changed to
</p>
<blockquote>
[<i>Note:</i> This is true in spite of that fact that such functions often
cause a change in <tt>use_count()</tt> <i>--end note</i>]
</blockquote>
<p>
(or something along these lines) to emphasise that <tt>use_count()</tt> is not,
conceptually, a variable, but a return value.
</p>
</blockquote>

</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Vote: Do we want one thread-safe shared pointer or two? If two, one
would allow concurrent construction and destruction of shared pointers,
and one would not be thread-safe. If one, then it would be thread-safe.
</p>
<p>
No concensus on that vote.
</p>
<p>
Hans to improve wording in consultation with Pete. Leave Open.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready. Ask Editor to clear up wording a little when integrating to
make it clear that the portion after the first comma only applies for
the presence of data races.
</blockquote>

<p><i>[
2009-10-24 Hans adds:
]</i></p>


<blockquote>
<p>
I think we need to pull 896 back from ready, unfortunately.  My wording
doesn't say the right thing.
</p>

<p>
I suspect we really want to say something along the lines of:
</p>

<blockquote>
For purposes of determining the presence of a data race, member
functions access and modify only the <tt>shared_ptr</tt> and
<tt>weak_ptr</tt> objects themselves and not objects they refer to.
Changes in <tt>use_count()</tt> do not reflect modifications that can
introduce data races.
</blockquote>

<p>
But I think this needs further discussion by experts to make sure this
is right.
</p>

<p>
Detlef and I agree continue to disagree on the resolution, but I think
we agree that it would be good to try to expedite this so that it can be
in CD2, since it's likely to generate NB comments no matter what we do.
And lack of clarity of intent is probably the worst option.  I think it
would be good to look at this between meetings.
</p>
</blockquote>

<p><i>[
2010-01-20 Howard:
]</i></p>


<blockquote>
<p>
I've moved Hans' suggested wording above into the proposed resolution section
and preserved the previous wording here:
</p>

<blockquote>
<p>
Make it explicitly thread-safe, in this weak sense, as I believe was intended:
</p>
<p>
Insert in 20.9.10.2 [util.smartptr.shared], before p5:
</p>
<blockquote>
<p>
For purposes of determining the presence of a data race,
member functions do not modify <tt>const shared_ptr</tt> and
const <tt>weak_ptr</tt> arguments, nor any objects they
refer to.  [<i>Note:</i> This is true in spite of that fact that such functions often
cause a change in <tt>use_count()</tt> <i>--end note</i>]
</p>
</blockquote>
<p>
On looking at the text, I'm not sure we need a similar disclaimer
anywhere else, since nothing else has the problem with the modified
<tt>use_count()</tt>.  I think Howard arrived at a similar conclusion.
</p>
</blockquote>
</blockquote>

<p><i>[
2010 Pittsburgh:  Moved to Ready for Pittsburgh
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Insert a new paragraph at the end of 20.9.10.2 [util.smartptr.shared]:
</p>

<blockquote>
For purposes of determining the presence of a data race, member functions access
and modify only the <tt>shared_ptr</tt> and <tt>weak_ptr</tt> objects themselves
and not objects they refer to. Changes in <tt>use_count()</tt> do not reflect
modifications that can introduce data races.
</blockquote>





<hr>
<h3><a name="898"></a>898. Small contradiction in n2723 to forward to committee</h3>
<p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Arch Robison <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I ran across a small contradiction in working draft n2723. 
</p>
<blockquote>
<p>
23.3.3 [forwardlist]p2: A <tt>forward_list</tt> satisfies all of the
requirements of a container (table 90), except that the <tt>size()</tt> member
function is not provided.
</p>
<p>
23.3.3.5 [forwardlist.ops]p57: <i>Complexity:</i> At most <tt>size() + x.size() - 1</tt>
comparisons.
</p>
</blockquote>
<p>
Presumably 23.3.3.5 [forwardlist.ops]p57 needs to be rephrased to not use
<tt>size()</tt>, or note that it is used there only for sake of notational convenience. 
</p>

<p><i>[
2009-03-29 Beman provided proposed wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We agree with the proposed resolution.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p><i>Change 23.3.3.5 [forwardlist.ops],
forward_list operations, paragraph 19, merge complexity as indicated:
</i></p>
<blockquote><i>Complexity:</i> At most <tt><del>size() + x.size()</del>
<ins>distance(begin(), end()) + distance(x.begin(), x.end())</ins> - 1</tt>
comparisons.
</blockquote>





<hr>
<h3><a name="899"></a>899. Adjusting <tt>shared_ptr</tt> for <tt>nullptr_t</tt></h3>
<p><b>Section:</b> 20.9.10.2.2 [util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
James Dennett, message c++std-lib-22442:
</p>
<blockquote>
The wording below addresses one case of this, but opening an
issue to address the need to sanity check uses of the term "pointer"
in 20.9.10.2 [util.smartptr.shared] would be a good thing.
</blockquote>
<p>
There's one more reference, in <tt>~shared_ptr;</tt> we can apply your suggested change to it, too. That is:
</p>
<p>
Change 20.9.10.2.2 [util.smartptr.shared.dest]/1 second bullet from:
</p>
<blockquote>
Otherwise, if *this owns a pointer p and a deleter d, d(p) is called.
</blockquote>
<p>
to:
</p>
<blockquote>
Otherwise, if *this owns an object p and a deleter d, d(p) is called.
</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend Review.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Peter Dimov notes the analogous change has already been made
to "the new nullptr_t taking constructors
in 20.9.10.2.1 [util.smartptr.shared.const] p9-13."
</p>
<p>
We agree with the proposed resolution.
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.10.2.2 [util.smartptr.shared.dest]/1 second bullet:
</p>
<blockquote>
<ul>
<li>...</li>
<li>
Otherwise, if <tt>*this</tt> <i>owns</i> <del>a pointer</del>
<ins>an object</ins> <tt>p</tt> and a
deleter <tt>d</tt>, <tt>d(p)</tt> is called.
</li>
</ul>
</blockquote>





<hr>
<h3><a name="900"></a>900. stream move-assignment</h3>
<p><b>Section:</b> 27.9.1.8 [ifstream.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-09-20 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It
appears that we have an issue similar to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> regarding the move-assignment of
stream types. For example, when assigning to an <tt>std::ifstream</tt>,
<tt>ifstream1</tt>, it seems preferable to close the file originally held by
<tt>ifstream1</tt>:
</p>

<blockquote><pre>ifstream1 = std::move(ifstream2); 
</pre></blockquote>

<p>
The current Draft
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
specifies that the move-assignment of
stream types like <tt>ifstream</tt> has the same effect as a swap:
</p>

<blockquote>
<p>
Assign and swap 27.9.1.8 [ifstream.assign]
</p>
<pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs); 
</pre>
<blockquote>
<i>Effects:</i> <tt>swap(rhs)</tt>.
</blockquote>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Howard agrees with the analysis and the direction proposed.
</p>
<p>
Move to Open pending specific wording to be supplied by Howard.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Howard is going to write wording.
</blockquote>

<p><i>[
2009-07-26 Howard provided wording.
]</i></p>


<p><i>[
2009-09-13 Niels adds:
]</i></p>


<blockquote>
Note: The proposed change of 27.9.1.3 [filebuf.assign]/1 depends on the
resolution of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204">1204</a>, which allows implementations to assume that
<tt>*this</tt> and <tt>rhs</tt> refer to different objects.
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Leave as Open.  Too closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#911">911</a> to move on at this time.
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to Ready for Pittsburgh.
</blockquote>



<p><b>Proposed resolution:</b></p>

<p>
Change 27.8.1.2 [stringbuf.assign]/1:
</p>

<blockquote><pre>basic_stringbuf&amp; operator=(basic_stringbuf&amp;&amp; rhs);
</pre>
<blockquote>
-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
<ins>After the move assignment <tt>*this</tt> reflects the same observable
state it would have if it had been move constructed from <tt>rhs</tt>
(27.8.1.1 [stringbuf.cons]).
</ins>
</blockquote>
</blockquote>

<p>
Change 27.8.2.2 [istringstream.assign]/1:
</p>

<blockquote><pre>basic_istringstream&amp; operator=(basic_istringstream&amp;&amp; rhs);
</pre>
<blockquote>
-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
<ins>Move assigns the base and members of <tt>*this</tt> with the respective
base and members of <tt>rhs</tt>.
</ins>
</blockquote>
</blockquote>

<p>
Change 27.8.3.2 [ostringstream.assign]/1:
</p>

<blockquote><pre>basic_ostringstream&amp; operator=(basic_ostringstream&amp;&amp; rhs);
</pre>
<blockquote>
-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
<ins>Move assigns the base and members of <tt>*this</tt> with the respective
base and members of <tt>rhs</tt>.
</ins>
</blockquote>
</blockquote>

<p>
Change 27.8.5.1 [stringstream.assign]/1:
</p>

<blockquote><pre>basic_stringstream&amp; operator=(basic_stringstream&amp;&amp; rhs);
</pre>
<blockquote>
-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
<ins>Move assigns the base and members of <tt>*this</tt> with the respective
base and members of <tt>rhs</tt>.
</ins>
</blockquote>
</blockquote>

<p>
Change 27.9.1.3 [filebuf.assign]/1:
</p>

<blockquote><pre>basic_filebuf&amp; operator=(basic_filebuf&amp;&amp; rhs);
</pre>
<blockquote>
-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
<ins>Begins by calling <tt>this-&gt;close()</tt>.
After the move assignment <tt>*this</tt> reflects the same observable
state it would have if it had been move constructed from <tt>rhs</tt>
(27.9.1.2 [filebuf.cons]).
</ins>
</blockquote>
</blockquote>

<p>
Change 27.9.1.8 [ifstream.assign]/1:
</p>

<blockquote><pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs);
</pre>
<blockquote>
-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
<ins>Move assigns the base and members of <tt>*this</tt> with the respective
base and members of <tt>rhs</tt>.</ins>
</blockquote>
</blockquote>

<p>
Change 27.9.1.12 [ofstream.assign]/1:
</p>

<blockquote><pre>basic_ofstream&amp; operator=(basic_ofstream&amp;&amp; rhs);
</pre>
<blockquote>
-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
<ins>Move assigns the base and members of <tt>*this</tt> with the respective
base and members of <tt>rhs</tt>.</ins>
</blockquote>
</blockquote>

<p>
Change 27.9.1.16 [fstream.assign]/1:
</p>

<blockquote><pre>basic_fstream&amp; operator=(basic_fstream&amp;&amp; rhs);
</pre>
<blockquote>
-1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
<ins>Move assigns the base and members of <tt>*this</tt> with the respective
base and members of <tt>rhs</tt>.</ins>
</blockquote>
</blockquote>






<hr>
<h3><a name="904"></a>904. result_of argument types</h3>
<p><b>Section:</b> X [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.ret">issues</a> in [func.ret].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The WP and TR1 have the same text regarding the argument types of a
<tt>result_of</tt> expression:
</p>
<blockquote>
The values <tt>ti</tt> are lvalues when the corresponding type <tt>Ti</tt> is a
reference type, and rvalues otherwise.
</blockquote>
<p>
I read this to mean that this compiles:
</p>
<blockquote><pre>typedef int (*func)(int&amp;);
result_of&lt;func(int&amp;&amp;)&gt;::type i = 0;
</pre></blockquote>
<p>
even though this doesn't:
</p>
<blockquote><pre>int f(int&amp;);
f( std::move(0) );
</pre></blockquote>
<p>
Should the text be updated to say "when <tt>Ti</tt> is an lvalue-reference
type" or am I missing something?
</p>
<p>
I later came up with this self-contained example which won't compile,
but I think it should:
</p>
<blockquote><pre>struct X {
  void operator()(int&amp;);
  int operator()(int&amp;&amp;);
} x;

std::result_of&lt; X(int&amp;&amp;) &gt;::type i = x(std::move(0));
</pre></blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change X [func.ret], p1:
</p>

<blockquote>
... The values <tt>ti</tt> are lvalues 
when the corresponding type <tt>Ti</tt> is a<ins>n</ins> <ins>lvalue-</ins>reference type,
and rvalues otherwise. 
</blockquote>





<hr>
<h3><a name="907"></a>907. Bitset's immutable element retrieval is inconsistently defined</h3>
<p><b>Section:</b> 20.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current standard 14882::2003(E) as well as the current draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
have in common a contradiction of the operational semantics
of member function test 20.5.2 [bitset.members]/56-58 and the immutable
member <tt>operator[]</tt> overload 20.5.2 [bitset.members]/64-66 (all references
are defined in terms of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>):
</p>

<ol>
<li><pre>bool test(size_t pos) const;
</pre>
<blockquote>
<p>
<i>Requires:</i> <tt>pos</tt> is valid
</p>
<p>
<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond
to a valid bit position.
</p>
<p>
<i>Returns:</i> <tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
has the value one.
</p>
</blockquote>
</li>
<li><pre>constexpr bool operator[](size_t pos) const;
</pre>
<blockquote>
<p>
<i>Requires:</i> <tt>pos</tt> shall be valid.
</p>
<p>
<i>Throws:</i> nothing.
</p>
<p>
<i>Returns:</i> <tt>test(pos)</tt>.
</p>
</blockquote>
</li>
</ol>

<p>
Three interpretations:
</p>

<ol type="A">
<li>
The <tt>operator[]</tt> overload is indeed allowed to throw an exception
(via <tt>test()</tt>, if <tt>pos</tt> corresponds to an invalid bit position) which does
not leave the call frame. In this case this function cannot be a
<tt>constexpr</tt> function, because <tt>test()</tt> is not, due to
5.19 [expr.const]/2, last bullet.
</li>
<li>
The intend was not to throw an exception in <tt>test</tt> in case of an
invalid bit position. There is only little evidence for this interpretation.
</li>
<li>
The intend was that <tt>operator[]</tt> should not throw any exception,
but that <tt>test</tt> has the contract to do so, if the provided bit position
is invalid.
</li>
</ol>

<p>
The problem became worse, because issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
recently voted into WP argued that member <tt>test</tt> logically must be
a <tt>constexpr</tt> function, because it was used to define the semantics
of another <tt>constexpr</tt> function (the <tt>operator[]</tt> overload).
</p>

<p>
Three alternatives are proposed, corresponding to the three bullets
(A), (B), and (C), the author suggests to follow proposal (C).
</p>

<b>
Proposed alternatives:
</b>

<ol type="A">
<li>
<p>
Remove the <tt>constexpr</tt> specifier in front of <tt>operator[]</tt> overload and
undo that of member <tt>test</tt> (assuming <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a> is accepted) in both the
class declaration 20.5 [template.bitset]/1 and in the member description
before 20.5.2 [bitset.members]/56 and before /64 to read:
</p>
<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
..
<del>constexpr</del> bool operator[](size_t pos) const;
</pre></blockquote>

<p>
Change the throws clause of p. 65 to read:
</p>

<blockquote>
<i>Throws:</i> <del>nothing</del>
<ins><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
position</ins>.
</blockquote>
</li>
<li>
<p>
Replace the throws clause p. 57 to read:
</p>

<blockquote>
<i>Throws:</i> <del><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
position</del> <ins>nothing</ins>.
</blockquote>
</li>
<li>
<p>
Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
function in both class declaration 20.5 [template.bitset]/1 and in the
member description before 20.5.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
was applied.
</p>

<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
</pre></blockquote>

<p>
Change the returns clause p. 66 to read:
</p>

<blockquote>
<i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
has the value one, otherwise <tt>false</tt></ins>.
</blockquote>
</li>
</ol>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Lawrence: proposed resolutions A, B, C are mutually exclusive.
</p>
<p>
Recommend Review with option C.
</p>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>

<ol type="A" ,="" start="3">
<li>
<p>
Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
function in both class declaration 20.5 [template.bitset]/1 and in the
member description before 20.5.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
was applied.
</p>

<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
</pre></blockquote>

<p>
Change the returns clause p. 66 to read:
</p>

<blockquote>
<i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
has the value one, otherwise <tt>false</tt></ins>.
</blockquote>
</li>
</ol>






<hr>
<h3><a name="909"></a>909. <tt>regex_token_iterator</tt> should use <tt>initializer_list</tt></h3>
<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 319</b></p>
<p>
Construction of a <tt>regex_token_iterator</tt> (28.12.2 [re.tokiter]/6+) usually
requires the provision of a sequence of integer values, which
can currently be done via a <tt>std::vector&lt;int&gt;</tt> or
a C array of <tt>int</tt>. Since the introduction of <tt>initializer_list</tt> in the
standard it seems much more reasonable to provide a
corresponding constructor that accepts an <tt>initializer_list&lt;int&gt;</tt>
instead. This could be done as a pure addition or one could
even consider replacement. The author suggests the
replacement strategy (A), but provides an alternative additive
proposal (B) as a fall-back, because of the handiness of this
range type:
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We strongly recommend alternative B of the proposed resolution
in order that existing code not be broken.
With that understanding, move to Tentatively Ready.
</blockquote>

<p><b>Original proposed wording:</b></p>

<ol type="A">
<li><br>
<ol>
<li>
<p>
In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 change the
constructor declaration:
</p>

<blockquote><pre><del>template &lt;std::size_t N&gt;</del>
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp; re,
                     <del>const int (&amp;submatches)[N]</del> <ins>initializer_list&lt;int&gt; submatches</ins>,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default);
</pre></blockquote>
</li>

<li>
<p>
In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
</p>

<blockquote>
The third constructor initializes the member <tt>subs</tt> to hold
a copy of the sequence of integer values pointed to by the
iterator range <tt>[<del>&amp;</del>submatches<ins>.begin()</ins>,
<del>&amp;</del>submatches<ins>.end()</ins> <del>+ N</del>)</tt>.
</blockquote>
</li>
</ol>
</li>

<li><br>
<ol>
<li>
<p>
In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
following constructor declaration between the already existing ones
accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
</p>

<blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp; re,
                     initializer_list&lt;int&gt; submatches,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default);
</pre></blockquote>
</li>
<li>
<p>
In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
</p>

<blockquote>
The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
to hold a copy of the sequence of integer values pointed to
by the iterator range <tt>[&amp;submatches,&amp;submatches + N)</tt>
<ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
</blockquote>
</li>
</ol>
</li>

</ol>



<p><b>Proposed resolution:</b></p>

<ol type="A" start="2">

<li><br>
<ol>
<li>
<p>
In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
following constructor declaration between the already existing ones
accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
</p>

<blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
                     const regex_type&amp; re,
                     initializer_list&lt;int&gt; submatches,
                     regex_constants::match_flag_type m =
                       regex_constants::match_default);
</pre></blockquote>
</li>
<li>
<p>
In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
</p>

<blockquote>
The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
to hold a copy of the sequence of integer values pointed to
by the iterator range <tt>[&amp;submatches,&amp;submatches + N)</tt>
<ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
</blockquote>
</li>
</ol>
</li>

</ol>






<hr>
<h3><a name="911"></a>911. I/O streams and <tt>move/swap</tt> semantic</h3>
<p><b>Section:</b> 27.7.1 [input.streams], 27.7.2 [output.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Class template <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
implements public move constructors, move assignment operators and <tt>swap</tt>
method and free functions. This might induce both the user and the
compiler to think that those types are <tt>MoveConstructible</tt>, <tt>MoveAssignable</tt>
and <tt>Swappable</tt>. However, those class templates fail to fulfill the user
expectations. For example:
</p>

<blockquote><pre>std::ostream os(std::ofstream("file.txt"));
assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed

std::vector&lt;std::ostream&gt; v;
v.push_back(std::ofstream("file.txt"));
v.reserve(100); // causes reallocation
assert(v[0].rdbuf() == 0); // file.txt has been closed!

std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
os1 = std::ofstream("file2.txt");
os1 &lt;&lt; "hello, world"; // still writes to file1.txt, not to file2.txt!

std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
std::ostream&amp;&amp; os2 = std::ofstream("file2.txt");
std::swap(os1, os2);
os1 &lt;&lt; "hello, world"; // writes to file1.txt, not to file2.txt!
</pre></blockquote>

<p>
This is because the move constructor, the move assignment operator and
<tt>swap</tt> are all implemented through calls to <tt>std::basic_ios</tt> member
functions <tt>move()</tt> and <tt>swap()</tt> that do not move nor swap the controlled
stream buffers. That can't happen because the stream buffers may have
different types.
</p>

<p>
Notice that for <tt>basic_streambuf</tt>, the member function <tt>swap()</tt> is
protected. I believe that is correct and all of <tt>basic_istream</tt>,
<tt>basic_ostream</tt>, <tt>basic_iostream</tt> should do the same as the move ctor, move
assignment operator and swap member function are needed by the derived
<tt>fstream</tt>s and <tt>stringstream</tt>s template. The free swap functions for
<tt>basic_(i|o|io)stream</tt> templates should be removed for the same reason.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We note that the rvalue swap functions have already been removed.
</p>
<p>
Bill is unsure about making the affected functions protected;
he believes they may need to be public.
</p>
<p>
We are also unsure about removing the lvalue swap functions as proposed.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
It's not clear that the use case is compelling.
</p>
<p>
Howard: This needs to be implemented and tested.
</p>
</blockquote>

<p><i>[
2009-07-26 Howard adds:
]</i></p>


<blockquote>
<p>
I started out thinking I would recommend NAD for this one.  I've turned around
to agree with the proposed resolution (which I've updated to the current draft).
I did not fully understand Ganesh's rationale, and attempt to describe my
improved understanding below.
</p>

<p>
The move constructor, move assignment operator, and swap function are different
for <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
than other classes.  A timely conversation with Daniel reminded me of this long
forgotten fact.  These members are sufficiently different that they would be
extremely confusing to use in general, but they are very much needed for derived
clients.
</p>

<ul>
<li>
The move constructor moves everything but the <tt>rdbuf</tt> pointer.
</li>
<li>
The move assignment operator moves everything but the <tt>rdbuf</tt> pointer.
</li>
<li>
The swap function swaps everything but the <tt>rdbuf</tt> pointer.
</li>
</ul>

<p>
The reason for this behavior is that for the std-derived classes (stringstreams,
filestreams), the <tt>rdbuf</tt> pointer points back into the class itself
(self referencing).  It can't be swapped or moved.  But this fact isn't born out
at the <tt>stream</tt> level.  Rather it is born out at the <tt>fstream</tt>/<tt>sstream</tt>
level.  And the lower levels just need to deal with that fact by not messing around
with the <tt>rdbuf</tt> pointer which is stored down at the lower levels.
</p>

<p>
In a nutshell, it is very confusing for all of those who are not so intimately
related with streams that they've implemented them.  And it is even fairly
confusing for some of those who have (including myself).  I do not think it is
safe to swap or move <tt>istreams</tt> or <tt>ostreams</tt> because this will
(by necessary design) separate stream state from streambuffer state.  Derived
classes (such as <tt>fstream</tt> and <tt>stringstream</tt> must be used to
keep the stream state and stream buffer consistently packaged as one unit during
a move or swap.
</p>

<p>
I've implemented this proposal and am living with it day to day.
</p>

</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Leave Open.  Pablo expected to propose alternative wording which would rename
move construction, move assignment and swap, and may or may not make them
protected.  This will impact issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>.
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to Ready for Pittsburgh.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
27.7.1.1 [istream]: make the following member functions protected:
</p>

<blockquote><pre>basic_istream(basic_istream&amp;&amp;  rhs);
basic_istream&amp;  operator=(basic_istream&amp;&amp;  rhs);
void  swap(basic_istream&amp;  rhs);
</pre></blockquote>

<p>
Ditto: remove the swap free function signature
</p>

<blockquote><pre><del>// swap: 
template &lt;class charT, class traits&gt; 
  void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
</pre></blockquote>

<p>
27.7.1.1.2 [istream.assign]: remove paragraph 4
</p>

<blockquote><pre><del>template &lt;class charT, class traits&gt; 
  void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
</pre>
<blockquote>
<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
</blockquote>
</blockquote>

<p>
27.7.1.5 [iostreamclass]: make the following member function protected:
</p>

<blockquote><pre>basic_iostream(basic_iostream&amp;&amp;  rhs);
basic_iostream&amp;  operator=(basic_iostream&amp;&amp;  rhs);
void  swap(basic_iostream&amp;  rhs);
</pre></blockquote>

<p>
Ditto: remove the swap free function signature
</p>

<blockquote><pre><del>template &lt;class charT, class traits&gt; 
  void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
</pre></blockquote>

<p>
27.7.1.5.3 [iostream.assign]: remove paragraph 3
</p>

<blockquote><pre><del>template &lt;class charT, class traits&gt; 
  void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
</pre>
<blockquote>
<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
</blockquote>
</blockquote>

<p>
27.7.2.1 [ostream]: make the following member function protected:
</p>

<blockquote><pre>basic_ostream(basic_ostream&amp;&amp;  rhs);
basic_ostream&amp;  operator=(basic_ostream&amp;&amp;  rhs);
void  swap(basic_ostream&amp;  rhs);
</pre></blockquote>

<p>
Ditto: remove the swap free function signature
</p>

<blockquote><pre><del>// swap: 
template &lt;class charT, class traits&gt; 
  void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
</pre></blockquote>

<p>
27.7.2.3 [ostream.assign]: remove paragraph 4 
</p>

<blockquote><pre><del>template &lt;class charT, class traits&gt; 
  void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
</pre>
<blockquote>
<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
</blockquote>
</blockquote>






<hr>
<h3><a name="920"></a>920. Ref-qualification support in the library</h3>
<p><b>Section:</b> 20.8.13 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Bronek Kozicki <b>Opened:</b> 2008-10-06 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.memfn">issues</a> in [func.memfn].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a></p>
<p><b>Discussion:</b></p>
<p>
Daniel Kr�gler wrote:
</p>

<blockquote>
<p>
Shouldn't above list be completed for &amp;- and &amp;&amp;-qualified
member functions This would cause to add:
</p>
<blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
unspecified mem_fn(R (T::* pm)(Args...) &amp;);
template&lt;Returnable R, class T, CopyConstructible... Args&gt;
unspecified mem_fn(R (T::* pm)(Args...) const &amp;);
template&lt;Returnable R, class T, CopyConstructible... Args&gt;
unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;);
template&lt;Returnable R, class T, CopyConstructible... Args&gt;
unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;);
template&lt;Returnable R, class T, CopyConstructible... Args&gt;
unspecified mem_fn(R (T::* pm)(Args...) &amp;&amp;);
template&lt;Returnable R, class T, CopyConstructible... Args&gt;
unspecified mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
template&lt;Returnable R, class T, CopyConstructible... Args&gt;
unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
template&lt;Returnable R, class T, CopyConstructible... Args&gt;
unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
</pre></blockquote>

</blockquote>

<p>
yes, absolutely. Thanks for spotting this. Without this change <tt>mem_fn</tt>
cannot be initialized from pointer to ref-qualified member function. I
believe semantics of such function pointer is well defined.
</p>

<p><i>[
Post Summit Daniel provided wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We need to think about whether we really want to go down the proposed path
of combinatorial explosion.
Perhaps a Note would suffice.
</p>
<p>
We would really like to have an implementation before proceeding.
</p>
<p>
Move to Open, and recommend this be deferred until after the next
Committee Draft has been issued.
</p>
</blockquote>

<p><i>[
2009-10-10 Daniel updated wording to post-concepts.
]</i></p>


<blockquote>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a> has a similar proposed resolution
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change 20.8 [function.objects]/2, header
<tt>&lt;functional&gt;</tt> synopsis as follows:
</p>

<blockquote><pre>// 20.7.14, member function adaptors:
template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::*);

<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...));</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile);</ins>

<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;);</ins>

<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) &amp;&amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const &amp;&amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) volatile &amp;&amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::*)(Args...) const volatile &amp;&amp;);</ins>
</pre></blockquote>
</li>

<li>
<p>
Change the prototype list of 20.8.13 [func.memfn] as follows [NB: The
following text, most notably p.2 and p.3 which
discuss influence of the cv-qualification on the definition of the
base class's first template parameter remains
unchanged. ]:
</p>

<blockquote><pre>template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::* pm);

<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...));</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile);</ins>

<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;);</ins>

<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;&amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;&amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);</ins>
<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);</ins>
</pre></blockquote>
</li>

<li>
<p>
Remove 20.8.13 [func.memfn]/5:
</p>

<blockquote>
<del><i>Remarks:</i> Implementations may implement <tt>mem_fn</tt> as a set of
overloaded function templates.</del>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="921"></a>921. Rational Arithmetic should use template aliases</h3>
<p><b>Section:</b> 20.6.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The compile-time functions that operate on <tt>ratio&lt;N,D&gt;</tt> require the
cumbersome and error-prone "evaluation" of a <tt>type</tt> member using a
meta-programming style that predates the invention of template aliases.
Thus, multiplying three ratios <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> requires the expression:
</p>

<blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;::type&gt;::type
</pre></blockquote>

<p>
The simpler expression:
</p>

<blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;&gt;
</pre></blockquote>

<p>
Could be used by if template aliases were employed in the definitions.
</p>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Jens: not a complete proposed resolution: "would need to make similar change"
</p>
<p>
Consensus: We agree with the direction of the issue.
</p>
<p>
Recommend Open.
</p>
</blockquote>

<p><i>[
2009-05-11 Daniel adds:
]</i></p>


<blockquote>
<p>
Personally I'm <em>not</em> in favor for the addition of:
</p>
<blockquote><pre>typedef ratio type;
</pre></blockquote>
<p>
For a reader of the
standard it's usage or purpose is unclear. I haven't seen similar examples
of attempts to satisfy non-feature complete compilers.
</p>
</blockquote>

<p><i>[
2009-05-11 Pablo adds:
]</i></p>


<blockquote>
<p>
The addition of type to the <tt>ratio</tt> template allows the previous style
(i.e., in the prototype implementations) to remain valid and permits the
use of transitional library implementations for C++03 compilers.  I do
not feel strongly about its inclusion, however, and leave it up to the
reviewers to decide.
</p>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Bill asks for additional discussion in the issue
that spells out more details of the implementation.
Howard points us to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>
which has at least most of the requested details.
Tom is strongly in favor of overflow-checking at compile time.
Pete points out that there is no change of functionality implied.
We agree with the proposed resolution,
but recommend moving the issue to Review
to allow time to improve the discussion if needed.
</blockquote>

<p><i>[
2009-07-21 Alisdair adds:
]</i></p>


<blockquote>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1121">1121</a> for a potentially incompatible proposal.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>

 
 <ol start="0">
<li>
<p>
In 20.6 [ratio]/3 change as indicated:
</p>

<blockquote><pre>// ratio arithmetic
template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins>;
template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins>;
template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins>;
template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins>;
</pre></blockquote>
</li>
<li>
<p>
In 20.6.1 [ratio.ratio], change as indicated:
</p>
<blockquote><pre>namespace std {
  template &lt;intmax_t N, intmax_t D = 1&gt;
  class ratio {
  public:
    <ins>typedef ratio type;</ins>
    static const intmax_t num;
    static const intmax_t den;
  };
}
</pre></blockquote>
</li>
<li>
<p>
In 20.6.2 [ratio.arithmetic] change as indicated:
</p>

<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins><del>{
  typedef <em>see below</em> type;
}</del>;
</pre>

<blockquote>
<p>
1 The <del>nested typedef</del> type <tt><ins>ratio_add&lt;R1, R2&gt;</ins></tt>
shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
where <tt>T1</tt> has the value <tt>R1::num * R2::den + R2::num * R1::den</tt> and <tt>T2</tt>
has the value <tt>R1::den * R2::den</tt>.
</p>
</blockquote>
</blockquote>
<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins><del>{
  typedef <em>see below</em> type;
}</del>;
</pre>
<blockquote>
<p>
2 The <del>nested typedef</del> type <tt><ins>ratio_subtract&lt;R1, R2&gt;</ins></tt>
shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num * R1::den</tt> and <tt>T2</tt>
has the value <tt>R1::den * R2::den</tt>.
</p>
</blockquote>
</blockquote>
<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins><del>{
  typedef <em>see below</em> type;
}</del>;
</pre>
<blockquote>
<p>
3 The <del>nested typedef</del> type <tt><ins>ratio_multiply&lt;R1, R2&gt;</ins></tt>
shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
where <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
</p>
</blockquote>
</blockquote>
<blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins><del>{
  typedef <em>see below</em> type;
}</del>;
</pre>
<blockquote>
<p>
4 The <del>nested typedef</del> type <tt><ins>ratio_divide&lt;R1, R2&gt;</ins></tt>
shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
where <tt>T1</tt> has the value <tt>R1::num * R2::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
</p>
</blockquote>
</blockquote>
</li>
<li>
<p>
In 20.11.3.1 [time.duration.cons]/4 change as indicated:
</p>
<blockquote>
<p>
<i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be true or
<tt>ratio_divide&lt;Period2, period&gt;::<del>type::</del>den</tt> shall be 1.[..]
</p>
</blockquote>
</li>
<li>
<p>
In 20.11.3.7 [time.duration.cast]/2 change as indicated:
</p>
<blockquote>
<p>
<i>Returns:</i> Let CF be <tt>ratio_divide&lt;Period, typename
ToDuration::period&gt;<del>::type</del></tt>, and [..]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="922"></a>922. [func.bind.place] Number of placeholders</h3>
<p><b>Section:</b> B [implimits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-10-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE 24</b></p>

<p>
With respect to the section 20.8.10.1.3 [func.bind.place]:
</p>
<p>
TR1 dropped some suggested implementation quantities for the number of
placeholders. The purpose of this defect is to put these back for C++0x.
</p>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
see DE 24
</p>
<p>
Recommend applying the proposed resolution from DE 24, with that
Tentatively Ready.
</p>
</blockquote>

<b>Original proposed resolution:</b>

<p>
Add 20.8.10.1.3 [func.bind.place]/2:
</p>

<blockquote>
While the exact number of placeholders (<tt>_M</tt>) is implementation defined,
this number shall be at least 10.
</blockquote>



<p><b>Proposed resolution:</b></p>

<p>
Add to B [implimits]:
</p>

<ul>
<li>
Number of placeholders (20.8.10.1.3 [func.bind.place]) [10].
</li>
</ul>






<hr>
<h3><a name="925"></a>925. <tt>shared_ptr</tt>'s explicit conversion from <tt>unique_ptr</tt></h3>
<p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Rodolfo Lima <b>Opened:</b> 2008-10-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current working draft
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
section 20.9.10.2.1 [util.smartptr.shared.const] declares
<tt>shared_ptr</tt>'s constructor that takes a rvalue reference to <tt>unique_ptr</tt> and
<tt>auto_ptr</tt> as being explicit, affecting several valid smart pointer use
cases that would take advantage of this conversion being implicit, for
example:
</p>

<blockquote><pre>class A;
std::unique_ptr&lt;A&gt; create();
void process(std::shared_ptr&lt;A&gt; obj);

int main()
{
   process(create());                  // use case #1
   std::unique_ptr&lt;A&gt; uobj = create();
   process(std::move(uobj));           // use case #2
   return 0;
}
</pre></blockquote>

<p>
If <tt>unique_ptr</tt> to <tt>shared_ptr</tt> conversions are explicit, the above lines
should be written:
</p>

<blockquote><pre>process(std::shared_ptr&lt;A&gt;(create()));        // use case #1
process(std::shared_ptr&lt;A&gt;(std::move(uobj))); // use case #2
</pre></blockquote>

<p>
The extra cast required doesn't seems to give any benefits to the user,
nor protects him of any unintended conversions, this being the raison
d'etre of explicit constructors.
</p>

<p>
It seems that this constructor was made explicit to mimic the conversion
from <tt>auto_ptr</tt> in pre-rvalue reference days, which accepts both lvalue and
rvalue references. Although this decision was valid back then, C++0x
allows the user to express in a clear and non verbose manner when he wants
move semantics to be employed, be it implicitly (use case 1) or explicitly
(use case 2).
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Howard and Alisdair like the motivating use cases
and the proposed resolution.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In both 20.9.10.2 [util.smartptr.shared] paragraph 1 and 
20.9.10.2.1 [util.smartptr.shared.const] change:
</p>

<blockquote><pre>template &lt;class Y&gt; <del>explicit</del> shared_ptr(auto_ptr&lt;Y&gt; &amp;&amp;r);
template &lt;class Y, class D&gt; <del>explicit</del> shared_ptr(unique_ptr&lt;Y, D&gt; &amp;&amp;r);
</pre></blockquote>






<hr>
<h3><a name="929"></a>929. Thread constructor</h3>
<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 323</b></p>

<p>
The <tt>thread</tt> constructor for starting a new thread with a function and
arguments is overly constrained by the signature requiring rvalue
references for <tt>func</tt> and <tt>args</tt> and the <tt>CopyConstructible</tt> requirements
for the elements of <tt>args</tt>. The use of an rvalue reference for the
function restricts the potential use of a plain function name, since
the type of the bound parameter will be deduced to be a function
reference and decay to pointer-to-function will not happen. This
therefore complicates the implementation in order to handle a simple
case. Furthermore, the use of rvalue references for args prevents the
array to pointer decay. Since arrays are not <tt>CopyConstructible</tt> or even
<tt>MoveConstructible</tt>, this essentially prevents the passing of arrays as
parameters. In particular it prevents the passing of string literals.
Consequently a simple case such as
</p>

<blockquote><pre>void f(const char*);
std::thread t(f,"hello");
</pre></blockquote>

<p>
is ill-formed since the type of the string literal is <tt>const char[6]</tt>.
</p>

<p>
By changing the signature to take all parameters by value we can
eliminate the <tt>CopyConstructible</tt> requirement and permit the use of
arrays, as the parameter passing semantics will cause the necessary
array-to-pointer decay. They will also cause the function name to
decay to a pointer to function and allow the implementation to handle
functions and function objects identically.
</p>

<p>
The new signature of the <tt>thread</tt> constructor for a function and
arguments is thus:
</p>

<blockquote><pre>template&lt;typename F,typename... Args&gt;
thread(F,Args... args);
</pre></blockquote>

<p>
Since the parameter pack <tt>Args</tt> can be empty, the single-parameter
constructor that takes just a function by value is now redundant.
</p>

<p><i>[
Howard adds:
]</i></p>


<blockquote>
<p>
I agree with everything Anthony says in this issue.  However I believe we
can optimize in such a way as to get the pass-by-value behavior with the
pass-by-rvalue-ref performance.  The performance difference is that the latter
removes a <tt>move</tt> when passing in an lvalue.
</p>

<p>
This circumstance is very analogous to <tt>make_pair</tt> (20.3.5 [pairs])
where we started with passing by const reference, changed to pass by value to
get pointer decay, and then changed to pass by rvalue reference, but modified with
<tt>decay&lt;T&gt;</tt> to retain the pass-by-value behavior.  If we were to
apply the same solution here it would look like:
</p>

<blockquote><pre><del>template &lt;class F&gt; explicit thread(F f);</del>
template &lt;class F, class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.8.2 [func.require]) shall be a valid expression for
some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
</p>
<p>
-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
<ins>Constructs
the following objects in memory which is accessible to a new thread of execution
as if:</ins>
</p>
<blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
<ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
</pre></blockquote>
<p>
<ins>The new thread of
execution executes <tt><i>INVOKE</i>(g, wi...)</tt> where the <tt>wi...</tt> refers
to the elements stored in the <tt>tuple w</tt>.</ins>
Any return value from <tt>g</tt> is ignored.
<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
<ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
catchable in the calling thread.</ins>
</p>
</blockquote>
</blockquote>

<p>
Text referring to when <tt>terminate()</tt> is called was contributed by Ganesh.
</p>

</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution,
but would like the final sentence to be reworded
since "catchable" is not a term of art (and is used nowhere else).
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
This is linked to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
</p>
<p>
Howard to open a separate issue to remove (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>).
</p>
<p>
In Frankfurt there is no consensus for removing the variadic constructor.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
We want to move forward with this issue.  If we later take it out via <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1176">1176</a>
then that's ok too.  Needs small group to improve wording.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<p>
Stefanus provided revised wording.  Moved to Review  Here is the original wording:
</p>
<blockquote>
<p>
Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
following signature:
</p>

<blockquote><pre><del>template&lt;class F&gt; explicit thread(F f);</del>
template&lt;class F, class ... Args&gt; <ins>explicit</ins> thread(F&amp;&amp; f, Args&amp;&amp; ... args);
</pre></blockquote>

<p>
Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
the single constructor as above. Replace paragraph 4 - 6 with the
following:
</p>

<blockquote>
<p>
-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.8.2 [func.require]) shall be a valid expression for
some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
</p>
<p>
-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
<ins>Constructs
the following objects:</ins>
</p>
<blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
<ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
</pre></blockquote>
<p>
<ins>and executes <tt><i>INVOKE</i>(g, wi...)</tt> in a new thread of execution.
These objects shall be destroyed when the new thread of execution completes.</ins>
Any return value from <tt>g</tt> is ignored.
<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
<ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
catchable in the calling thread.</ins>
</p>
<p>
-6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
invocation of <del><tt>f</tt></del> <ins><tt>g</tt></ins>.
</p>
</blockquote>

</blockquote>
</blockquote>

<p><i>[
2010-01-19 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
following signature:
</p>

<blockquote><pre><del>template&lt;class F&gt; explicit thread(F f);</del>
template&lt;class F, class ... Args&gt; <ins>explicit</ins> thread(F&amp;&amp; f, Args&amp;&amp; ... args);
</pre></blockquote>

<p>
Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
the single constructor as above. Replace paragraph 4 - 6 with the
following:
</p>

<blockquote>
<p>
<ins>Given a function as follows:</ins>
</p>

<blockquote><pre><ins>
template&lt;typename T&gt; typename decay&lt;T&gt;::type decay_copy(T&amp;&amp; v)
    { return std::forward&lt;T&gt;(v); }
</ins></pre></blockquote>

<p>
-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall
<del>be <tt>CopyConstructible</tt> if an lvalue and otherwise</del> <ins>satisfy
the</ins> <tt>MoveConstructible</tt> <ins>requirements</ins>.
<del><tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.8.2 [func.require])
shall be a valid expression for some values <tt>w1, w2, ... , wN,</tt> where
<tt>N == sizeof...(Args)</tt>.</del>
<ins><tt><i>INVOKE</i>(decay_copy(std::forward&lt;F&gt;(f)), decay_copy(std::forward&lt;Args&gt;(args))...)</tt> (20.8.2 [func.require]) shall be a valid expression.</ins>
</p>

<p>
-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt> <del>and executes
<tt>INVOKE(f, t1, t2, ..., tN)</tt> in a new thread of execution, where
<tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt>. 
Any return
value from <tt>f</tt> is ignored. If <tt>f</tt> terminates with an
uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
<ins>The new thread of execution executes <tt>INVOKE(decay_copy(std::forward&lt;F&gt;(f)),
decay_copy(std::forward&lt;Args&gt;(args))...)</tt> with the calls to <tt>decay_copy()</tt> being evaluated in
the constructing thread. Any return value from this invocation is
ignored. [<i>Note:</i> this implies any exceptions not thrown from the
invocation of the copy of <tt>f</tt> will be thrown in the constructing thread,
not the new thread. � <i>end note</i>].
If the invocation of <tt><i>INVOKE</i>(decay_copy(std::forward&lt;F&gt;(f)),
decay_copy(std::forward&lt;Args&gt;(args))...)</tt> terminates with an uncaught
exception, <tt>std::terminate</tt> shall be called.
</ins></p>

<p>
-6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
invocation of <ins>the copy of</ins> <tt>f</tt>.
</p>
</blockquote>






<hr>
<h3><a name="931"></a>931. type trait <tt>extent&lt;T, I&gt;</tt></h3>
<p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2008-11-04 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The draft (N2798) says in 20.7.4.3 [meta.unary.prop] Table 44: 
</p>
<blockquote>
<table border="1">
<caption>Table 44 -- Type property queries</caption>
<tbody><tr><th>Template</th><th>Value</th></tr>
<tr>
<td>
<tt>template &lt;class T, unsigned I = 0&gt; struct extent;</tt>
</td>
<td>
If <tt>T</tt> is not an array type (8.3.4), or if it has rank less than
<tt>I</tt>, or if <tt>I</tt> is 0
and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
size of the <tt>I</tt>'th dimension of <tt>T</tt>
</td>
</tr>
</tbody></table>
</blockquote>

<p>
Firstly it isn't clear from the wording if <tt>I</tt> is 0-based or 1-based 
("the <tt>I</tt>'th dimension" sort of implies 1-based). From the following 
example it is clear that the intent is 0-based, in which case it 
should say "or if it has rank less than or equal to <tt>I</tt>".
</p>
<p>
Sanity check:
</p>
<p>
The example says <tt>assert((extent&lt;int[2], 1&gt;::value) == 0);</tt>
</p>
<p>
Here the rank is 1 and <tt>I</tt> is 1, but the desired result is 0.
</p>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Do not use "size" or "value", use "bound". Also, move the
cross-reference to 8.3.4 to just after "bound".
</p>
<p>
Recommend Tentatively Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In Table 44 of 20.7.4.3 [meta.unary.prop], third row, column "Value",
change the cell content:
</p>

<blockquote>
<table border="1">
<caption>Table 44 -- Type property queries</caption>
<tbody><tr><th>Template</th><th>Value</th></tr>
<tr>
<td>
<tt>template &lt;class T, unsigned I = 0&gt; struct extent;</tt>
</td>
<td>
If <tt>T</tt> is not an array type <del>(8.3.4)</del>, or if it has rank less than
<ins> or equal to</ins> <tt>I</tt>, or if <tt>I</tt> is 0
and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
<del>size</del> <ins>bound (8.3.4)</ins> of the <tt>I</tt>'th dimension of <tt>T</tt><ins>,
where indexing of <tt>I</tt> is zero-based.</ins>
</td>
</tr>
</tbody></table>
</blockquote>

<p><i>[
Wording supplied by Daniel.
]</i></p>







<hr>
<h3><a name="932"></a>932. <tt>unique_ptr(pointer p)</tt> for pointer deleter types</h3>
<p><b>Section:</b> 20.9.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-11-26 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses US 79</b></p>

<p>
20.9.9.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
not to be a pointer type.  I believe this restriction was accidently removed
when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
needs to be put back in.  Otherwise we have a run time failure that could
have been caught at compile time:
</p>

<blockquote><pre>{
unique_ptr&lt;int, void(*)(void*)&gt; p1(malloc(sizeof(int)));  <font color="#C80000">// should not compile</font>
}  <font color="#C80000">// p1.~unique_ptr() dereferences a null function pointer</font>
unique_ptr&lt;int, void(*)(void*)&gt; p2(malloc(sizeof(int)), free);  <font color="#C80000">// ok</font>
</pre></blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend Tentatively Ready.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved from Tentatively Ready to Open only because the wording needs to be
improved for enable_if type constraining, possibly following Robert's
formula.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
We need to consider whether some requirements in the Requires paragraphs
of [unique.ptr] should instead be Remarks.
</p>
<p>
Leave Open. Howard to provide wording, and possibly demonstrate how this
can be implemented using enable_if.
</p>
</blockquote>

<p><i>[
2009-07-27 Howard adds:
]</i></p>


<blockquote>
<p>
The two constructors to which this issue applies are not easily constrained
with <tt>enable_if</tt> as they are not templated:
</p>

<blockquote><pre>unique_ptr();
explicit unique_ptr(pointer p);
</pre></blockquote>

<p>
To "SFINAE" these constructors away would take heroic effort such as specializing
the entire <tt>unique_ptr</tt> class template on pointer deleter types.  There
is insufficient motivation for such heroics.  Here is the expected and
reasonable implementation for these constructors:
</p>

<blockquote><pre>unique_ptr()
    : ptr_(pointer())
    {
        static_assert(!is_pointer&lt;deleter_type&gt;::value,
            "unique_ptr constructed with null function pointer deleter");
    }
explicit unique_ptr(pointer p)
    : ptr_(p)
    {
        static_assert(!is_pointer&lt;deleter_type&gt;::value,
            "unique_ptr constructed with null function pointer deleter");
    }
</pre></blockquote>

<p>
I.e. just use <tt>static_assert</tt> to verify that the constructor is not
instantiated with a function pointer for a deleter.  The compiler will automatically
take care of issuing a diagnostic if the deleter is a reference type (uninitialized
reference error).
</p>

<p>
In keeping with our discussions in Frankfurt, I'm moving this requirement on
the implementation from the Requires paragraph to a Remarks paragraph.
</p>

</blockquote>

<p><i>[
2009-08-17 Daniel adds:
]</i></p>


<blockquote>
<p>
It is insufficient to require a diagnostic. This doesn't imply an
ill-formed program
as of 1.3.6 [defns.diagnostic] (a typical alternative would be a compiler
warning), but
exactly that seems to be the intend. I suggest to use the following
remark instead:
</p>

<blockquote>
<i>Remarks:</i> The program shall be ill-formed if this constructor is
instantiated when <tt>D</tt> is a pointer type or reference type.
</blockquote>

<p>
Via the general standard rules of 1.4 [intro.compliance] the "diagnostic
required" is implied.
</p>

</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>

<p><i>[
2010-03-14 Howard adds:
]</i></p>


<blockquote>
We moved
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
to the formal motions page in Pittsburgh which should obsolete this issue.  I've
moved this issue to NAD Editorial, solved by N3073.
</blockquote>



<p><b>Rationale:</b></p>
<p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the description of the default constructor in 20.9.9.2.1 [unique.ptr.single.ctor]:
</p>

<blockquote><pre>unique_ptr();
</pre>
<blockquote>
<p>
-1- <i>Requires:</i> <tt>D</tt> shall be default constructible, and that construction
shall not throw an exception. <del><tt>D</tt> shall 
not be a reference type or pointer type (diagnostic required).</del>
</p>
<p>...</p>
<p><ins>
<i>Remarks:</i> The program shall be ill-formed if this constructor is
instantiated when <tt>D</tt> is a pointer type or reference type.

</ins></p>
</blockquote>
</blockquote>

<p>
Add  after 20.9.9.2.1 [unique.ptr.single.ctor]/8:
</p>

<blockquote><pre>unique_ptr(pointer p);
</pre>
<blockquote>
<p>...</p>
<p><ins>
<i>Remarks:</i> The program shall be ill-formed if this constructor is
instantiated when <tt>D</tt> is a pointer type or reference type.

</ins></p>
</blockquote>
</blockquote>





<hr>
<h3><a name="934"></a>934. <tt>duration</tt> is missing <tt>operator%</tt></h3>
<p><b>Section:</b> 20.11.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Terry Golubiewski <b>Opened:</b> 2008-11-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses US 81</b></p>

<p>
<tt>duration</tt> is missing <tt>operator%</tt>.  This operator is convenient
for computing where in a time frame a given <tt>duration</tt> lies.  A
motivating example is converting a <tt>duration</tt> into a "broken-down"
time duration such as hours::minutes::seconds:
</p>

<blockquote><pre>class ClockTime
{
    typedef std::chrono::hours hours;
    typedef std::chrono::minutes minutes;
    typedef std::chrono::seconds seconds;
public:
    hours hours_;
    minutes minutes_;
    seconds seconds_;

    template &lt;class Rep, class Period&gt;
      explicit ClockTime(const std::chrono::duration&lt;Rep, Period&gt;&amp; d)
        : hours_  (std::chrono::duration_cast&lt;hours&gt;  (d)),
          minutes_(std::chrono::duration_cast&lt;minutes&gt;(d % hours(1))),
          seconds_(std::chrono::duration_cast&lt;seconds&gt;(d % minutes(1)))
          {}
};
</pre></blockquote>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree except that there is a typo in the proposed resolution. The member
operators should be operator%=.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved from Tentatively Ready to Open only because the wording needs to be
improved for enable_if type constraining, possibly following Robert's
formula.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
<p>
Howard to open a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>) to handle the removal of member
functions from overload sets, provide wording, and possibly demonstrate
how this can be implemented using enable_if (see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a>).
</p>
<p>
Move to Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add to the synopsis in 20.11 [time]:
</p>

<blockquote><pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
  typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
  operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre></blockquote>

<p>
Add to the synopsis of <tt>duration</tt> in 20.11.3 [time.duration]:
</p>

<blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
class duration {
public:
  ...
  <ins>duration&amp; operator%=(const rep&amp; rhs);</ins>
  <ins>duration&amp; operator%=(const duration&amp; d);</ins>
  ...
};
</pre></blockquote>

<p>
Add to 20.11.3.3 [time.duration.arithmetic]:
</p>

<blockquote>
<pre>duration&amp; operator%=(const rep&amp; rhs);
</pre>
<blockquote>
<p>
<i>Effects:</i> <tt>rep_ %= rhs</tt>.
</p>
<p>
<i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>

<pre>duration&amp; operator%=(const duration&amp; d);
</pre>
<blockquote>
<p>
<i>Effects:</i> <tt>rep_ %= d.count()</tt>.
</p>
<p>
<i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>

<p>
Add to 20.11.3.5 [time.duration.nonmember]:
</p>

<blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
<i>Requires:</i> <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
<tt>Rep2</tt> shall not be an instantiation of <tt>duration</tt>. Diagnostic required.
</p>
<p>
<i>Returns:</i> <tt>duration&lt;CR, Period&gt;(d) %= s</tt>.
</p>
</blockquote>

<pre>template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
  typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
  operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<i>Returns:</i> <tt>common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type(lhs) %= rhs</tt>.
</p>
</blockquote>

</blockquote>






<hr>
<h3><a name="938"></a>938. <tt>default_delete&lt;T[]&gt;::operator()</tt> should only accept <tt>T*</tt></h3>
<p><b>Section:</b> 20.9.9.1.3 [unique.ptr.dltr.dflt1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider:
</p>

<blockquote><pre>derived* p = new derived[3];
std::default_delete&lt;base[]&gt; d;
d(p);  <font color="#C80000">// should fail</font>
</pre></blockquote>

<p>
Currently the marked line is a run time failure.  We can make it a compile
time failure by "poisoning" <tt>op(U*)</tt>.
</p>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend Review.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Add to 20.9.9.1.3 [unique.ptr.dltr.dflt1]:
</p>

<blockquote><pre>namespace std {
  template &lt;class T&gt; struct default_delete&lt;T[]&gt; {
    void operator()(T*) const;
  <ins>template &lt;class U&gt; void operator()(U*) const = delete;</ins>
};
}
</pre></blockquote>





<hr>
<h3><a name="939"></a>939. Problem with <tt>std::identity</tt> and reference-to-temporaries</h3>
<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-12-11 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::identity</tt> takes an argument of type <tt>T const &amp;</tt>
and returns a result of <tt>T const &amp;</tt>.
</p>
<p>
Unfortunately, this signature will accept a value of type other than <tt>T</tt> that
is convertible-to-<tt>T</tt>, and then return a reference to the dead temporary.  The
constraint in the concepts version simply protects against returning
reference-to-<tt>void</tt>.
</p>
<p>
Solutions:
</p>
<blockquote>
<p>
i/  Return-by-value, potentially slicing bases and rejecting non-copyable
types
</p>
<p>
ii/ Provide an additional overload:
</p>
<blockquote><pre>template&lt; typename T &gt;
template operator( U &amp; ) = delete;
</pre></blockquote>
<p>
This seems closer on intent, but moves beyond the original motivation for
the operator, which is compatibility with existing (non-standard)
implementations.
</p>
<p>
iii/ Remove the <tt>operator()</tt> overload.  This restores the original definition
of the <tt>identity</tt>, although now effectively a type_trait rather than part of
the perfect forwarding protocol.
</p>
<p>
iv/ Remove <tt>std::identity</tt> completely; its original reason to exist is
replaced with the <tt>IdentityOf</tt> concept.
</p>
</blockquote>
<p>
My own preference is somewhere between (ii) and (iii) - although I stumbled
over the issue with a specific application hoping for resolution (i)!
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We dislike options i and iii, and option ii seems like overkill.
If we remove it (option iv), implementers can still provide it under a
different name.
</p>
<p>
Move to Open pending wording (from Alisdair) for option iv.
</p>
</blockquote>

<p><i>[
2009-05-23 Alisdair provided wording for option iv.
]</i></p>


<p><i>[
2009-07-20 Alisdair adds:
]</i></p>


<blockquote>
<p>
I'm not sure why this issue was not discussed at Frankfurt (or I missed
the discussion) but the rationale is now fundamentally flawed.  With the
removal of concepts, <tt>std::identity</tt> again becomes an important library
type so we cannot simply remove it.
</p>
<p>
At that point, we need to pick one of the other suggested resolutions,
but have no guidance at the moment.
</p>
</blockquote>

<p><i>[
2009-07-20 Howard adds:
]</i></p>


<blockquote>
<p>
I believe the rationale for not addressing this issue in Frankfurt was that it did
not address a national body comment.
</p>
<p>
I also believe that removal of <tt>identity</tt> is still a practical option as
my latest reformulation of <tt>forward</tt>, which is due to comments suggested
at Summit, no longer uses <tt>identity</tt>. :-)
</p>

<blockquote><pre>template &lt;class T, class U,
    class = typename enable_if
            &lt;
                !is_lvalue_reference&lt;T&gt;::value || 
                 is_lvalue_reference&lt;T&gt;::value &amp;&amp;
                 is_lvalue_reference&lt;U&gt;::value
            &gt;::type,
    class = typename enable_if
            &lt;
                is_same&lt;typename remove_all&lt;T&gt;::type,
                        typename remove_all&lt;U&gt;::type&gt;::value
            &gt;::type&gt;
inline
T&amp;&amp;
forward(U&amp;&amp; t)
{
    return static_cast&lt;T&amp;&amp;&gt;(t);

}
</pre>

<p><i>[
The above code assumes acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a> for the definition of
<tt>remove_all</tt>.  This is just to make the syntax a little more palatable.
Without this trait the above is still very implementable.
]</i></p>


</blockquote>

<p>
Paper with rationale is on the way ... <i>really</i>, I promise this time! ;-)
</p>
</blockquote>

<p><i>[
2009-07-30 Daniel adds:  See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a> for an alternative resolution.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready. Howard will update proposed wording to reflect current draft.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Strike from 20.3 [utility]:
</p>

<blockquote><pre><del>template &lt;class T&gt; struct identity;</del>
</pre></blockquote>

<p>
Remove from 20.3.3 [forward]:
</p>

<blockquote>
<pre><del>template &lt;class T&gt; struct identity {
  typedef T type;

  const T&amp; operator()(const T&amp; x) const;
};</del>

<del>const T&amp; operator()(const T&amp; x) const;</del>
</pre>
<blockquote>
<del>-2-  <i>Returns:</i> <tt>x</tt></del>
</blockquote>
</blockquote>






<hr>
<h3><a name="943"></a>943. <tt>ssize_t</tt> undefined</h3>
<p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is a row in "Table 122 - Atomics for standard typedef types"
in 29.5.1 [atomics.types.integral] with <tt>atomic_ssize_t</tt>
and <tt>ssize_t</tt>. Unless, I'm missing something <tt>ssize_t</tt>
is not defined by the standard.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Move to review. Proposed resolution: Remove the typedef. Note: ssize_t
is a POSIX type.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Remove the row containing <tt>ssize_t</tt> from Table 119
"Atomics for standard typedef types" in 29.5.2 [atomics.types.address].
</p>





<hr>
<h3><a name="947"></a>947. duration arithmetic: contradictory requirements</h3>
<p><b>Section:</b> 20.11.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 20.11.3.5 [time.duration.nonmember], paragraph 8 says that calling
<tt>dur / rep</tt>
when <tt>rep</tt> is an instantiation of <tt>duration</tt> requires a diagnostic.
That's followed by an <tt>operator/</tt> that takes two durations.
So <tt>dur1 / dur2</tt> is legal under the second version,
but requires a diagnostic under the first.
</p>

<p><i>[
Howard adds:
]</i></p>


<blockquote>
Please see the thread starting with c++std-lib-22980 for more information.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Move to Open, pending proposed wording (and preferably an implementation).
</blockquote>

<p><i>[
2009-07-27 Howard adds:
]</i></p>


<blockquote>
<p>
I've addressed this issue under the proposed wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a> which
cleans up several places under 20.11.3 [time.duration] which used the
phrase "diagnostic required".
</p>
<p>
For clarity's sake, here is an example implementation of the constrained <tt>operator/</tt>:
</p>

<blockquote><pre>template &lt;class _Duration, class _Rep, bool = __is_duration&lt;_Rep&gt;::value&gt;
struct __duration_divide_result
{
};

template &lt;class _Duration, class _Rep2,
    bool = is_convertible&lt;_Rep2,
                          typename common_type&lt;typename _Duration::rep, _Rep2&gt;::type&gt;::value&gt;
struct __duration_divide_imp
{
};

template &lt;class _Rep1, class _Period, class _Rep2&gt;
struct __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, true&gt;
{
    typedef duration&lt;typename common_type&lt;_Rep1, _Rep2&gt;::type, _Period&gt; type;
};

template &lt;class _Rep1, class _Period, class _Rep2&gt;
struct __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, false&gt;
    : __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;
{
};

template &lt;class _Rep1, class _Period, class _Rep2&gt;
inline
typename __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;::type
operator/(const duration&lt;_Rep1, _Period&gt;&amp; __d, const _Rep2&amp; __s)
{
    typedef typename common_type&lt;_Rep1, _Rep2&gt;::type _Cr;
    duration&lt;_Cr, _Period&gt; __r = __d;
    __r /= static_cast&lt;_Cr&gt;(__s);
    return __r;
}
</pre></blockquote>

<p>
<tt>__duration_divide_result</tt> is basically a custom-built <tt>enable_if</tt>
that will contain <tt>type</tt> only if <tt>Rep2</tt> is not a <tt>duration</tt>
and if <tt>Rep2</tt> is implicitly convertible to
<tt>common_type&lt;typename Duration::rep, Rep2&gt;::type</tt>. <tt>__is_duration</tt>
is simply a private trait that answers <tt>false</tt>, but is specialized for
<tt>duration</tt> to answer <tt>true</tt>.
</p>

<p>
The constrained <tt>operator%</tt> works identically.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Mark <del>NAD Editorial</del><ins>Resolved</ins>, fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
</p>





<hr>
<h3><a name="948"></a>948. <tt>ratio</tt> arithmetic tweak</h3>
<p><b>Section:</b> 20.6.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
20.6.2 [ratio.arithmetic] lacks a paragraph from the proposal
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>:
</p>

<blockquote>
<p><b>ratio arithmetic [ratio.arithmetic]</b></p>

<p>
... If the implementation is unable to form the indicated <tt>ratio</tt> due to
overflow, a diagnostic shall be issued.
</p>
</blockquote>

<p>
The lack of a diagnostic on compile-time overflow is a significant lack of
functionality.  This paragraph could be put back into the WP simply editorially.
However in forming this issue I realized that we can do better than that.  This
paragraph should also allow alternative formulations which go to extra lengths
to avoid overflow when possible.  I.e. we should not mandate overflow when the
implementation can avoid it.
</p>

<p>
For example:
</p>

<blockquote>
<pre>template &lt;class R1, class R2&gt; struct ratio_multiply {
  typedef <i>see below</i>} type; 
</pre>

<blockquote>
The nested typedef type shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt> where
<tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the
value <tt>R1::den * R2::den</tt>.
</blockquote>

</blockquote>

<p>
Consider the case where <tt>intmax_t</tt> is a 64 bit 2's complement signed integer,
and we have:
</p>

<blockquote><pre>typedef std::ratio&lt;0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFF0&gt; R1;
typedef std::ratio&lt;8, 7&gt; R2;
typedef std::ratio_multiply&lt;R1, R2&gt;::type RT;
</pre></blockquote>

<p>
According to the present formulation the implementaiton will multiply
<tt>0x7FFFFFFFFFFFFFFF * 8</tt> which will result in an overflow and subsequently
require a diagnostic.
</p>

<p>
However if the implementation is first allowed to divde <tt>0x7FFFFFFFFFFFFFFF</tt>
by <tt>7</tt> obtaining <tt>0x1249249249249249 / 1</tt> and divide
<tt>8</tt> by <tt>0x7FFFFFFFFFFFFFF0</tt> obtaining <tt>1 / 0x0FFFFFFFFFFFFFFE</tt>,
then the exact result can then be computed without overflow:
</p>

<blockquote><pre>[0x7FFFFFFFFFFFFFFF/0x7FFFFFFFFFFFFFF0] * [8/7] = [0x1249249249249249/0x0FFFFFFFFFFFFFFE]
</pre></blockquote>

<p>
Example implmentation which accomplishes this:
</p>

<blockquote><pre>template &lt;class R1, class R2&gt;
struct ratio_multiply
{
private:
    typedef ratio&lt;R1::num, R2::den&gt; _R3;
    typedef ratio&lt;R2::num, R1::den&gt; _R4;
public:
    typedef ratio&lt;__ll_mul&lt;_R3::num, _R4::num&gt;::value,
                  __ll_mul&lt;_R3::den, _R4::den&gt;::value&gt; type;
};
</pre></blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend Tentatively Ready.
</blockquote>




<p><b>Proposed resolution:</b></p>
<p>
Add a paragraph prior to p1 in 20.6.2 [ratio.arithmetic]:
</p>

<blockquote>
Implementations may use other algorithms to compute the indicated ratios to avoid overflow. 
If overflow occurs, a diagnostic shall be issued.
</blockquote>





<hr>
<h3><a name="949"></a>949. <tt>owner_less</tt></h3>
<p><b>Section:</b> 20.9.10.3.7 [util.smartptr.ownerless] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2008-12-30 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.9.10.3.7 [util.smartptr.ownerless] (class template <tt>owner_less</tt>) says that 
<tt>operator()(x,y)</tt> shall return <tt>x.before(y)</tt>.
</p>
<p>
However, <tt>shared_ptr</tt> and <tt>weak_ptr</tt> have an <tt>owner_before()</tt> but not a
<tt>before()</tt>, and there's no base class to provide a missing <tt>before()</tt>.
</p>
<p>
Being that the class is named  <tt>owner_less</tt> , I'm guessing that
"<tt>before()</tt>" should be "<tt>owner_before()</tt>", right?
</p>

<p><i>[
Herve adds:
]</i></p>


<blockquote>
Agreed with the typo, it should be "shall return <tt>x.owner_before(y)</tt>".
</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.10.3.7 [util.smartptr.ownerless] p2:
</p>

<blockquote>
-2- <tt>operator()(x,y)</tt> shall return
<tt>x.<ins>owner_</ins>before(y)</tt>. [<i>Note:</i> ...
</blockquote>





<hr>
<h3><a name="950"></a>950. unique_ptr converting ctor shouldn't accept array form</h3>
<p><b>Section:</b> 20.9.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>unique_ptr</tt>'s of array type should not convert to
<tt>unique_ptr</tt>'s which do not have an array type.
</p>

<blockquote><pre>struct Deleter
{
   void operator()(void*) {}
};

int main()
{
   unique_ptr&lt;int[], Deleter&gt; s;
   unique_ptr&lt;int, Deleter&gt; s2(std::move(s));  <font color="#C80000">// should not compile</font>
}
</pre></blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Walter: Does the "diagnostic required" apply to both arms of the "and"?
</p>
<p>
Tom Plum: suggest to break into several sentences
</p>
<p>
Walter: suggest "comma" before the "and" in both places
</p>
<p>
Recommend Review.
</p>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
The post-Summit comments have been applied to the proposed resolution.
We now agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved from Tentatively Ready to Open only because the wording needs to be
improved for enable_if type constraining, possibly following Robert's
formula.
</blockquote>

<p><i>[
2009-08-01 Howard updates wording and sets to Review.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
2010-02-27 Pete Opens:
]</i></p>


<blockquote>
<p>
The proposed replacement text doesn't make sense.
</p>

<blockquote>
If <tt>D</tt> is a reference type, then <tt>E</tt> shall be the same type as
<tt>D</tt>, else this constructor shall not participate in overload resolution.
</blockquote>

<p>
This imposes two requirements. 1. If <tt>D</tt> is a reference type, <tt>E</tt>
has to be <tt>D</tt>. 2. If <tt>D</tt> is not a reference type, the constructor
shall not participate in overload resolution. If the latter apples, the language
in the preceding paragraph that this constructor shall not throw an exception if
<tt>D</tt> is not a reference type is superfluous. I suspect that's not the
intention, but I can't parse this text any other way.
</p>

<blockquote>
<tt>U</tt> shall not be an array type, else this constructor shall not
participate in overload resolution.
</blockquote>

<p>
I don't know what this means.
</p>
</blockquote>

<p><i>[
2010-02-27 Peter adds:
]</i></p>


<blockquote>
<p>
I think that the intent is (proposed text):
</p>

<blockquote>
<p>
<i>Remarks:</i> this constructor shall only participate in overload resolution
if:
</p>

<ul>
<li>
<tt>unique_ptr&lt;U, E&gt;::pointer</tt> is implicitly convertible to
<tt>pointer</tt>,
</li>

<li>
<tt>U</tt> is not an array type, and
</li>

<li>
if <tt>D</tt> is a reference type, <tt>E</tt> is the same type as <tt>D</tt>.
</li>
</ul>

</blockquote>

</blockquote>

<p><i>[
2010-02-28 Howard adds:
]</i></p>


<blockquote>
<p>
I like Peter's proposal.  Here is a tweak of it made after looking at my
implementation.  I believe this fixes a further defect not addressed by the
current proposed wording:
</p>

<blockquote>
<p>
<i>Remarks:</i> this constructor shall only participate in overload resolution
if:
</p>

<ul>
<li>
<tt>unique_ptr&lt;U, E&gt;::pointer</tt> is implicitly convertible to
<tt>pointer</tt>, and
</li>

<li>
<tt>U</tt> is not an array type, and
</li>

<li>
if <tt>D</tt> is a reference type, <tt>E</tt> is the same type as <tt>D</tt>,
else <tt>E</tt> shall be implicitly convertible to <tt>D</tt>.
</li>
</ul>

</blockquote>

</blockquote>

<p><i>[
2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]:
</p>

<blockquote>
<pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
-20- <i>Requires:</i> If <tt>D</tt> is not a reference type,
construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
shall be well formed and shall not throw an exception. <del>If <tt>D</tt> is
a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
(diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
implicitly convertible to <tt>pointer</tt>. [<i>Note:</i> These requirements
imply that <tt>T</tt> and <tt>U</tt> are complete types. � <i>end note</i>]</del>
</p>

<p><ins>
<i>Remarks:</i> If <tt>D</tt> is
a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>, else this
constructor shall not participate in overload resolution. <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
implicitly convertible to <tt>pointer</tt>, else this
constructor shall not participate in overload resolution. <tt>U</tt> shall not be
an array type, else this
constructor shall not participate in overload resolution. [<i>Note:</i> These requirements
imply that <tt>T</tt> and <tt>U</tt> are complete types. � <i>end note</i>]
</ins></p>

</blockquote>
</blockquote>

<p>
Change 20.9.9.2.3 [unique.ptr.single.asgn]:
</p>

<blockquote>
<pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
-6- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
<tt>D</tt> shall not throw an exception. <del><tt>unique_ptr&lt;U,
E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
are complete types. � <i>end note</i>]</del>
</p>

<p><ins>
<i>Remarks:</i> <tt>unique_ptr&lt;U,
E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>, else this
operator shall not participate in overload resolution.
<tt>U</tt> shall not be an array type, else this
operator shall not participate in overload resolution.
[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
are complete types. � <i>end note</i>]
</ins></p>

</blockquote>
</blockquote>






<hr>
<h3><a name="951"></a>951. Various threading bugs #1</h3>
<p><b>Section:</b> 20.11.2.1 [time.traits.is_fp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>.
</p>

<p>
20.11.2.1 [time.traits.is_fp] says that the type <tt>Rep</tt> "is
assumed to be ... a class emulating an integral type." What are the
requirements for such a type?
</p>
<p><i>[
2009-05-10 Howard adds:
]</i></p>


<blockquote>
<tt>IntegralLike</tt>.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#953">953</a>,
we recommend this issue be addressed in the context of providing concepts for the entire <tt>thread</tt> header.
</p>
<p>
We look forward to proposed wording.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-08-01 Howard adds:
]</i></p>


<blockquote>
<p>
I have surveyed all clauses of 20.11.2.2 [time.traits.duration_values],
20.11.2.3 [time.traits.specializations] and 20.11.3 [time.duration].
I can not find any clause which involves the use of a <tt>duration::rep</tt> type
where the requirements on the <tt>rep</tt> type are not clearly spelled out.
These requirements were carefully crafted to allow any arithmetic type, or
any user-defined type emulating an arithmetic type.
</p>

<p>
Indeed, <tt>treat_as_floating_point</tt>
becomes completely superfluous if <tt>duration::rep</tt> can never be a class type.
</p>

<p>
There will be some <tt>Rep</tt> types which will not meet the requirements of
<em>every</em> <tt>duration</tt> operation.  This is no different than the fact
that <tt>vector&lt;T&gt;</tt> can easily be used for types <tt>T</tt> which are
not <tt>DefaultConstructible</tt>, even though some members of <tt>vector&lt;T&gt;</tt>
require <tt>T</tt> to be <tt>DefaultConstructible</tt>.  This is why the requirements
on <tt>Rep</tt> are specified for each operation individually.
</p>

<p>
In 20.11.2.1 [time.traits.is_fp] p1:
</p>

<blockquote><pre>template &lt;class Rep&gt; struct treat_as_floating_point 
  : is_floating_point&lt;Rep&gt; { };
</pre>

<blockquote>
The <tt>duration</tt> template uses the <tt>treat_as_floating_point</tt> trait to help
determine if a <tt>duration</tt> object can be converted to another <tt>duration</tt>
with a different tick period. If <tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is
<tt>true</tt>, then <tt>Rep</tt> is a floating-point type and implicit conversions are
allowed among <tt>duration</tt>s. Otherwise, the implicit convertibility depends
on the tick periods of the <tt>duration</tt>s. If <tt>Rep</tt> is <u>a class type which
emulates a floating-point type</u>, the author of <tt>Rep</tt> can specialize
<tt>treat_as_floating_point</tt> so that <tt>duration</tt> will treat this <tt>Rep</tt> as if it
were a floating-point type. Otherwise <tt>Rep</tt> is assumed to be an integral
type or <u>a class emulating an integral type</u>.
</blockquote>
</blockquote>

<p>
The phrases "a class type which emulates a floating-point type" and
"a class emulating an integral type" are clarifying phrases which refer to
the summation of all the requirements on the <tt>Rep</tt> type specified in
detail elsewhere (and <em>should not</em> be repeated here).
</p>

<p>
This specification has been implemented, now multiple times, and the experience
has been favorable.  The current specification clearly specifies the requirements
at each point of use (though I'd be happy to fix any place I may have missed,
but none has been pointed out).
</p>

<p>
I am amenable to improved wording of this paragraph (and any others), but do not have any
suggestions for improved wording at this time.  I am <em>strongly</em> opposed to
changes which would significantly alter the semantics of the
specification under 20.11 [time] without firmly grounded and
documented rationale, example implementation, testing, and user
experience which relates a positive experience.
</p>

<p>
I recommend NAD unless someone wants to produce some clarifying wording.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Stefanus to provide wording to turn this into a note.
</blockquote>

<p><i>[
2010-02-11 Stefanus provided wording.
]</i></p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.11.2.1 [time.traits.is_fp]/1:
</p>

<blockquote>
1 The <tt>duration</tt> template uses the <tt>treat_as_floating_point</tt> trait
to help determine if a <tt>duration</tt> object can be converted to another
<tt>duration</tt> with a different tick period. If
<tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is <tt>true</tt>, then
<del><tt>Rep</tt> is a floating-point type and</del> implicit conversions are allowed among
<tt>duration</tt>s. Otherwise, the implicit convertibility depends on the tick
periods of the <tt>duration</tt>s. <del>If <tt>Rep</tt> is a class type which
emulates a floating-point type, the author of <tt>Rep</tt> can specialize
<tt>treat_as_floating_point</tt> so that duration will treat this <tt>Rep</tt>
as if it were a floating-point type. Otherwise <tt>Rep</tt> is assumed to be an
integral type or a class emulating an integral type.</del>
<ins>[<i>Note:</i> The intention of this trait is to indicate whether a given
class behaves like a floating point type, and thus allows division of one value
by another with acceptable loss of precision. If
<tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is <tt>false</tt>,
<tt>Rep</tt> will be treated as if it behaved like an integral type for the
purpose of these conversions. � <i>end note</i>]</ins>
</blockquote>






<hr>
<h3><a name="953"></a>953. Various threading bugs #3</h3>
<p><b>Section:</b> 20.11.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.
</p>

<p>
20.11.1 [time.clock.req] says that a clock's <tt>rep</tt> member is "an
arithmetic type or a class emulating an arithmetic type." What are the
requirements for such a type?
</p>

<p><i>[
2009-05-10 Howard adds:
]</i></p>


<blockquote>
This wording was aimed directly at the <tt>ArithmeticLike</tt> concept.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We recommend this issue be addressed in the context of providing concepts
for the entire <tt>thread</tt> header.
</p>
<p>
May resolve for now by specifying arithmetic types,
and in future change to <tt>ArithmeticLike</tt>.
However, Alisdair believes this is not feasible.
</p>
<p>
Bill disagrees.
</p>
<p>
We look forward to proposed wording.  Move to Open.
</p>
</blockquote>

<p><i>[
2009-08-01 Howard adds:
]</i></p>


<blockquote>
See commented dated 2009-08-01 in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Stefanus to provide wording to turn this into a note.
</blockquote>

<p><i>[
2010-02-11 Stephanus provided wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a> which addresses
this issue as well.
]</i></p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote>
Move to <del>NAD Editorial</del><ins>Resolved</ins>, resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#951">951</a>.
</blockquote>




<p><b>Proposed resolution:</b></p>
<p>
</p>





<hr>
<h3><a name="954"></a>954. Various threading bugs #4</h3>
<p><b>Section:</b> 20.11.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 55 -- Clock Requirements (in 20.11.1 [time.clock.req])
</p>

<ol type="a">
<li>
the requirements for <tt>C1::time_point</tt> require <tt>C1</tt> and <tt>C2</tt>
to "refer to the same epoch", but "epoch" is not defined.
</li>
<li>
"Different clocks may share a <tt>time_point</tt> definition if it is
valid to compare their <tt>time_point</tt>s by comparing their
respective <tt>duration</tt>s." What does "valid" mean here? And, since
<tt>C1::rep</tt> is "**THE** representation type of the native
<tt>duration</tt> and <tt>time_point</tt>" (emphasis added), there
doesn't seem to be much room for some other representation.
</li>
<li>
<tt>C1::is_monotonic</tt> has type "<tt>const bool</tt>". The
"<tt>const</tt>" should be removed.
</li>
<li>
<tt>C1::period</tt> has type <tt>ratio</tt>. <tt>ratio</tt> isn't a type, 
it's a template. What is the required type?
</li>
</ol>

<p><i>[
2009-05-10 Howard adds:
]</i></p>


<ol type="a">
<li>
<p>
"epoch" is purposefully not defined beyond the common English
<a href="http://www.dictionary.net/epoch">definition</a>.  The C standard
also chose not to define epoch, though POSIX did.  I believe it is a strength
of the C standard that epoch is not defined.  When it is known that two <tt>time_point</tt>s
refer to the same epoch, then a definition of the epoch is not needed to compare
the two <tt>time_point</tt>s, or subtract them.
</p>
<p>
A <tt>time_point</tt> and a <tt>Clock</tt> implicitly refer to an (unspecified) epoch.
The <tt>time_point</tt> represents an offset (<tt>duration</tt>) from an epoch.
</p>
</li>
<li>
<p>
The sentence:
</p>
<blockquote>
Different clocks 
may share a <tt>time_point</tt>
definition if it is valid to 
compare their <tt>time_point</tt>s by 
comparing their respective 
<tt>duration</tt>s.
</blockquote>

<p>
is redundant and could be removed.  I believe the sentence which follows the above:
</p>

<blockquote>
<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
</blockquote>

<p>
is sufficient.  If two clocks share the same epoch, then by definition, comparing
their <tt>time_point</tt>s is valid.
</p>
</li>
<li>
<tt>is_monotonic</tt> is meant to never change (be <tt>const</tt>).  It is also
desired that this value be usable in compile-time computation and branching.
</li>
<li>
<p>
This should probably instead be worded:
</p>
<blockquote>
An instantiation of <tt>ratio</tt>.
</blockquote>
</li>
</ol>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Re (a): It is not clear to us whether "epoch" is a term of art.
</p>
<p>
Re (b), (c), and (d):  We agree with Howard's comments,
and would consider adding to (c) a <tt>static constexpr</tt> requirement.
</p>
<p>
Move to Open pending proposed wording.
</p>
</blockquote>

<p><i>[
2009-05-25 Daniel adds:
]</i></p>


<blockquote>
In regards to (d) I suggest to say "a specialization of ratio" instead of
"An instantiation of ratio". This seems to be the better matching standard
core language term for this kind of entity.
</blockquote>

<p><i>[
2009-05-25 Ganesh adds:
]</i></p>


<blockquote>
<p>
Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:
</p>

<p>
<a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM">http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM</a>
</p>
<p>
which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".
</p>
</blockquote>

<p><i>[
2009-08-01 Howard: Moved to Reivew as the wording requested in Batavia has been provided.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<ol type="a">
<li>
<p>
Change 20.11.1 [time.clock.req] p1:
</p>
<blockquote>
-1- A clock is a bundle consisting of a native <tt>duration</tt>, a native <tt>time_point</tt>, and a function <tt>now()</tt> to get the 
current <tt>time_point</tt>.  <ins>The origin of the clock's <tt>time_point</tt> is referred to as the clock's <i>epoch</i> as defined in 
section 6.3 of ISO/IEC 18026.</ins>
A clock shall meet the requirements in Table 45.
</blockquote>
</li>
<li>
<p>
Remove the sentence from the <tt>time_point</tt> row of the table "Clock Requirements":
</p>
<table border="1">
<caption>Clock requirements</caption>
<tbody><tr>
<td>
<tt>C1::time_point</tt>
</td>
<td>
<tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration&gt;</tt>
</td>
<td>
The native <tt>time_point</tt> type of the clock.
<del>Different clocks may share a <tt>time_point</tt> definition if it is valid to compare their <tt>time_point</tt>s by comparing their respective <tt>duration</tt>s.</del>
<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
</td>
</tr>
</tbody></table>
</li>
</ol>
<ol type="a" start="4">
<li>
<p>
Change the row starting with <tt>C1::period</tt> of the table "Clock Requirements":
</p>
<table border="1">
<caption>Clock requirements</caption>
<tbody><tr>
<td>
<tt>C1::period</tt>
</td>
<td>
<ins>a specialization of</ins> <tt>ratio</tt>
</td>
<td>
The tick period of the clock in seconds.
</td>
</tr>
</tbody></table>

</li>
</ol>





<hr>
<h3><a name="956"></a>956. Various threading bugs #6</h3>
<p><b>Section:</b> 20.11.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.11.1 [time.clock.req] uses the word "native" in several places,
but doesn't define it. What is a "native <tt>duration</tt>"?
</p>

<p><i>[
2009-05-10 Howard adds:
]</i></p>


<blockquote>
The standard uses "native" in several places without defining it (e.g.
2.14.3 [lex.ccon]).  It is meant to mean "that which is defined
by the facility", or something along those lines.  In this case it refers
to the nested <tt>time_point</tt> and <tt>duration</tt> types of the clock.
Better wording is welcome.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Move to Open pending proposed wording from Pete.
</blockquote>

<p><i>[
2009-10-23 Pete provides wording:
]</i></p>


<p><i>[
2009-11-18 Daniel adds:
]</i></p>


<blockquote>
<p>
I see that 30.4.1.3 [thread.timedmutex.requirements]/3 says:
</p>

<blockquote>
<i>Precondition:</i> If the tick <tt>period</tt> of <tt>rel_time</tt> is not
exactly convertible to the native tick <tt>period</tt>, the <tt>duration</tt>
shall be rounded up to the nearest native tick <tt>period</tt>.
</blockquote>

<p>
I would prefer to see that adapted as well. Following the same style as
the proposed resolution I come up with
</p>

<blockquote>
<i>Precondition:</i> If the tick <tt>period</tt> of <tt>rel_time</tt> is not
exactly convertible to the <del>native</del> tick <tt>period</tt> <ins>of the
execution environment</ins>, the <tt>duration</tt> shall be rounded up to the
nearest <del>native</del> tick <tt>period</tt> <ins>of the execution
environment</ins>.
</blockquote>

</blockquote>

<p><i>[
2010-03-28 Daniel synced wording with N3092
]</i></p>


<p><i>[
Post-Rapperswil, Howard provides wording:
]</i></p>


<blockquote>
Moved to Tentatively Ready with revised wording from Howard Hinnant after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Change 20.11.1 [time.clock.req]:
</p>

<blockquote>
<p>
1 A clock is a bundle consisting of a <del>native</del> <tt>duration</tt>, a
<del>native</del> <tt>time_point</tt>, and a function <tt>now()</tt> to get the
current <tt>time_point</tt>. The origin of the clock's <tt>time_point</tt> is
referred to as the clock's <i>epoch</i>. A clock shall meet the requirements in
Table 56.
</p>

<p>
2 ...
</p>

<table border="1">
<caption>Table 56 � Clock requirements</caption>
<tbody><tr><th>Expression</th> <th>Return type</th> <th>Operational semantics</th></tr>

<tr>
<td><tt>C1::rep</tt></td>
<td>An arithmetic type or a class emulating an arithmetic type</td>
<td>The representation type of <del>the native</del>
<tt><ins>C1::</ins>duration</tt><ins>.</ins> <del>and
<tt>time_point</tt>.</del></td>
</tr>

<tr>
<td><tt>C1::period</tt></td>
<td align="center">...</td>
<td align="center">...</td>
</tr>

<tr>
<td><tt>C1::duration</tt></td>
<td><tt>chrono::duration&lt;C1::rep, C1::period&gt;</tt></td>
<td>The <del>native</del> <tt>duration</tt> type of the clock.</td>
</tr>

<tr>
<td><tt>C1::time_point</tt></td>
<td><tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2,
C1::duration&gt;</tt></td>
<td>The <del>native</del> <tt>time_point</tt> type of the clock. <tt>C1</tt> and
<tt>C2</tt> shall refer to the same epoch.</td>
</tr>

<tr>
<td colspan="3" align="center">...</td>
</tr>

</tbody></table>
</blockquote>






<hr>
<h3><a name="957"></a>957. Various threading bugs #7</h3>
<p><b>Section:</b> 20.11.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.11.5.1 [time.clock.system]: <tt>to_time_t</tt> is overspecified. It
requires truncation, but should allow rounding. For example, suppose a
system has a clock that gives times in milliseconds, but <tt>time()</tt> rounds
those times to the nearest second. Then <tt>system_clock</tt> can't use any
resolution finer than one second, because if it did, truncating times
between half a second and a full second would produce the wrong <tt>time_t</tt>
value.
</p>

<p><i>[
Post Summit Anthony Williams provided proposed wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Move to Review pending input from Howard. and other stakeholders.
</blockquote>

<p><i>[
2009-05-23 Howard adds:
]</i></p>


<blockquote>
I am in favor of the wording provided by Anthony.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In 20.11.5.1 [time.clock.system] replace paragraphs 3 and 4 with:
</p>

<blockquote>
<pre>time_t to_time_t(const time_point&amp; t);
</pre>
<blockquote>
-3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
point in time as <tt>t</tt> when both values are <del>truncated</del>
<ins>restricted</ins> to the coarser of the precisions of
<tt>time_t</tt> and <tt>time_point</tt>. <ins> It is implementation
defined whether values are rounded or truncated to the required
precision.</ins>
</blockquote>

<pre>time_point from_time_t(time_t t);
</pre>
<blockquote>
-4- <i>Returns:</i> A <tt>time_point</tt> object that represents the
same point in time as <tt>t</tt> when both values are <del>truncated</del>
<ins>restricted</ins> to the
coarser of the precisions of <tt>time_t</tt> and <tt>time_point</tt>.
<ins>It is implementation defined whether values are
rounded or truncated to the required precision.</ins>
</blockquote>
</blockquote>





<hr>
<h3><a name="960"></a>960. Various threading bugs #10</h3>
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled
"Error conditions", but according to 17.5.1.4 [structure.specifications], "Error
conditions:" specifies "the error conditions for error codes reported by
the function." It's not clear what this should mean when there is no
function in sight.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Move to open.
</blockquote>

<p><i>[
Beman provided proposed wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready. Fix the proposed wording with "functions of type Mutex"
-&gt; "functions of Mutex type"
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 30.4.1 [thread.mutex.requirements] Mutex requirements,
paragraph 4 as indicated:
</p>

<blockquote>
<p>
-4- <del><i>Error conditions:</i></del>
<ins>The error conditions for error codes, if any, reported by member
functions of Mutex type shall be:</ins>
</p>
<ul>
<li>
<tt>not_enough_memory</tt> -- if there is not enough memory to construct
the mutex object.
</li>
<li>
<tt>resource_unavailable_try_again</tt> -- if any native handle type
manipulated is not available.
</li>
<li>
<tt>operation_not_permitted</tt> -- if the thread does not have the
necessary permission to change the state of the mutex object.
</li>
<li>
<tt>device_or_resource_busy</tt> -- if any native handle type
manipulated is already locked.
</li>
<li>
<tt>invalid_argument</tt> -- if any native handle type manipulated as
part of mutex construction is incorrect.
</li>
</ul>
</blockquote>





<hr>
<h3><a name="962"></a>962. Various threading bugs #12</h3>
<p><b>Section:</b> 30.4.2.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.4.2.2.2 [thread.lock.unique.locking]:  <tt>unique_lock::lock</tt> is
required to throw an object of type <tt>std::system_error</tt> "when the
postcondition cannot be achieved." The postcondition is <tt>owns == true</tt>,
and this is trivial to achieve. Presumably, the requirement is intended
to mean something more than that.
</p>

<p><i>[
Summit:
]</i></p>

<blockquote>
Move to open.
</blockquote>

<p><i>[
Beman has volunteered to provide proposed wording.
]</i></p>


<p><i>[
2009-07-21 Beman added wording to address 30.2.2 [thread.req.exception]
in response to the Frankfurt notes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>.
]</i></p>


<p><i>[
2009-09-25 Beman: minor update to wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>

<p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
<blockquote>
<p>Some functions described in this Clause are specified to throw exceptions of 
type <code>system_error</code> (19.5.5). Such exceptions shall be thrown if <ins>
any of the <i>Error conditions</i> are detected or</ins> a call to an operating 
system or other underlying API results in an error that prevents the library 
function from <del>satisfying its postconditions or from returning a meaningful 
value</del> <ins>meeting its specifications</ins>. <ins>Failure to
allocate storage shall be reported as described in
17.6.4.12 [res.on.exception.handling].</ins></p>
</blockquote>

<p><i>Change thread assignment 30.3.1.5 [thread.thread.member], join(), 
paragraph 8 as indicated:</i></p>
<blockquote>
<p><i>Throws:</i> <code>std::system_error</code> when <del>the postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>

</blockquote>

<p><i>Change thread assignment 30.3.1.5 [thread.thread.member], detach(), paragraph 
13 as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>

</blockquote>

<p><i>Change Mutex requirements 30.4.1 [thread.mutex.requirements], paragraph 
11, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
paragraph 3, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
paragraph 8, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
paragraph 13, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
paragraph 18, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change unique_lock locking 30.4.2.2.2 [thread.lock.unique.locking], 
paragraph 22, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change Function call_once 30.4.4.2 [thread.once.callonce], paragraph 4, as 
indicated</i></p>
<blockquote>
  <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>, 
  or any exception thrown by <code>func</code>.</p>
</blockquote>
<p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar], 
paragraph 12, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar], 
paragraph 19, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany], 
paragraph 10, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>
<p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany], 
paragraph 16, as indicated:</i></p>
<blockquote>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects, or 
postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>

<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as 
indicated:</i></p>
<blockquote>
<pre>template &lt;class Rep, class Period&gt; 
bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
              const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
<pre>...</pre>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
postcondition cannot be achieved</del> <ins>an exception is required ([thread.req.exception])</ins>.</p>
</blockquote>

<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as 
indicated:</i></p>
<blockquote>
<pre>template &lt;class Rep, class Period, class Predicate&gt; 
  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
                Predicate pred);</pre>
  <pre>...</pre>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or 
postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>

<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
applied to the working paper, change 30.5.2 [thread.condition.condvarany] as 
indicated:</i></p>
<blockquote>
<pre>template &lt;class Lock, class Rep, class Period&gt; 
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
  <pre>...</pre>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or 
postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>

<p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been 
applied to the working paper, change 30.5.2 [thread.condition.condvarany] as 
indicated:</i></p>
<blockquote>
<pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);</pre>
  <pre>...</pre>

<p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or 
postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
</blockquote>






<hr>
<h3><a name="963"></a>963. Various threading bugs #13</h3>
<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.3.1.5 [thread.thread.member]:  <tt>thread::detach</tt> is required to
throw an exception if the thread is "not a detachable thread".
"Detachable" is never defined.
</p>

<p><i>[
Howard adds:
]</i></p>


<blockquote>
Due to a mistake on my part, 3 proposed resolutions appeared at approximately
the same time.  They are all three noted below in the discussion.
</blockquote>

<p><i>[
Summit, proposed resolution:
]</i></p>


<blockquote>
<p>
In 30.3.1.5 [thread.thread.member] change:
</p>

<blockquote><pre>void detach();
</pre>
<blockquote>
<p>...</p>
<p>-14- <i>Error conditions:</i></p>
<ul>
<li><tt>no_such_process</tt> --  <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
<li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
</ul>
</blockquote>

</blockquote>

</blockquote>

<p><i>[
Post Summit, Jonathan Wakely adds:
]</i></p>


<blockquote>
<p>
A <tt>thread</tt> is detachable if it is joinable. As we've defined joinable,
we can just use that.
</p>
<p>
This corresponds to the pthreads specification, where pthread_detach
fails if the thread is not joinable:
</p>
<blockquote>
EINVAL: The  implementation  has  detected  that  the value specified by
thread does not refer to a joinable thread.
</blockquote>
<p>
Jonathan recommends this proposed wording:
</p>
<blockquote>
<p>
In 30.3.1.5 [thread.thread.member] change:
</p>

<blockquote><pre>void detach();
</pre>
<blockquote>
<p>...</p>
<p>-14- <i>Error conditions:</i></p>
<ul>
<li>...</li>
<li><tt>invalid_argument</tt> -- not a <del>detachable</del> <ins>joinable</ins> thread.</li>
</ul>
</blockquote>

</blockquote>
</blockquote>
</blockquote>

<p><i>[
Post Summit, Anthony Williams adds:
]</i></p>


<blockquote>
<p>
This is covered by the precondition that <tt>joinable()</tt> be <tt>true</tt>.
</p>
<p>
Anthony recommends this proposed wording:
</p>

<blockquote>
<p>
In 30.3.1.5 [thread.thread.member] change:
</p>

<blockquote><pre>void detach();
</pre>
<blockquote>
<p>...</p>
<p>-14- <i>Error conditions:</i></p>
<ul>
<li>...</li>
<li><del><tt>invalid_argument</tt> -- not a detachable thread.</del></li>
</ul>
</blockquote>

</blockquote>

</blockquote>

</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Mark as Ready with proposed resolution from Summit.
</blockquote>



<p><b>Proposed resolution:</b></p>

<p>
In 30.3.1.5 [thread.thread.member] change:
</p>

<blockquote><pre>void detach();
</pre>
<blockquote>
<p>...</p>
<p>-14- <i>Error conditions:</i></p>
<ul>
<li><tt>no_such_process</tt> --  <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
<li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
</ul>
</blockquote>

</blockquote>






<hr>
<h3><a name="965"></a>965. Various threading bugs #15</h3>
<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.5.1 [thread.condition.condvar]: the constructor for
<tt>condition_variable</tt> throws an exception with error code
<tt>device_or_resource_busy</tt> "if attempting to initialize a
previously-initialized but as of yet undestroyed <tt>condition_variable</tt>."
How can this occur?
</p>

<p><i>[
Summit:
]</i></p>

<blockquote>
<p>
Move to review. Proposed resolution: strike the <tt>device_or_resource_busy</tt>
error condition from the constructor of <tt>condition_variable</tt>.
</p>
<ul>
<li>
This is a POSIX error that cannot occur in this interface because the
C++ interface does not separate declaration from initialization.
</li>
</ul>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 30.5.1 [thread.condition.condvar] p3:
</p>

<blockquote>
<ul>
<li>...</li>
<li>
<del><tt>device_or_resource_busy</tt> -- if attempting to initialize a
previously-initialized but as of yet undestroyed
<tt>condition_variable</tt>.</del>
</li>
</ul>
</blockquote>





<hr>
<h3><a name="967"></a>967. Various threading bugs #17</h3>
<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
the error handling for the constructor for <tt>condition_variable</tt>
distinguishes lack of memory from lack of other resources, but the error
handling for the thread constructor does not. Is this difference
intentional?
</p>

<p><i>[
Beman has volunteered to provide proposed wording.
]</i></p>


<p><i>[
2009-09-25 Beman provided proposed wording.
]</i></p>


<blockquote>
The proposed resolution assumes <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a> has been accepted and
its proposed resolution applied to the working paper.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>


<p><span style="font-style: italic">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
paragraph 4, as indicated:</span></p>
<blockquote>

<p><i>Error conditions:</i></p>
  <blockquote>

<ul>
<li><del> <code>not_enough_memory</code> � if there is not enough memory to construct 
the mutex object.</del></li>

<li><code>resource_unavailable_try_again</code> � if any native handle type 
manipulated is not available.</li>

<li><code>operation_not_permitted</code> � if the thread does not have the 
necessary permission to change the state of the mutex object.</li>

<li><code>device_or_resource_busy</code> � if any native handle type 
manipulated is already locked.</li>

<li><code>invalid_argument</code> � if any native handle type manipulated as 
part of mutex construction is incorrect.</li>
</ul>
  </blockquote>
</blockquote>

<p><span style="font-style: italic">Change Class condition_variable 30.5.1 [thread.condition.condvar], 
default constructor, as indicated:</span></p>
<blockquote>
  <p><code>condition_variable();</code></p>
  <blockquote>
    <p><i>Effects:</i> Constructs an object of type <code>condition_variable</code>.</p>
    <p><ins><i>Throws:</i> <code>std::system_error</code> when an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
    <p><i>Error conditions:</i></p>
    <blockquote>
    <ul>
      <li><del><code>not_enough_memory</code> � if a memory limitation prevents 
      initialization.</del></li>
      <li> <code>resource_unavailable_try_again</code> � if some non-memory 
      resource limitation prevents initialization.</li>
      <li> <code>device_or_resource_busy</code> � if attempting to initialize a 
      previously-initialized but as of yet undestroyed <code>condition_variable</code>.</li>
    </ul>
    </blockquote>
  </blockquote>
</blockquote>





<hr>
<h3><a name="968"></a>968. Various threading bugs #18</h3>
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.4.1 [thread.mutex.requirements]: several functions are
required to throw exceptions "if the thread does not have the necessary
permission ...". "The necessary permission" is not defined.
</p>

<p><i>[
Summit:
]</i></p>

<blockquote>
Move to open.
</blockquote>


<p><i>[
Beman has volunteered to provide proposed wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready with minor word-smithing in the example.
</blockquote>



<p><b>Proposed resolution:</b></p>


<p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
<blockquote>
<p>Some functions described in this Clause are 
specified to throw exceptions of type <code>system_error</code> (19.5.5). Such exceptions 
shall be thrown if any of the <i>Error conditions</i> are detected or a call to an operating system or other underlying API 
results in an error that prevents the library function from meeting its specifications.
<i>[Note:</i> See 17.6.4.12 [res.on.exception.handling] for exceptions thrown to report 
storage allocation failures. <i>�end 
note]</i></p>

<p><ins><i>[Example:</i></ins></p>

<blockquote>

<p><ins>Consider a function in this clause that is specified to throw exceptions of type <code>
system_error</code> and specifies <i>Error conditions</i> that include <code>
operation_not_permitted</code> for a thread that does not have the privilege to 
perform the operation. Assume that, during the execution of this function, an <code>errno</code> 
of <code>EPERM</code> is reported by a POSIX API call used by the 
implementation. Since POSIX specifies an <code>errno</code> of <code>EPERM</code> 
when "the caller does not have the privilege to perform the operation", 
the implementation maps <code>EPERM</code>&nbsp; to an <code>error_condition</code> 
of <code>operation_not_permitted</code> (19.5 [syserr]) and an exception of type <code>
system_error</code> is thrown. </ins></p>

</blockquote>

<p><ins><i>�end example]</i></ins></p>

<p><span style="font-style: italic">Editorial note: For the sake of exposition, 
the existing text above is shown with the changes proposed in issues 962 and 967. The 
proposed additional example is independent of whether or not the 962 and 967 
proposed resolutions are accepted.</span></p>

</blockquote>

<p><span style="font-style: italic">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
paragraph 4, as indicated:</span></p>

<blockquote>

<p>� <code>operation_not_permitted</code> � if the thread does not have the 
<del>necessary permission to change the state of the mutex object</del> <ins>privilege to perform the operation</ins>.</p>

</blockquote>

<p><span style="font-style: italic">Change Mutex requirements 30.4.1 [thread.mutex.requirements], 
paragraph 12, as indicated:</span></p>

<blockquote>

<p>� <code>operation_not_permitted</code> � if the thread does not have the 
<del>necessary permission to change the state of the mutex</del> <ins>privilege to perform the operation</ins>.</p>

</blockquote>






<hr>
<h3><a name="970"></a>970. addressof overload unneeded</h3>
<p><b>Section:</b> 20.9.8.1 [specialized.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-16 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.9.8.1 [specialized.addressof] specifies:
</p>

<blockquote><pre>template &lt;ObjectType T&gt; T* addressof(T&amp; r);
template &lt;ObjectType T&gt; T* addressof(T&amp;&amp; r);
</pre></blockquote>

<p>
The two signatures are ambiguous when the argument is an lvalue.  The
second signature seems not useful:  what does it mean to take the
address of an rvalue?
</p>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
Recommend Review.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>

<p><i>[
2009-11-18 Moved from Pending WP to WP.  Confirmed in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.8.1 [specialized.addressof]:
</p>

<blockquote><pre>template &lt;ObjectType T&gt; T* addressof(T&amp; r);
<del>template &lt;ObjectType T&gt; T* addressof(T&amp;&amp; r);</del>
</pre></blockquote>






<hr>
<h3><a name="974"></a>974. <tt>duration&lt;double&gt;</tt> should not implicitly convert to <tt>duration&lt;int&gt;</tt></h3>
<p><b>Section:</b> 20.11.3.1 [time.duration.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following code should not compile because it involves implicit truncation
errors (against the design philosophy of the <tt>duration</tt> library).
</p>

<blockquote><pre>duration&lt;double&gt; d(3.5);
duration&lt;int&gt; i = d;  <font color="#C80000">// implicit truncation, should not compile</font>
</pre></blockquote>

<p>
This intent was codified in the example implementation which drove this proposal
but I failed to accurately translate the code into the specification in this
regard.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We agree with the proposed resolution.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved from Tentatively Ready to Open only because the wording needs to be
improved for enable_if type constraining, possibly following Robert's
formula.
</blockquote>

<p><i>[
2009-08-01 Howard adds:
]</i></p>


<blockquote>
Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Not completely addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>.  Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.11.3.1 [time.duration.cons], p4:
</p>

<blockquote>
<pre>template &lt;class Rep2, class Period2&gt; 
  duration(const duration&lt;Rep2, Period2&gt;&amp; d);
</pre>
<blockquote>
-4- <i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt>
shall be <tt>true</tt> or <ins>both</ins> <tt>ratio_divide&lt;Period2,
period&gt;::type::den</tt> shall be 1
<ins>and <tt>treat_as_floating_point&lt;Rep2&gt;::value</tt>
shall be <tt>false</tt></ins>.
Diagnostic required.
[<i>Note:</i> This requirement prevents implicit truncation error when
converting between integral-based <tt>duration</tt> types. Such a
construction could easily lead to confusion about the value of the
<tt>duration</tt>. -- <i>end note</i>]
</blockquote>
</blockquote>





<hr>
<h3><a name="975"></a>975. <tt>is_convertible</tt> cannot be instantiated for  non-convertible types</h3>
<p><b>Section:</b> 20.7.6 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-01-25 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<b>Addresses UK 206</b>

<p>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1114">1114</a>.
</p>

<p>
The current specification of <tt>std::is_convertible</tt> (reference is draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
is basically defined by 20.7.6 [meta.rel]/4:
</p>

<blockquote>
<p>
In order to instantiate the template <tt>is_convertible&lt;From,
To&gt;</tt>, the following code shall be well formed:
</p>

<blockquote><pre>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();

To test() {
  return create&lt;From&gt;();
}
</pre></blockquote>

<p>
[<i>Note:</i> This requirement gives well defined results for reference
types, void types, array types, and function types. --<i>end note</i>]
</p>
</blockquote>

<p>
The first sentence can be interpreted, that e.g. the expression
</p>

<blockquote><pre>std::is_convertible&lt;double, int*&gt;::value
</pre></blockquote>

<p>
is ill-formed because <tt>std::is_convertible&lt;double, int*&gt;</tt> could not be
instantiated, or in more general terms: The wording requires that
<tt>std::is_convertible&lt;X, Y&gt;</tt> cannot be instantiated for otherwise valid
argument types <tt>X</tt> and <tt>Y</tt> if <tt>X</tt> is not convertible to <tt>Y</tt>.
</p>

<p>
This semantic is both unpractical and in contradiction to what the last type
traits paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html">N2255</a>
proposed:
</p>

<blockquote>
<p>
If the following <tt>test</tt> function is well formed code <tt>b</tt>
is <tt>true</tt>, else it is <tt>false</tt>.
</p>

<blockquote><pre>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();

To test() {
  return create&lt;From&gt;();
}
</pre></blockquote>

<p>
[<i>Note:</i> This definition gives well defined results for <tt>reference</tt>
types, <tt>void</tt> types, array types, and function types. --<i>end note</i>]
</p>
</blockquote>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Jens: Checking that code is well-formed and then returning true/false
sounds like speculative compilation. John Spicer would really dislike
this. Please find another wording suggesting speculative compilation.
</p>
<p>
Recommend Open.
</p>
</blockquote>

<p><i>[
Post Summit, Howard adds:
]</i></p>


<blockquote>
<p>
John finds the following wording clearer:
</p>
<blockquote>

<table border="1">
<tbody><tr>
<th>Template</th><th>Condition</th><th>Comments</th>
</tr>
<tr>
<td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
<td><i>see below</i></td>
<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
or (possibly cv-qualified) <tt>void</tt> types.</td>
</tr>
</tbody></table>

<p>
Given the following function prototype:
</p>

<blockquote><pre>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();
</pre></blockquote>

<p>
<tt>is_convertible&lt;From, To&gt;::value</tt> shall be <tt>true</tt> if the
return expression in the following code would be well-formed, including
any implicit conversions to the return type of the function, else
<tt>is_convertible&lt;From, To&gt;::value</tt> shall be <tt>false</tt>.
</p>

<blockquote><pre>To test() {
  return create&lt;From&gt;();
}
</pre></blockquote>

</blockquote>

</blockquote>

<b>Original proposed wording:</b>

<p>
In 20.7.6 [meta.rel]/4 change:
</p>

<blockquote>
<del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
following code shall be well formed</del> <ins>If the following code
is well formed <tt>is_convertible&lt;From, To&gt;::value</tt> is <tt>true</tt>, otherwise
<tt>false</tt></ins>:[..]
</blockquote>

<p><b>Revision 2</b></p>

<blockquote>

<p>
In 20.7.6 [meta.rel] change:
</p>

<blockquote>

<table border="1">
<tbody><tr>
<th>Template</th><th>Condition</th><th>Comments</th>
</tr>
<tr>
</tr><tr><td>...</td><td>...</td><td>...</td></tr>
<tr><td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
<td>
<del>The code set out below shall be well formed.</del>
<ins><i>see below</i></ins></td>
<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
or (possibly cv-qualified) <tt>void</tt> types.</td>
</tr>
</tbody></table>

<p>
-4- <del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
following code shall be well formed:</del>
<ins>Given the following function prototype:</ins>
</p>

<blockquote><pre>template &lt;class T&gt; 
  typename add_rvalue_reference&lt;T&gt;::type create();
</pre></blockquote>

<p>
<ins><tt>is_convertible&lt;From, To&gt;::value</tt> inherits either directly or
indirectly from <tt>true_type</tt> if the
return expression in the following code would be well-formed, including
any implicit conversions to the return type of the function, else
<tt>is_convertible&lt;From, To&gt;::value</tt> inherits either directly or
indirectly from <tt>false_type</tt>.</ins>
</p>

<blockquote><pre>To test() { 
  return create&lt;From&gt;(); 
}
</pre></blockquote>

<p>
[<i>Note:</i> This requirement gives well defined results for reference types,
void types, array types, and function types. <i>-- end note</i>]
</p>

</blockquote>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>

<p>
In 20.7.6 [meta.rel] change:
</p>

<blockquote>

<table border="1">
<tbody><tr>
<th>Template</th><th>Condition</th><th>Comments</th>
</tr>
<tr>
</tr><tr><td>...</td><td>...</td><td>...</td></tr>
<tr><td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
<td>
<del>The code set out below shall be well formed.</del>
<ins><i>see below</i></ins></td>
<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
or (possibly cv-qualified) <tt>void</tt> types.</td>
</tr>
</tbody></table>

<p>
-4- <del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
following code shall be well formed:</del>
<ins>Given the following function prototype:</ins>
</p>

<blockquote><pre>template &lt;class T&gt; 
  typename add_rvalue_reference&lt;T&gt;::type create();
</pre></blockquote>

<p>
<ins>the predicate condition for a template specialization
<tt>is_convertible&lt;From, To&gt;</tt> shall be satisfied, if and only
if the return expression in the following code would be well-formed,
including any implicit conversions to the return type of the
function.</ins>
</p>

<blockquote><pre>To test() { 
  return create&lt;From&gt;(); 
}
</pre></blockquote>

<p>
[<i>Note:</i> This requirement gives well defined results for reference types,
void types, array types, and function types. <i>� end note</i>]
</p>

</blockquote>





<hr>
<h3><a name="978"></a>978. Hashing smart pointers</h3>
<p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-02 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 208</b></p>
<p>
I don't see an open issue on supporting <tt>std::hash</tt> for smart pointers
(<tt>unique_ptr</tt> and <tt>shared_ptr</tt> at least).
</p>
<p>
It seems reasonable to at least expect support for the smart
pointers, especially as they support comparison for use in ordered
associative containers.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Howard points out that the client can always supply a custom hash function.
</p>
<p>
Alisdair replies that the smart pointer classes are highly likely
to be frequently used as hash keys.
</p>
<p>
Bill would prefer to be conservative.
</p>
<p>
Alisdair mentions that this issue may also be viewed as a subissue or
duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.
</p>
<p>
Move to Open, and recommend the issue be deferred until after the next
Committee Draft is issued.
</p>
</blockquote>

<p><i>[
2009-05-31 Peter adds:
]</i></p>


<blockquote>
<blockquote>
Howard points out that the client can always supply a custom hash function.
</blockquote>
<p>
Not entirely true. The client cannot supply the function that hashes the
address of the control block (the equivalent of the old <tt>operator&lt;</tt>, now
proudly carrying the awkward name of '<tt>owner_before</tt>'). Only the
implementation can do that, not necessarily via specializing <tt>hash&lt;&gt;</tt>, of
course.
</p>
<p>
This hash function makes sense in certain situations for <tt>shared_ptr</tt>
(when one needs to switch from <tt>set/map</tt> using ownership ordering to
<tt>unordered_set/map</tt>) and is the only hash function that makes sense for
<tt>weak_ptr</tt>.
</p>
</blockquote>

<p><i>[
2009-07-28 Alisdair provides wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
2009-11-16 Moved from Ready to Open:
]</i></p>


<blockquote>
<p>
Pete writes:
</p>
<blockquote>
<p>
As far as I can see, "...suitable for using this type as key in unordered
associative containers..." doesn't define any semantics. It's advice to the
reader, and if it's present at all it should be in a note. But we have far too
much of this sort of editorial commentary as it is.
</p>
<p>
And in the resolution of 978 it's clearly wrong: it says that if there is no
hash specialization available for <tt>D::pointer</tt>, the implementation may provide
<tt>hash&lt;unique_ptr&lt;T,D&gt;&gt;</tt> if the result is not suitable for use in unordered
containers.
</p>
</blockquote>

<p>
Howard writes:
</p>

<blockquote>
Is this a request to pull 978 from Ready?
</blockquote>

<p>
Barry writes:
</p>
<blockquote>
<p>
I read this as more than a request. The PE says it's wrong, so it can't be
Ready.
</p>
</blockquote>

</blockquote>

<p><i>[
2010-01-31 Alisdair: related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>.
]</i></p>


<p><i>[
2010-02-08 Beman updates wording.
]</i></p>


<p><i>[
2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>Add the following declarations to the synopsis of <tt>&lt;memory&gt;</tt> in 
20.9 [memory] </i></p>

<blockquote>
<pre><ins>// [util.smartptr.hash] hash support
template &lt;class T&gt; struct hash;
template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;
template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;</ins></pre>
</blockquote>

<p><i>Add a new subclause under 20.9.10 [util.smartptr] called hash support </i></p>

<blockquote>
<h3><ins>hash support [util.smartptr.hash]</ins></h3>

<pre><ins>template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;</ins></pre>

<blockquote>
<p><ins>
Specialization meeting the requirements of class template <tt>hash</tt> (20.8.15 [unord.hash]). For an object <tt>p</tt> of type <tt>UP</tt>, where
<tt>UP</tt> is a type <tt>unique_ptr&lt;T,D&gt;</tt>,
<tt>hash&lt;UP&gt;()(p)</tt> shall evaluate to the same value as
<tt>hash&lt;typename UP::pointer&gt;()(p.get())</tt>. The specialization
<tt>hash&lt;typename UP::pointer&gt;</tt> is required to be well-formed.
</ins></p>
</blockquote>

<pre><ins>template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;</ins></pre>

<blockquote>
<p><ins>
Specialization meeting the requirements of class template <tt>hash</tt> (20.8.15 [unord.hash]). For an object <tt>p</tt> of type
<tt>shared_ptr&lt;T&gt;</tt>, <tt>hash&lt;shared_ptr&lt;T&gt;&gt;()(p)</tt>
shall evaluate to the same value as <tt> hash&lt;T*&gt;()(p.get())</tt>.
</ins></p>
</blockquote>
</blockquote>






<hr>
<h3><a name="981"></a>981. Unordered container requirements should add  <tt>initializer_list</tt> support</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Refering to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
all container requirements tables (including those for
associative containers) provide useful member function overloads
accepting <tt>std::initializer_list</tt> as argument, the only exception is
Table 87. There seems to be no reason for not providing them, because 23.7 [unord]
is already <tt>initializer_list</tt>-aware. For the sake of 
library interface consistency and user-expectations corresponding 
overloads should be added to the table requirements of unordered 
containers as well.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We agree with the proposed resolution.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>

<p>
In 23.2.5 [unord.req]/9 insert:
</p>

<blockquote>
... <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <ins><tt>il</tt>
designates an object of type <tt>initializer_list&lt;value_type&gt;</tt>, </ins><tt>t</tt> is a value of type
<tt>X::value_type</tt>, ...
</blockquote>

<p>
In 23.2.5 [unord.req], Table 87 insert:
</p>

<blockquote>
<table border="1">
<caption>Table 87 - Unordered associative container requirements (in addition to container)</caption>
<tbody><tr>
<th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
</tr>
<tr>
<td><tt>X(i, j)<br>X a(i, j)</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
</tr>
<tr>
<td><ins><tt>X(il)</tt></ins></td> <td><ins><tt>X</tt></ins></td> 
<td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td> 
<td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td>
</tr>
<tr>
<td>...</td> <td>...</td> <td>...</td> <td>...</td>
</tr>
<tr>
<td><tt>a = b</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
</tr>
<tr>
<td><ins><tt>a = il</tt></ins></td> <td><ins><tt>X&amp;</tt></ins></td> 
<td><ins><tt>a = X(il); return *this;</tt></ins></td> 
<td><ins>Same as <tt>a = X(il)</tt>.</ins></td>
</tr>
<tr>
<td>...</td> <td>...</td> <td>...</td> <td>...</td>
</tr>
<tr>
<td><tt>a.insert(i, j)</tt></td> <td><tt>void</tt></td> <td>...</td> <td>...</td>
</tr>
<tr>
<td><ins><tt>a.insert(il)</tt></ins></td> <td><ins><tt>void</tt></ins></td> 
<td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td> 
<td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td>
</tr>
</tbody></table>
</blockquote>






<hr>
<h3><a name="982"></a>982. Wrong complexity for initializer_list assignment in  Table 85</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2010-10-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
the associative container requirements table 85 says
    that assigning an <tt>initializer_list</tt> to such a container is of
    constant complexity, which is obviously wrong.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We agree with the proposed resolution.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>

<p>
In 23.2.4 [associative.reqmts], Table 85 change:
</p>

<blockquote>
<table border="1">
<caption>Table 85 - Associative container requirements (in addition to container)</caption>
<tbody><tr>
<th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
</tr>
<tr>
<td><tt>a = il</tt></td> <td><tt>X&amp;</tt></td> <td><tt>a = X(il);<br>return *this;</tt></td> 
<td><del>constant</del><ins>Same as <tt>a = X(il)</tt>.</ins></td>
</tr>
</tbody></table>
</blockquote>






<hr>
<h3><a name="983"></a>983. <tt>unique_ptr</tt> reference deleters should not be moved from</h3>
<p><b>Section:</b> 20.9.9.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-10 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Dave brought to my attention that when a <tt>unique_ptr</tt> has a non-const reference
type deleter, move constructing from it, even when the <tt>unique_ptr</tt> containing
the reference is an rvalue, could have surprising results:
</p>

<blockquote><pre>D d(some-state);
unique_ptr&lt;A, D&amp;&gt; p(new A, d);
unique_ptr&lt;A, D&gt; p2 = std::move(p);
<font color="#C80000">// has d's state changed here?</font>
</pre></blockquote>

<p>
I agree with him.  It is the <tt>unique_ptr</tt> that is the rvalue, not the
deleter.  When the deleter is a reference type, the <tt>unique_ptr</tt> should
respect the "lvalueness" of the deleter.
</p>

<p>
Thanks Dave.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Seems correct, but complicated enough that we recommend moving to Review.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
2010-03-14 Howard adds:
]</i></p>


<blockquote>
We moved
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
to the formal motions page in Pittsburgh which should obsolete this issue.  I've
moved this issue to NAD Editorial, solved by N3073.
</blockquote>



<p><b>Rationale:</b></p>
<p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor], p20-21
</p>

<blockquote>
<pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
</pre>

<blockquote>

<p>
-20- <i>Requires:</i> If <tt><del>D</del> <ins>E</ins></tt> is not a reference type,
construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
shall be well formed and shall not throw an exception.
<ins>
Otherwise <tt>E</tt> is a reference type and construction of the deleter
<tt>D</tt> from an lvalue of type <tt>E</tt> shall be well formed and
shall not throw an exception.
</ins>
If <tt>D</tt> is
a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
(diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
implicitly convertible to <tt>pointer</tt>. [<tt>Note:</tt> These
requirements imply that <tt>T</tt> and <tt>U</tt> are complete types.
<i>-- end note</i>]
</p>

<p>
-21- <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns the
pointer which <tt>u</tt> owns (if any). If the deleter
<ins><tt>E</tt></ins> is not a reference type, <del>it</del> <ins>this
deleter</ins> is move constructed from <tt>u</tt>'s deleter, otherwise
<del>the reference</del> <ins>this deleter</ins> is copy constructed
from <tt>u</tt>.'s deleter. After the construction, <tt>u</tt> no longer
owns a pointer. [<i>Note:</i> The deleter constructor can be implemented
with <tt>std::forward&lt;<del>D</del><ins>E</ins>&gt;</tt>. <i>-- end
note</i>]
</p>

</blockquote>
</blockquote>

<p>
Change 20.9.9.2.3 [unique.ptr.single.asgn], p1-3
</p>

<blockquote>
<pre>unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
</pre>
<blockquote>

<p>
-1- <i>Requires:</i> <ins>If the deleter <tt>D</tt> is not a reference type,</ins>
<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue <tt>D</tt> shall not throw an exception.
<ins>
Otherwise the deleter <tt>D</tt> is a reference type,
and assignment of the deleter <tt>D</tt> from an lvalue <tt>D</tt> shall not throw an exception.</ins>
</p>

<p>
-2- <i>Effects:</i> reset(u.release()) followed by
a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
<ins><tt>std::forward&lt;D&gt;(u.get_deleter())</tt></ins>.
</p>

<p>
-3- <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer
which <tt>u</tt> owned, and <tt>u</tt> no longer owns it. <del>[<i>Note:</i> If
<tt>D</tt> is a reference type, then the referenced lvalue deleters are
move assigned. <i>-- end note</i>]</del>
</p>
</blockquote>
</blockquote>

<p>
Change 20.9.9.2.3 [unique.ptr.single.asgn], p6-7
</p>

<blockquote>
<pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
</pre>
<blockquote>

<p>
<i>Requires:</i> <ins>If the deleter <tt>E</tt> is not a reference type,</ins>
<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue
<tt><del>D</del><ins>E</ins></tt> shall not throw an exception.
<ins>
Otherwise the deleter <tt>E</tt> is a reference type,
and assignment of the deleter <tt>D</tt> from an lvalue <tt>E</tt> shall not throw an exception.</ins>
<tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U&gt;</tt>
are complete types. <i>-- end note</i>]
</p>

<p>
<i>Effects:</i> <tt>reset(u.release())</tt> followed by
a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
<ins><tt>std::forward&lt;E&gt;(u.get_deleter())</tt></ins>.
<del>If either
<tt>D</tt> or <tt>E</tt> is a reference type, then the referenced lvalue
deleter participates in the move assignment.</del>
</p>

</blockquote>
</blockquote>






<hr>
<h3><a name="984"></a>984. Does <tt>&lt;cinttypes&gt;</tt> have macro guards?</h3>
<p><b>Section:</b> 27.9.2 [c.files] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-12 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The C standard says about <tt>&lt;inttypes.h&gt;</tt>:
</p>

<blockquote>
C++ implementations should define these macros only when <tt>__STDC_FORMAT_MACROS</tt>is defined 
before <tt>&lt;inttypes.h&gt;</tt> is included.
</blockquote>

<p>
The C standard has a similar note about <tt>&lt;stdint.h&gt;</tt>.  For <tt>&lt;cstdint&gt;</tt>
we adopted a "thanks but no thanks" policy and documented that fact in
18.4.1 [cstdint.syn]:
</p>

<blockquote>
... [<i>Note:</i> The macros defined by <tt>&lt;stdint&gt;</tt> are
provided unconditionally. In particular, the symbols
<tt>__STDC_LIMIT_MACROS</tt> and <tt>__STDC_CONSTANT_MACROS</tt>
(mentioned in C99 footnotes 219, 220, and 222) play no role in C++.
<i>-- end note</i>]
</blockquote>

<p>
I recommend we put a similar note in 27.9.2 [c.files] regarding <tt>&lt;cinttypes&gt;</tt>.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Add to 27.9.2 [c.files]:
</p>

<blockquote>
Table 112 describes header <tt>&lt;cinttypes&gt;</tt>.
<ins>
[<i>Note:</i> The macros defined by <tt>&lt;cintypes&gt;</tt> are
provided unconditionally. In particular, the symbol
<tt>__STDC_FORMAT_MACROS</tt>
(mentioned in C99 footnote 182) plays no role in C++.
<i>-- end note</i>]
</ins>
</blockquote>





<hr>
<h3><a name="986"></a>986. Generic <tt>try_lock</tt> contradiction</h3>
<p><b>Section:</b> 30.4.3 [thread.lock.algorithm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Chris Fairles <b>Opened:</b> 2009-02-14 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 30.4.3 [thread.lock.algorithm], the generic <tt>try_lock</tt> effects (p2) say that a failed
<tt>try_lock</tt> is when it either returns <tt>false</tt> or throws an exception. In
the event a call to <tt>try_lock</tt> does fail, by either returning <tt>false</tt> or
throwing an exception, it states that <tt>unlock</tt> shall be called for all
prior arguments. Then the returns clause (p3) goes on to state
in a note that after returning, either all locks are locked or none
will be. So what happens if multiple locks fail on <tt>try_lock</tt>?
</p>

<p>
Example:
</p>

<blockquote><pre>#include &lt;mutex&gt;

int main() {
 std::mutex m0, m1, m2;
 std::unique_lock&lt;std::mutex&gt; l0(m0, std::defer_lock);
 std::unique_lock&lt;std::mutex&gt; l1(m1); //throws on try_lock
 std::unique_lock&lt;std::mutex&gt; l2(m2); //throws on try_lock

 int result = std::try_lock(l0, l1, l2);

 assert( !l0.owns_lock() );
 assert( l1.owns_lock() ); //??
 assert( l2.owns_lock() ); //??
}
</pre></blockquote>

<p>
The first lock's <tt>try_lock</tt> succeeded but, being a prior argument to a
lock whose <tt>try_lock</tt> failed, it gets unlocked as per the effects clause
of 30.4.3 [thread.lock.algorithm]. However, 2 locks remain locked in this case but the return
clause states that either all arguments shall be locked or none will
be. This seems to be a contradiction unless the intent is for
implementations to make an effort to unlock not only prior arguments,
but the one that failed and those that come after as well. Shouldn't
the note only apply to the arguments that were successfully locked?
</p>

<p>
Further discussion and possible resolutions in c++std-lib-23049.
</p>

<p><i>[
Summit:
]</i></p>

<blockquote>
Move to review. Agree with proposed resolution.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>

<p>
Change 30.4.3 [thread.lock.algorithm], p2:
</p>

<blockquote>
-2- <i>Effects:</i> Calls <tt>try_lock()</tt> for each argument in order
beginning with the first until all arguments have been processed or a
call to <tt>try_lock()</tt> fails, either by returning <tt>false</tt> or by throwing an
exception. If a call to <tt>try_lock()</tt> fails, <tt>unlock()</tt> shall be called for
all prior arguments<ins> and there shall be no further calls to <tt>try_lock()</tt></ins>.
</blockquote>

<p>
Delete the note from 30.4.3 [thread.lock.algorithm], p3
</p>

<blockquote>
-3- <i>Returns:</i> -1 if all calls to <tt>try_lock()</tt> returned <tt>true</tt>,
otherwise a 0-based index value that indicates 
the argument for which <tt>try_lock()</tt> returned <tt>false</tt>. <del>[<i>Note:</i>
On return, either all arguments will be 
locked or none will be locked. -- <i>end note</i>]</del>
</blockquote>





<hr>
<h3><a name="987"></a>987. <tt>reference_wrapper</tt> and function types</h3>
<p><b>Section:</b> 20.8.4 [refwrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-18 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The synopsis in 20.8.4 [refwrap] says:
</p>

<blockquote><pre>template &lt;<b>ObjectType</b> T&gt; class reference_wrapper
...
</pre></blockquote>

<p>
And then paragraph 3 says:
</p>

<blockquote>
<p>
The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall be
derived from <tt>std::unary_function&lt;T1, R&gt;</tt> only if the type
<tt>T</tt> is any of the following:
</p>

<ul>
<li>
a <b>function type</b> or a pointer to function type taking one argument of
type <tt>T1</tt> and returning <tt>R</tt>
</li>
</ul>
</blockquote>

<p>
But function types are not <tt>ObjectType</tt>s.
</p>

<p>
Paragraph 4 contains the same contradiction.
</p>

<p><i>[
Post Summit:
]</i></p>


<blockquote>
<p>
Jens: restricted reference to ObjectType
</p>
<p>
Recommend Review.
</p>
</blockquote>

<p><i>[
Post Summit, Peter adds:
]</i></p>


<blockquote>
<p>
In <a href="https://svn.boost.org/trac/boost/ticket/1846">https://svn.boost.org/trac/boost/ticket/1846</a>
however Eric Niebler makes the very reasonable point that <tt>reference_wrapper&lt;F&gt;</tt>,
where <tt>F</tt> is a function type, represents a reference to a function,
a legitimate entity. So <tt>boost::ref</tt> was changed to allow it.
</p>
<p>
<a href="https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp">https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp</a>
</p>
<p>
Therefore, I believe an alternative proposed resolution for issue 987 could simply
allow <tt>reference_wrapper</tt> to be used with function types.
</p>
</blockquote>

<p><i>[
Post Summit, Howard adds:
]</i></p>


<blockquote>
<p>
I agree with Peter (and Eric).  I got this one wrong on my first try.  Here
is code that demonstrates how easy (and useful) it is to instantiate
<tt>reference_wrapper</tt> with a function type:
</p>

<blockquote><pre>#include &lt;functional&gt;

template &lt;class F&gt;
void test(F f);

void f() {}

int main()
{
    test(std::ref(f));
}
</pre></blockquote>

<p>
Output (link time error shows type of <tt>reference_wrapper</tt> instantiated
with function type):
</p>

<blockquote><pre>Undefined symbols:
  "void test&lt;std::reference_wrapper&lt;void ()()&gt; &gt;(std::reference_wrapper&lt;void ()()&gt;)",...
</pre></blockquote>

<p>
I've taken the liberty of changing the proposed wording to allow function types
and set to Open.  I'll also freely admit that I'm not positive <tt>ReferentType</tt>
is the correct concept.
</p>

</blockquote>



<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Howard observed that <tt>FunctionType</tt>,
a concept not (yet?) in the Working Paper,
is likely the correct constraint to be applied.
However, the proposed resolution provides an adequate approximation.
</p>
<p>
Move to Review.
</p>
</blockquote>

<p><i>[
2009-05-23 Alisdair adds:
]</i></p>


<blockquote>
<p>
By constraining to <tt>PointeeType</tt> we rule out the ability for <tt>T</tt> to be a
reference, and call in reference-collapsing.  I'm not sure if this is
correct and intended, but would like to be sure the case was considered.
</p>
<p>
Is dis-allowing reference types and the
implied reference collapsing the intended result?
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved from Review to Open only because the wording needs to be
tweaked for concepts removal.
</blockquote>

<p><i>[
2009-10-14 Daniel provided de-conceptified wording.
]</i></p>


<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.4 [refwrap]/1 as indicated:
</p>

<blockquote>
<tt>reference_wrapper&lt;T&gt;</tt> is a <tt>CopyConstructible</tt> and
<tt><ins>Copy</ins>Assignable</tt> wrapper around a
reference to an object <ins>or function</ins> of type <tt>T</tt>.
</blockquote>








<hr>
<h3><a name="990"></a>990. <tt>monotonic_clock::is_monotonic</tt> must be <tt>true</tt></h3>
<p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.monotonic">issues</a> in [time.clock.monotonic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is some confusion over what the value of <tt>monotonic_clock::is_monotonic</tt>
when <tt>monotonic_clock</tt> is a  synonym for <tt>system_clock</tt>.  The
intent is that if <tt>monotonic_clock</tt> exists, then <tt>monotonic_clock::is_monotonic</tt>
is <tt>true</tt>.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We agree with the proposed resolution.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change X [time.clock.monotonic], p1:
</p>

<blockquote>
-1- Objects of class <tt>monotonic_clock</tt> represent clocks for which
values of <tt>time_point</tt> never decrease as physical time advances.
<tt>monotonic_clock</tt> may be a synonym for <tt>system_clock</tt>
<ins>if and only if <tt>system_clock::is_monotonic</tt> is
<tt>true</tt></ins>.
</blockquote>





<hr>
<h3><a name="991"></a>991. Response to JP 50</h3>
<p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Add custom allocator parameter to <tt>wstring_convert</tt>, since we cannot
allocate memory for strings from a custom allocator.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 22.3.3.2.2 [conversions.string]:
</p>

<blockquote><pre>template&lt;class Codecvt, class Elem = wchar_t<ins>,
         class Wide_alloc = std::allocator&lt;Elem&gt;,
         class Byte_alloc = std::allocator&lt;char&gt; </ins>&gt; class wstring_convert {
  public:
    typedef std::basic_string&lt;char<ins>, char_traits&lt;char&gt;, Byte_alloc</ins>&gt; byte_string;
    typedef std::basic_string&lt;Elem<ins>, char_traits&lt;Elem&gt;, Wide_alloc</ins>&gt; wide_string;
     ...
</pre></blockquote>

<p>
Change 22.3.3.2.2 [conversions.string], p3:
</p>

<blockquote>
-3- The class template describes an ob ject that controls conversions
between wide string ob jects of class
<tt>std::basic_string&lt;Elem<ins>, char_traits&lt;Elem&gt;, Wide_alloc</ins>&gt;</tt>
and byte string objects of class
<tt>std::basic_string&lt;char<ins>, char_traits&lt;char&gt;, Byte_alloc</ins>&gt;</tt>
<del>(also known as <tt>std::string</tt>)</del>.
</blockquote>






<hr>
<h3><a name="993"></a>993. Response to UK 188</h3>
<p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The function <tt>_Exit</tt> does not appear to be defined in this standard.
Should it be added to the table of functions included-by-reference to
the C standard?
</p>

<p><i>[
2009-05-09 Alisdair fixed some minor issues in the wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Add to 18.5 [support.start.term] Table 20 (Header
<tt>&lt;cstdlib&gt;</tt> synopsis) Functions:
</p>

<blockquote><pre>_Exit
</pre></blockquote>

<p>
Add before the description of <tt>abort(void)</tt>:
</p>

<blockquote><pre>void _Exit [[noreturn]] (int status)
</pre>

<blockquote>
<p>
The function <tt>_Exit(int status)</tt> has additional behavior in this
International Standard:
</p>
<ul>
<li>
The program is terminated without executing destructors for objects of
automatic, thread, or static storage duration and without calling the
functions passed to <tt>atexit()</tt> (3.6.3 [basic.start.term]).
</li>
</ul>
</blockquote>
</blockquote>






<hr>
<h3><a name="994"></a>994. Response to UK 193</h3>
<p><b>Section:</b> 18.6.2.3 [new.handler] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>quick_exit</tt> has been added as a new valid way to terminate a program in a
well defined way
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 18.6.2.3 [new.handler], p2:
</p>

<blockquote>
<p>
-2- <i>Required behavior:</i> ...
</p>
<ul>
<li>...</li>
<li>
<del>call either <tt>abort()</tt> or <tt>exit();</tt></del>
<ins>terminate execution of the program without returning to the caller</ins>
</li>
</ul>
</blockquote>







<hr>
<h3><a name="997"></a>997. Response to UK 163</h3>
<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Many functions are defined as "Effects: Equivalent to a...", which seems
to also define the preconditions, effects, etc. But this is not made
clear.
</p>

<p>
After studying the occurrences of "Effects: Equivalent to", I agree with
the diagnosis but disagree with the solution.  In 21.4.2 [string.cons]
we find
</p>

<blockquote>
<p>
14 <i>Effects:</i> If <tt>InputIterator</tt> is an integral type, equivalent to
<tt>basic_string(static_cast&lt;size_type&gt;(begin), static_cast&lt;value_type&gt;(end), a)</tt>
</p>
<p>
15 Otherwise constructs a string from the values in the range <tt>[begin,
end)</tt>, as indicated in the Sequence Requirements table (see 23.1.3).
</p>
</blockquote>

<p>
This would be devishly difficult to re-write with an explicit
"Equivalent to:" clause.  Instead, I propose the following, which will
result in much less editorial re-work.
</p>

<p><i>[
2009-05-09 Alisdair adds:
]</i></p>


<blockquote>
This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#492">492</a>.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Add a new paragraph after 17.5.1.4 [structure.specifications], p3:
</p>

<blockquote>
<p>
-3- Descriptions of function semantics contain the following elements (as appropriate):<sup>154</sup>
</p>

<ul>
<li>
<i>Requires:</i> the preconditions for calling the function
</li>
<li>
<i>Effects:</i> the actions performed by the function
</li>
<li>
<i>Postconditions:</i> the observable results established by the function
</li>
<li>
<i>Returns:</i> a description of the value(s) returned by the function
</li>
<li>
<i>Throws:</i> any exceptions thrown by the function, and the conditions that would cause the exception
</li>
<li>
<i>Complexity:</i> the time and/or space complexity of the function
</li>
<li>
<i>Remarks:</i> additional semantic constraints on the function
</li>
<li>
<i>Error conditions:</i> the error conditions for error codes reported by the function.
</li>
<li>
<i>Notes:</i> non-normative comments about the function
</li>
</ul>

<p><ins>
Whenever the <i>Effects</i> element specifies that the semantics of some
function <tt>F</tt> are <i>Equivalent to</i> some <i>code-sequence</i>, then
the various elements are interpreted as follows.  If <tt>F</tt>'s
semantics specifies a <i>Requires</i> element, then that requirement is
logically imposed prior to the <i>equivalent-to</i> semantics.  Then,
the semantics of the <i>code-sequence</i> are determined by the
<i>Requires</i>, <i>Effects</i>, <i>Postconditions</i>, <i>Returns</i>,
<i>Throws</i>, <i>Complexity</i>, <i>Remarks</i>, <i>Error
Conditions</i> and <i>Notes</i> specified for the (one or more) function
invocations contained in the <i>code-sequence</i>. The value returned from
<tt>F</tt> is specified by <tt>F</tt>'s <i>Returns</i> element, or
if <tt>F</tt> has no <i>Returns</i> element, a non-<tt>void</tt> return from <tt>F</tt> is specified 
by the <i>Returns</i> elements in <i>code-sequence</i>.  If
<tt>F</tt>'s semantics contains a <i>Throws</i> (or
<i>Postconditions</i>, or <i>Complexity</i>) element, then that
supersedes any occurrences of that element in the <i>code-sequence</i>.
</ins></p>
</blockquote>






<hr>
<h3><a name="998"></a>998. Smart pointer referencing its owner</h3>
<p><b>Section:</b> 20.9.9.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pavel Minaev <b>Opened:</b> 2009-02-26 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following (simplified) implementation of 
<tt>std::auto_ptr&lt;T&gt;::reset()</tt>: 
</p>

<blockquote><pre>void reset(T* newptr = 0) { 
   if (this-&gt;ptr &amp;&amp; this-&gt;ptr != newptr) { 
     delete this-&gt;ptr; 
   } 
   this-&gt;ptr = newptr; 
} 
</pre></blockquote>

<p>
Now consider the following code which uses the above implementation: 
</p>

<blockquote><pre>struct foo { 
   std::auto_ptr&lt;foo&gt; ap; 
   foo() : ap(this) {} 
   void reset() { ap.reset(); } 
}; 
int main() { 
   (new foo)-&gt;reset(); 
} 
</pre></blockquote>

<p>
With the above implementation of auto_ptr, this results in U.B. at the 
point of auto_ptr::reset(). If this isn't obvious yet, let me explain 
how this goes step by step: 
</p>

<ol>
<li>
<tt>foo::reset()</tt> entered 
</li>
<li>
<tt>auto_ptr::reset()</tt> entered 
</li>
<li>
<tt>auto_ptr::reset()</tt> tries to delete <tt>foo</tt>
</li>
<li>
<tt>foo::~foo()</tt> entered, tries to destruct its members 
</li>
<li>
<tt>auto_ptr::~auto_ptr()</tt> executed - <tt>auto_ptr</tt> is no longer a valid object! 
</li>
<li>
<tt>foo::~foo()</tt> left 
</li>
<li>
<tt>auto_ptr::reset()</tt> sets its "ptr" field to 0 &lt;- U.B.! <tt>auto_ptr</tt>
is not a valid object here already! 
</li>
</ol>

<p><i>[
Thanks to Peter Dimov who recognized the connection to <tt>unique_ptr</tt> and
brought this to the attention of the LWG, and helped with the solution.
]</i></p>


<p><i>[
Howard adds:
]</i></p>


<blockquote>
To fix this behavior <tt>reset</tt> must be specified such that deleting the
pointer is the last action to be taken within <tt>reset</tt>.
</blockquote>

<p><i>[
Alisdair adds:
]</i></p>


<blockquote>
<p>
The example providing the rationale for LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a> is poor, as it relies on
broken semantics of having two object believing they are unique owners of a
single resource.  It should not be surprising that UB results from such
code, and I feel no need to go out of our way to support such behaviour.
</p>
<p>
If an example is presented that does not imply multiple ownership of a
unique resource, I would be much more ready to accept the proposed
resolution.
</p>
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Howard summarizes:
</p>
<blockquote>
This issue has to do with circular ownership,
and affects <tt>auto_ptr</tt>, too (but we don't really care about that).
It is intended to spell out the order in which operations must be performed
so as to avoid the possibility
of undefined behavior in the self-referential case.
</blockquote>
<p>
Howard points to message c++std-lib-23175 for another example,
requested by Alisdair.
</p>
<p>
We agree with the issue and with the proposed resolution.
Move to Tentatively Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.9.2.5 [unique.ptr.single.modifiers], p5 (<i>Effects</i> clause for <tt>reset</tt>), and p6:
</p>

<blockquote>
<p>
-5- <i>Effects:</i> <del>If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.</del>
<ins>Assigns <tt>p</tt> to the stored <tt>pointer</tt>, and then if the old value of the <tt>pointer</tt> is not
equal to <tt>nullptr</tt>, calls <tt>get_deleter()(</tt>the old value of the <tt>pointer)</tt>.
[<i>Note:</i> The order of these operations is significant because the call to <tt>get_deleter()</tt>
may destroy <tt>*this</tt>. <i>-- end note</i>]</ins>
</p>

<p>
-6- Postconditions: <tt>get() == p</tt>.
<ins>[<i>Note:</i> The postcondition does not hold if the call to
<tt>get_deleter()</tt> destroys <tt>*this</tt> since <tt>this-&gt;get()</tt> is no longer a valid
expression. <i>-- end note</i>]</ins>
</p>
</blockquote>





<hr>
<h3><a name="999"></a>999. Taking the address of a function</h3>
<p><b>Section:</b> 20.9.8 [specialized.algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2010-10-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.algorithms].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The same fix (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#987">987</a>) may be applied to <tt>addressof</tt>, which is also constrained to
<tt>ObjectType</tt>. (That was why <tt>boost::ref</tt> didn't work with functions - it
tried to apply <tt>boost::addressof</tt> and the <tt>reinterpret_cast&lt;char&amp;&gt;</tt>
implementation of <tt>addressof</tt> failed.)
</p>



<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We agree.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved from Tentatively Ready to Open only because the wording needs to be
tweaked for concepts removal.
</blockquote>

<p><i>[
2009-10-10 Daniel updates wording to concept-free.
]</i></p>


<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p><i>[
The resolution assumes that <tt>addressof</tt> is reintroduced as described in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2946.pdf">n2946</a>
]</i></p>


<p>
In 20.9.8 [specialized.algorithms] change as described:
</p>

<blockquote><pre>template &lt;class T&gt; T* addressof(T&amp; r);
</pre>
<blockquote>
<i>Returns:</i> The actual address of the object <ins>or function</ins>
referenced by <tt>r</tt>, even in the
presence of an overloaded <tt>operator&amp;</tt>.
</blockquote>
</blockquote>







<hr>
<h3><a name="1004"></a>1004. Response to UK 179</h3>
<p><b>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 179</b></p>

<p>
According to the 4th bullet there is a problem if "if any replacement
function or handler function or destructor operation throws an
exception". There should be no problem throwing exceptions so long as
they are caught within the function.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
The phrasing "throws an exception" is commonly used elsewhere
to mean "throws or propagates an exception."
Move to Open pending a possible more general resolution.
</blockquote>

<p><i>[
2009-07 Frankfurt:
]</i></p>


<blockquote>
Replace "propagates" in the proposed resolution with the phrase "exits
via" and move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change the 4th bullet of 17.6.3.8 [res.on.functions], p2:
</p>

<blockquote>
<ul>
<li>
if any replacement function or handler function or destructor operation
<del>throws</del> <ins>exits via</ins> an exception, unless specifically
allowed in the applicable <i>Required behavior:</i> paragraph.
</li>
</ul>
</blockquote>






<hr>
<h3><a name="1006"></a>1006. <tt>operator delete</tt> in garbage collected implementation</h3>
<p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 190</b></p>

<p>
It is not entirely clear how the current specification acts in the
presence of a garbage collected implementation.
</p>

<p><i>[
Summit:
]</i></p>

 
<blockquote>
Agreed.
</blockquote>

<p><i>[
2009-05-09 Alisdair adds:
]</i></p>


<blockquote>
Proposed wording is too strict for implementations that do not support
garbage collection.  Updated wording supplied.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We recommend advancing this to Tentatively Ready
with the understanding that it will not be moved for adoption
unless and until the proposed resolution to Core issue #853 is adopted.
</blockquote>


<p><b>Proposed resolution:</b></p>

<p>
(Editorial note: This wording ties into the proposed
resolution for Core #853)
</p>

<p>
Add paragraphs to 18.6.1.1 [new.delete.single]:
</p>

<blockquote><pre>void operator delete(void* ptr) throw();
<del>void operator delete(void* ptr, const std::nothrow_t&amp;) throw();</del>
</pre>

<p><i>[
The second signature deletion above is editorial.
]</i></p>


<blockquote>
<p><ins>
<i>Requires:</i> If an implementation has strict pointer safety
(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
be a safely-derived pointer.
</ins></p>

<p>-10- ...</p>
</blockquote>

<pre>void operator delete(void* ptr, const std::nothrow_t&amp;) throw();
</pre>

<blockquote>
<p><ins>
<i>Requires:</i> If an implementation has strict pointer safety
(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
be a safely-derived pointer.
</ins></p>

<p>-15- ...</p>
</blockquote>

</blockquote>

<p>
Add paragraphs to 18.6.1.2 [new.delete.array]:
</p>

<blockquote><pre>void operator delete[](void* ptr) throw();
<del>void operator delete[](void* ptr, const std::nothrow_t&amp;) throw();</del>
</pre>

<p><i>[
The second signature deletion above is editorial.
]</i></p>


<blockquote>
<p><ins>
<i>Requires:</i> If an implementation has strict pointer safety
(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
be a safely-derived pointer.
</ins></p>

<p>-9- ...</p>
</blockquote>

<pre>void operator delete[](void* ptr, const std::nothrow_t&amp;) throw();
</pre>

<blockquote>
<p><ins>
<i>Requires:</i> If an implementation has strict pointer safety
(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
be a safely-derived pointer.
</ins></p>

<p>-13- ...</p>
</blockquote>

</blockquote>


<p>
Add paragraphs to 18.6.1.3 [new.delete.placement]:
</p>

<blockquote><pre>void operator delete(void* ptr, void*) throw();
</pre>

<blockquote>
<p><ins>
<i>Requires:</i> If an implementation has strict pointer safety
(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
be a safely-derived pointer.
</ins></p>

<p>-7- ...</p>
</blockquote>

<pre>void operator delete[](void* ptr, void*) throw();
</pre>

<blockquote>
<p><ins>
<i>Requires:</i> If an implementation has strict pointer safety
(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
be a safely-derived pointer.
</ins></p>

<p>-9- ...</p>
</blockquote>

</blockquote>






<hr>
<h3><a name="1011"></a>1011. <tt>next/prev</tt> wrong iterator type</h3>
<p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 271</b></p>

<p>
<tt>next/prev</tt> return an incremented iterator without changing the value of
the original iterator. However, even this may invalidate an
<tt>InputIterator</tt>. A <tt>ForwardIterator</tt> is required to guarantee the
'multipass' property.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved from Tentatively Ready to Open only because the wording needs to be
tweaked for concepts removal.
</blockquote>

<p><i>[
2009-10-14 Daniel provided de-conceptified wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>


<ol>
<li>
<p>
Change header <tt>&lt;iterator&gt;</tt> synopsis 24.3 [iterator.synopsis] as indicated:
</p>

<blockquote><pre>// 24.4.4, iterator operations:
...
template &lt;class <del>Input</del><ins>Forward</ins>Iterator&gt;
  <del>Input</del><ins>Forward</ins>Iterator
  next(<del>Input</del><ins>Forward</ins>Iterator x, typename std::iterator_traits&lt;<del>Input</del><ins>Forward</ins>Iterator&gt;::difference_type n = 1);
</pre></blockquote>
</li>

<li>
<p>
Change 24.4.4 [iterator.operations] before p.6 as indicated:
</p>

<blockquote><pre>template &lt;class <del>Input</del><ins>Forward</ins>Iterator&gt;
  <del>Input</del><ins>Forward</ins>Iterator
  next(<del>Input</del><ins>Forward</ins>Iterator x, typename std::iterator_traits&lt;<del>Input</del><ins>Forward</ins>Iterator&gt;::difference_type n = 1);
</pre></blockquote>
</li>
</ol>






<hr>
<h3><a name="1012"></a>1012. <tt>reverse_iterator</tt> default ctor should value initialize</h3>
<p><b>Section:</b> 24.5.1.3.1 [reverse.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 277</b></p>

<p>
The default constructor default-initializes current, rather than
value-initializes. This means that when Iterator corresponds to a
trivial type, the current member is left un-initialized, even when the
user explictly requests value intialization! At this point, it is not
safe to perform any operations on the reverse_iterator other than assign
it a new value or destroy it. Note that this does correspond to the
basic definition of a singular iterator.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree with option i.
</blockquote>

<p>
Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We believe this should be revisited
in conjunction with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#408">408</a>,
which nearly duplicates this issue.
Move to Open.
</blockquote>

<p><i>[
2009-07 post-Frankfurt:
]</i></p>


<blockquote>
<p>
Change "constructed" to "initialized" in two places in the proposed resolution.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready for this meeting.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change  [reverse.iter.con]:
</p>

<blockquote><pre>reverse_iterator();
</pre>
<blockquote>
-1- <i>Effects:</i> <del>Default</del> <ins>Value</ins> initializes <tt>current</tt>. Iterator
operations applied to the resulting iterator have defined behavior if and
only if the corresponding operations are defined on a <del>default constructed</del>
<ins>value initialized</ins>
iterator of type <tt>Iterator</tt>.
</blockquote>
</blockquote>

<p>
Change 24.5.3.3.1 [move.iter.op.const]:
</p>

<blockquote><pre>move_iterator();
</pre>
<blockquote>
-1- <i>Effects:</i> Constructs a <tt>move_iterator</tt>, <del>default</del> <ins>value</ins>
initializing <tt>current</tt>.
<ins>Iterator
operations applied to the resulting iterator have defined behavior if and
only if the corresponding operations are defined on a
value initialized
iterator of type <tt>Iterator</tt>.</ins>
</blockquote>
</blockquote>






<hr>
<h3><a name="1014"></a>1014. Response to UK 317 and JP 74</h3>
<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 317 and JP 74</b></p>

<p>
UK 317:
</p>

<blockquote>
<tt>basic_string</tt> has both a constructor and an assignment operator that
accepts an initializer list, <tt>basic_regex</tt> should have the same.
</blockquote>

<p>
JP 74:
</p>

<blockquote>
<tt>basic_regx &amp; operator= (initializer_list&lt;T&gt;);</tt> is not defined.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
UK 317 asks for both assignment and constructor,
but the requested constructor is already present in the current Working Paper.
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 28.8 [re.regex]:
</p>

<blockquote><pre>template &lt;class charT,
          class traits = regex_traits&lt;charT&gt; &gt;
class basic_regex {
  ...
  basic_regex&amp; operator=(const charT* ptr);
  <ins>basic_regex&amp; operator=(initializer_list&lt;charT&gt; il);</ins>
  template &lt;class ST, class SA&gt;
    basic_regex&amp; operator=(const basic_string&lt;charT, ST, SA&gt;&amp; p);
  ...
};
</pre></blockquote>

<p>
Add in  28.8.2 [re.regex.construct]:
</p>

<blockquote>
<blockquote>
-20- ...
</blockquote>
<pre>basic_regex&amp; operator=(initializer_list&lt;charT&gt; il);
</pre>
<blockquote>
-21- <i>Effects:</i> returns <tt>assign(il.begin(), il.end());</tt>
</blockquote>
</blockquote>






<hr>
<h3><a name="1019"></a>1019. Response to UK 205</h3>
<p><b>Section:</b> 20.7.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 205</b></p>

<p>
<tt>integral_constant</tt> objects should be usable in integral-constant-expressions.
The addition to the language of literal types and the enhanced rules for
constant expressions make this possible.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree that the <tt>static</tt> data member
ought be declared <tt>constexpr</tt>,
but do not see a need for the proposed <tt>operator value_type()</tt>.
(A use case would be helpful.)
Move to Open.
</blockquote>

<p><i>[
2009-05-23 Alisdair adds:
]</i></p>


<blockquote>
<p>
The motivating case in my mind is that we can then use
<tt>true_type</tt> and <tt>false_type</tt> as integral Boolean expressions, for example inside
a <tt>static_assert</tt> declaration.  In that sense it is purely a matter of style.
</p>
<p>
Note that Boost has applied the non-explicit conversion operator for many
years as it has valuable properties for extension into other metaprogramming
libraries, such as MPL.  If additional rationale is desired I will poll the
Boost lists for why this extension was originally applied.  I would argue
that explicit conversion is more appropriate for 0x though.
</p>
</blockquote>

<p><i>[
2009-07-04 Howard adds:
]</i></p>


<blockquote>
<p>
Here's a use case which demonstrates the syntactic niceness which Alisdair describes:
</p>

<blockquote><pre>#define requires(...) class = typename std::enable_if&lt;(__VA_ARGS__)&gt;::type

template &lt;class T, class U,
    requires(!is_lvalue_reference&lt;T&gt;() ||
              is_lvalue_reference&lt;T&gt;() &amp;&amp; is_lvalue_reference&lt;U&gt;()),
    requires(is_same&lt;typename base_type&lt;T&gt;::type,
                     typename base_type&lt;U&gt;::type&gt;)&gt;
inline
T&amp;&amp;
forward(U&amp;&amp; t)
{
    return static_cast&lt;T&amp;&amp;&gt;(t);
}
</pre></blockquote>
</blockquote>

<p><i>[
2009-07 post-Frankfurt:
]</i></p>


<blockquote>
Move to Tentatively Ready.
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready for this meeting.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add to the <tt>integral_constant</tt> struct definition in 20.7.3 [meta.help]:
</p>

<blockquote><pre>template &lt;class T, T v&gt;
struct integral_constant {
  static const<ins>expr</ins> T value = v;
  typedef T value_type;
  typedef integral_constant&lt;T,v&gt; type;
  <ins>constexpr operator value_type() { return value; }</ins>
};
</pre></blockquote>





<hr>
<h3><a name="1021"></a>1021. Response to UK 211</h3>
<p><b>Section:</b> 20.9.9.2.3 [unique.ptr.single.asgn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 211</b></p>

<p>
The <tt>nullptr_t</tt> type was introduced to resolve the null pointer literal
problem. It should be used for the assignemnt operator, as with the
constructor and elsewhere through the library.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis in 20.9.9.2 [unique.ptr.single]:
</p>

<blockquote><pre>unique_ptr&amp; operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
</pre></blockquote>

<p>
Change 20.9.9.2.3 [unique.ptr.single.asgn]:
</p>

<blockquote><pre>unique_ptr&amp; operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
</pre>
<blockquote>
<del>Assigns from the literal 0 or <tt>NULL</tt>. [<i>Note:</i> The
<i>unspecified-pointer-type</i> is often implemented as a pointer to a
private data member, avoiding many of the implicit conversion pitfalls.
<i>-- end note</i>]</del>
</blockquote>
</blockquote>





<hr>
<h3><a name="1030"></a>1030. Response to JP 44</h3>
<p><b>Section:</b> 20.9.10.5 [util.smartptr.shared.atomic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses JP 44</b></p>

<p>
The 1st parameter <tt>p</tt> and 2nd parameter <tt>v</tt> is now
<tt>shared_ptr&lt;T&gt;*</tt>.
</p>
<p>
It should be <tt>shared_ptr&lt;T&gt;&amp;</tt>, or if these are
<tt>shared_ptr&lt;T&gt;*</tt> then add the "<tt>p</tt> shall not be a
null pointer" at the requires.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree. All of the functions need a requirement that <tt>p</tt> (or
<tt>v</tt>) is a pointer to a valid object.
</blockquote>

<p><i>[
2009-07 post-Frankfurt:
]</i></p>


<blockquote>
<p>
Lawrence explained that these signatures match the regular atomics. The
regular atomics must not use references because these signatures are
shared with C. The decision to pass shared_ptrs by pointer rather than
by reference was deliberate and was motivated by the principle of least
surprise.
</p>
<p>
Lawrence to write wording that requires that the pointers not be null.
</p>
</blockquote>

<p><i>[
2009-09-20 Lawrence provided wording:
]</i></p>


<blockquote>
<p>
The parameter types for atomic shared pointer access
were deliberately chosen to be pointers
to match the corresponding parameters of the atomics chapter.
Those in turn were deliberately chosen
to match C functions,
which do not have reference parameters.
</p>
<p>
We adopt the second suggestion,
to require that such pointers not be null.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In section "<code>shared_ptr</code> atomic access"
20.9.10.5 [util.smartptr.shared.atomic], add to each function the
following clause.
</p>
<blockquote><p>
<i>Requires:</i> <code>p</code> shall not be null.
</p></blockquote>





<hr>
<h3><a name="1033"></a>1033. <tt>thread::join()</tt> effects?</h3>
<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>
While looking at <tt>thread::join()</tt> I think I spotted a couple of
possible defects in the specifications. I could not find a previous
issue or NB comment about that, but I might have missed it.
</p>

<p>
The postconditions clause for <tt>thread::join()</tt> is:
</p>

<blockquote>
<i>Postconditions:</i> If <tt>join()</tt> throws an exception, the value
returned by <tt>get_id()</tt> is unchanged. Otherwise, <tt>get_id() == id()</tt>.
</blockquote>

<p>
and the throws clause is:
</p>

<blockquote>
<i>Throws:</i> <tt>std::system_error</tt> when the postconditions cannot be achieved.
</blockquote>

<p>
Now... how could the postconditions <em>not</em> be achieved?
It's just a matter of resetting the value of <tt>get_id()</tt> or leave it
unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg
problem: in order to decide whether to throw or not I depend on the
postconditions, but the postconditions are different in the two cases.
</p>

<p>
I believe the throws clause should be:
</p>

<blockquote>
<i>Throws:</i> <tt>std::system_error</tt> when the effects or postconditions
cannot be achieved.
</blockquote>

<p>
as it is in <tt>detach()</tt>, or, even better, as the postcondition is
trivially satisfiable and to remove the circular dependency:
</p>


<blockquote>
<i>Throws:</i> <tt>std::system_error</tt> if the effects cannot be achieved.
</blockquote>

<p>
Problem is that... ehm... <tt>join()</tt> has no "Effects" clause. Is that intentional?
</p>

<p><i>[
See the thread starting at c++std-lib-23204 for more discussion.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Pete believes there may be some more general language (in frontmatter)
that can address this and related issues such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#962">962</a>.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-11-18 Anthony provides wording.
]</i></p>



<p><i>[
2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><b>Proposed resolution:</b></p>
<p>
Edit 30.3.1.5 [thread.thread.member] as indicated:
</p>

<blockquote><pre>void join();
</pre>
<blockquote>
<p>
5 <i>Precondition:</i> <tt>joinable()</tt> is <tt>true</tt>.
</p>
<p><ins>
<i>Effects:</i> Blocks until the thread represented by <tt>*this</tt> has completed.
</ins></p>

<p>
6 <i>Synchronization:</i> The completion of the thread represented by
<tt>*this</tt> happens before (1.10 [intro.multithread])
<tt>join()</tt> returns. [<i>Note:</i> Operations on <tt>*this</tt> are not
synchronized. � <i>end note</i>]
</p>

<p>
7 <i>Postconditions:</i> <del>If <tt>join()</tt> throws an exception, the value
returned by <tt>get_id()</tt> is unchanged. Otherwise,</del> <ins>The thread
represented by <tt>*this</tt> has completed.</ins> <tt>get_id() == id()</tt>.
</p>

<p>
8 ...
</p>


</blockquote>
</blockquote>






<hr>
<h3><a name="1034"></a>1034. Response to UK 222</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 222</b></p>

<p>
It is not clear what purpose the Requirement tables serve in the
Containers clause. Are they the definition of a library Container? Or
simply a conventient shorthand to factor common semantics into a single
place, simplifying the description of each subsequent container? This
becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
support the size operation. Are these components no longer containers?
Does that mean the remaining requirements don't apply? Or are these
contradictions that need fixing, despite being a clear design decision?
</p>

<p>
Recommend:
</p>

<p>
Clarify all the tables in 23.2 [container.requirements] are
there as a convenience for documentation, rather than a strict set of
requirements. Containers should be allowed to relax specific
requirements if they call attention to them in their documentation. The
introductory text for <tt>array</tt> should be expanded to mention a
default constructed <tt>array</tt> is not empty, and
<tt>forward_list</tt> introduction should mention it does not provide
the required <tt>size</tt> operation as it cannot be implemented
efficiently.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree in principle.
</blockquote>

<p><i>[
2009-07 post-Frankfurt:
]</i></p>


<blockquote>
We agree in principle, but we have a timetable. This group feels that
the issue should be closed as NAD unless a proposed resolution is
submitted prior to the March 2010 meeting.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Looked at this and still intend to close as NAD in March
2010 unless there is proposed wording that we like.
</blockquote>

<p><i>[
2010-02-02 Nicolai M. Josuttis updates proposed wording and adds:
]</i></p>


<blockquote>
<p>
I just came across issue #1034 (response to UK 222),
which covers the role of container requirements.
The reason I found this issue was that I am wondering why
<tt>array&lt;&gt;</tt> is specified to be a sequence container.
For me, currently, this follows from
Sequence containers 23.2.3 [sequence.reqmts]
saying:
</p>
<blockquote>
The library provides five basic kinds of sequence containers: <tt>array</tt>,
<tt>vector</tt>, <tt>forward_list</tt>, <tt>list</tt>, and <tt>deque</tt>. while
later on in Table 94 "Sequence container requirements" are defined.
</blockquote>

<p>
IMO, you can hardly argue that this is NAD.
We MUST say somewhere that either array is not a sequence container
or does not provide all operations of a sequence container
(even not all requirements of a container in general).
</p>
<p>
Here is the number of requirements <tt>array&lt;&gt;</tt> does not meet
(AFAIK):
</p>
<p>
general container requirements:
</p>
<ul>
<li>
a default constructed <tt>array</tt> is not empty
</li>
<li>
<tt>swap</tt> has no constant complexity
</li>
</ul>

<p>
 Note also that <tt>swap</tt> not only has linear complexity
 it also invalidates iterators (or to be more precise,
 assigns other values to the elements), which
 is different from the effect swap has for other containers.
 For this reason, I must say that i tend to propose to
 remove <tt>swap()</tt> for <tt>arrays</tt>.
 </p>

<p>
sequence container requirements:
</p>

<ul>
<li>
There is no constructor and assignment for a range
</li>
<li>
There is no constructor and assignment for <tt>n</tt> copies of <tt>t</tt>
</li>
<li>
 There are no <tt>emplace</tt>, <tt>insert</tt>, <tt>erase</tt>, <tt>clear</tt>,
 <tt>assign</tt> operations
</li>
</ul>

<p>
In fact, out of all sequence container requirements <tt>array&lt;&gt;</tt> only
provides the following operations:
from sequence requirements (Table 94):
</p>
<blockquote><pre>X(il);
a = il;
</pre></blockquote>
<p>
and from optional requirements (Table 95):
</p>
<blockquote><pre>[], at(), front(), back()
</pre></blockquote>
<p>
This is almost nothing!
</p>

<p>
Note in addition, that due to the fact that
<tt>array</tt> is an aggregate and not a container with
<tt>initializer_lists</tt>
a construction or assignment with an initializer list is valid
for all sequence containers but not valid for array:
</p>

<blockquote><pre>vector&lt;int&gt;  v({1,2,3});   // OK
v = {4,5,6};               // OK

array&lt;int,3&gt; a({1,2,3});   // Error
array&lt;int,3&gt; a = {1,2,3};  // OK
a = {4,5,6};               // Error
</pre></blockquote>

<p>
BTW, for this reason, I am wondering, why <tt>&lt;array&gt;</tt> includes
<tt>&lt;initializer_list&gt;</tt>.
</p>

<p>
IMO, we can't really say that <tt>array</tt> is a sequence container.
<tt>array</tt> is special.
As the solution to this issue seemed to miss some proposed wording
where all could live with, let me try to suggest some.
</p>

</blockquote>

<p><i>[
2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010 Pittsburgh:  Ok with move to Ready except for "OPEN:" part.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>In Sequence containers 23.2.3 [sequence.reqmts] modify paragraph 1 as 
indicated: </i> </p>
<blockquote>
  <p>1 A sequence container organizes a finite set of objects, all of the same 
  type, into a strictly linear arrangement. The library provides <del>five</del>
  <ins>four</ins> basic kinds of sequence containers: <del><tt>array</tt>,</del>
  <tt>vector</tt>, <tt>forward_list</tt>, <tt>list</tt>, and <tt>deque</tt>.
  <ins>In addition, <tt>array</tt> is provided as a sequence container that 
  only provides limited sequence operations because it has a fixed number of 
  elements.</ins> <del>It</del> <ins>The library</ins> also provides container adaptors that make it easy to 
  construct abstract data types, such as <tt>stack</tt>s or <tt>queue</tt>s, out 
  of the basic sequence container kinds (or out of other kinds of sequence 
  containers that the user might define). </p>
</blockquote>
<p><i>Modify paragraph 2 as follows (just editorial): </i> </p>
<blockquote>
  <p>2 The <del>five basic</del> sequence 
  containers offer the programmer different complexity trade-offs and should be 
  used accordingly. <tt>vector</tt> or <tt>array</tt> is the type of sequence 
  container that should be used by default. <tt>list</tt> or <tt>forward_list</tt> 
  should be used when there are frequent insertions and deletions from the 
  middle of the sequence. <tt>deque</tt> is the data structure of choice when 
  most insertions and deletions take place at the beginning or at the end of the 
  sequence. </p>
</blockquote>
<p><i>In Class template array 23.3.1 [array] modify paragraph 3 as indicated:
</i> </p>
<blockquote>
  <p>3 <del>Unless otherwise specified, all <tt>array</tt> operations are as 
  described in 23.2.</del> <ins>An array satisfies all of the requirements of a 
  container and of a reversible container (given in two tables in 23.2 [container.requirements]) 
  except that a default constructed <tt>array</tt> is not empty, <tt>swap</tt> 
  does not have constant complexity, and <tt>swap</tt> may throw exceptions. An <tt>array</tt> satisfies some of the requirements of a 
  sequence container (given in 23.2.3 [sequence.reqmts]).</ins> Descriptions are 
  provided here only for operations on <tt>array</tt> that are not described
  <del>in that Clause</del> <ins>in one of these tables</ins> or for operations 
  where there is additional semantic information. </p>
</blockquote>
<p><i>In array specialized algorithms 23.3.1.2 [array.special] add to the 
specification of <tt>swap()</tt>: </i> </p>
<blockquote>
  <pre>template &lt;class T, size_t N&gt; void swap(array&lt;T,N&gt;&amp; x, array&lt;T,N&gt;&amp; y);
</pre>
  <blockquote>
    <p>1 <i>Effects:</i> ... </p>
    <p><ins><i>Complexity:</i> Linear in <tt>N</tt>. </ins></p>
  </blockquote>
</blockquote>









<hr>
<h3><a name="1037"></a>1037. Response to UK 232</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 232</b></p>

<p>
<tt>match_results</tt> may follow the requirements but is not listed a general
purpose library container.
</p>

<p>
Remove reference to <tt>match_results</tt> against <tt>a[n]</tt> operation.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree. <tt>operator[]</tt> is defined elsewhere.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 23.2.3 [sequence.reqmts] Table 84, remove reference to
<tt>match_results</tt> in the row describing the <tt>a[n]</tt> operation.
</p>





<hr>
<h3><a name="1038"></a>1038. Response to UK 233</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 233</b></p>

<p>
Table 84 is missing references to several new container types.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 23.2.3 [sequence.reqmts] Table 84, Add reference to listed
containers to the following rows:
</p>

<blockquote>
<table border="1">
<caption>Table 84 -- Optional sequence container operations</caption>
<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Container</th>
</tr>
<tr>
<td><tt>a.front()</tt></td>
<td>...</td>
<td>...</td>
<td><tt>vector, list, deque, basic_string<ins>, array, forward_list</ins></tt></td>
</tr>
<tr>
<td><tt>a.back()</tt></td>
<td>...</td>
<td>...</td>
<td><tt>vector, list, deque, basic_string<ins>, array</ins></tt></td>
</tr>
<tr>
<td><tt>a.emplace_front(args)</tt></td>
<td>...</td>
<td>...</td>
<td><tt>list, deque<ins>, forward_list</ins></tt></td>
</tr>
<tr>
<td><tt>a.push_front(t)</tt></td>
<td>...</td>
<td>...</td>
<td><tt>list, deque<ins>, forward_list</ins></tt></td>
</tr>
<tr>
<td><tt>a.push_front(rv)</tt></td>
<td>...</td>
<td>...</td>
<td><tt>list, deque<ins>, forward_list</ins></tt></td>
</tr>
<tr>
<td><tt>a.pop_front()</tt></td>
<td>...</td>
<td>...</td>
<td><tt>list, deque<ins>, forward_list</ins></tt></td>
</tr>
<tr>
<td><tt>a[n]</tt></td>
<td>...</td>
<td>...</td>
<td><tt>vector, deque, basic_string<ins>, array</ins></tt></td>
</tr>
<tr>
<td><tt>a.at(n)</tt></td>
<td>...</td>
<td>...</td>
<td><tt>vector, deque<ins>, basic_string, array</ins></tt></td>
</tr>
</tbody></table>
</blockquote>





<hr>
<h3><a name="1039"></a>1039. Response to UK 234</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 234</b></p>

<p>
The reference to <tt>iterator</tt> in semantics for <tt>back</tt> should
also allow for <tt>const_iterator</tt> when called on a const-qualified
container. This would be ugly to specify in the 03 standard, but is
quite easy with the addition of <tt>auto</tt> in this new standard.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 23.2.3 [sequence.reqmts] Table 84, replace iterator with auto in semantics for back:
</p>

<blockquote>
<table border="1">
<caption>Table 84 -- Optional sequence container operations</caption>
<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Container</th>
</tr>
<tr>
<td><tt>a.back()</tt></td>
<td><tt>reference; const_reference</tt> for constant <tt>a</tt></td>
<td><tt>{ <del>iterator</del> <ins>auto</ins> tmp = a.end();<br>--tmp;<br>return *tmp; }</tt></td>
<td><tt>vector, list, deque, basic_string</tt></td>
</tr>
</tbody></table>
</blockquote>





<hr>
<h3><a name="1040"></a>1040. Response to UK 238</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 238</b></p>

<p>
Leaving it unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> are the
same type is dangerous, as user code may or may not violate the One
Definition Rule by providing overloads for 
both types. It is probably too late to specify a single behaviour, but
implementors should document what to expect. Observing that problems can be
avoided by users restricting themselves to using <tt>const_iterator</tt>, add a note to that effect. 
</p>
<p>
Suggest Change 'unspecified' to 'implementation defined'.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree with issue. Agree with adding the note but not with changing the
normative text. We believe the note provides sufficient guidance.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 23.2.4 [associative.reqmts] p6, add:
</p>

<blockquote>
-6- <tt>iterator</tt> of an associative container meets the requirements
of the <tt>BidirectionalIterator</tt> concept. For associative
containers where the value type is the same as the key type, both
<tt>iterator</tt> and <tt>const_iterator</tt> are constant iterators. It
is unspecified whether or not <tt>iterator</tt> and
<tt>const_iterator</tt> are the same type.
<ins>[<i>Note:</i> <tt>iterator</tt> and <tt>const_iterator</tt> have identical semantics in
this case, and <tt>iterator</tt> is convertible to <tt>const_iterator</tt>. Users can avoid
violating the One Definition Rule by always using <tt>const_iterator</tt>
in their function parameter lists <i>-- end note</i>]</ins>
</blockquote>





<hr>
<h3><a name="1044"></a>1044. Response to UK 325</h3>
<p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex">issues</a> in [thread.mutex].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 325</b></p>

<p>
We believe constexpr literal values should be a more natural expression
of empty tag types than extern objects as it should improve the
compiler's ability to optimize the empty object away completely.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Move to review. The current specification is a "hack", and the proposed
specification is a better "hack".
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis in 30.4 [thread.mutex]:
</p>

<blockquote><pre>struct defer_lock_t <ins>{}</ins>;
struct try_to_lock_t <ins>{}</ins>;
struct adopt_lock_t <ins>{}</ins>;

<del>extern</del> const<ins>expr</ins> defer_lock_t defer_lock <ins>{}</ins>;
<del>extern</del> const<ins>expr</ins> try_to_lock_t try_to_lock <ins>{}</ins>;
<del>extern</del> const<ins>expr</ins> adopt_lock_t adopt_lock <ins>{}</ins>;
</pre></blockquote>






<hr>
<h3><a name="1045"></a>1045. Response to UK 326</h3>
<p><b>Section:</b> 30.4.2.2.1 [thread.lock.unique.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 326</b></p>

<p>
The precondition that the mutex is not owned by this thread offers
introduces the risk of un-necessary undefined behaviour into the
program. The only time it matters whether the current thread owns the
mutex is in the lock operation, and that will happen subsequent to
construction in this case. The lock operation has the identical
pre-condition, so there is nothing gained by asserting that precondition
earlier and denying the program the right to get into a valid state
before calling lock.
</p>

<p><i>[
Summit:
]</i></p>


<blockquote>
Agree, move to review.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Strike 30.4.2.2.1 [thread.lock.unique.cons] p7:
</p>

<blockquote><pre>unique_lock(mutex_type&amp; m, defer_lock_t);
</pre>
<blockquote>
<del>-7- <i>Precondition:</i> If <tt>mutex_type</tt> is not a recursive mutex
the calling thread does not own the mutex.</del>
</blockquote>
</blockquote>






<hr>
<h3><a name="1054"></a>1054. <tt>forward</tt> broken</h3>
<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>

<p>
This is a placeholder issue to track the fact that we (well I) put the standard
into an inconsistent state by requesting that we accept
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
except for the proposed changes to [forward].
</p>

<p>
There will exist in the post meeting mailing
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2835.html">N2835</a>
which in its current state reflects the state of affairs prior to the Summit
meeting.  I hope to update it in time for the post Summit mailing, but as I write
this issue I have not done so yet.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Move to Open, awaiting the promised paper.
</blockquote>

<p><i>[
2009-08-02 Howard adds:
]</i></p>


<blockquote>
<p>
My current preferred solution is:
</p>

<blockquote><pre>template &lt;class T&gt;
struct __base_type
{
   typedef typename remove_cv&lt;typename remove_reference&lt;T&gt;::type&gt;::type type;
};

template &lt;class T, class U,
   class = typename enable_if&lt;
       !is_lvalue_reference&lt;T&gt;::value ||
        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
        is_lvalue_reference&lt;U&gt;::value&gt;::type,
   class = typename enable_if&lt;
        is_same&lt;typename __base_type&lt;T&gt;::type,
                typename __base_type&lt;U&gt;::type&gt;::value&gt;::type&gt;
inline
T&amp;&amp;
forward(U&amp;&amp; t)
{
   return static_cast&lt;T&amp;&amp;&gt;(t);
}
</pre></blockquote>

<p>
This has been tested by Bill, Jason and myself.
</p>

<p>
It allows the following lvalue/rvalue casts:
</p>

<ol>
<li>
Cast an lvalue <tt>t</tt> to an lvalue <tt>T</tt> (identity).
</li>
<li>
Cast an lvalue <tt>t</tt> to an rvalue <tt>T</tt>.
</li>
<li>
Cast an rvalue <tt>t</tt> to an rvalue <tt>T</tt> (identity).
</li>
</ol>

<p>
It disallows:
</p>

<ol type="a">
<li>
Cast an rvalue <tt>t</tt> to an lvalue <tt>T</tt>.
</li>
<li>
Cast one type <tt>t</tt> to another type <tt>T</tt> (such as <tt>int</tt> to <tt>double</tt>).
</li>
</ol>

<p>
"a." is disallowed as it can easily lead to dangling references.
"b." is disallowed as this function is meant to only change the lvalue/rvalue
characteristic of an expression.
</p>

<p>
Jason has expressed concern that "b." is not dangerous and is useful in contexts
where you want to "forward" a derived type as a base type.  I find this use case
neither dangerous, nor compelling.  I.e. I could live with or without the "b."
constraint.  Without it, forward would look like:
</p>

<blockquote><pre>template &lt;class T, class U,
   class = typename enable_if&lt;
       !is_lvalue_reference&lt;T&gt;::value ||
        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
        is_lvalue_reference&lt;U&gt;::value&gt;::type&gt;
inline
T&amp;&amp;
forward(U&amp;&amp; t)
{
   return static_cast&lt;T&amp;&amp;&gt;(t);
}
</pre></blockquote>

<p>
Or possibly:
</p>

<blockquote><pre>template &lt;class T, class U,
   class = typename enable_if&lt;
       !is_lvalue_reference&lt;T&gt;::value ||
        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
        is_lvalue_reference&lt;U&gt;::value&gt;::type,
   class = typename enable_if&lt;
        is_base_of&lt;typename __base_type&lt;U&gt;::type,
                   typename __base_type&lt;T&gt;::type&gt;::value&gt;::type&gt;
inline
T&amp;&amp;
forward(U&amp;&amp; t)
{
   return static_cast&lt;T&amp;&amp;&gt;(t);
}
</pre></blockquote>


<p>
The "promised paper" is not in the post-Frankfurt mailing only because I'm waiting
for the non-concepts draft.  But I'm hoping that by adding this information here
I can keep people up to date.
</p>
</blockquote>

<p><i>[
2009-08-02 David adds:
]</i></p>


<blockquote>
<p>
<tt>forward</tt> was originally designed to do one thing: perfect forwarding.
That is, inside a function template whose actual argument can be a const
or non-const lvalue or rvalue, restore the original "rvalue-ness" of the
actual argument:
</p>

<blockquote><pre>template &lt;class T&gt;
void f(T&amp;&amp; x)
{
    // x is an lvalue here.  If the actual argument to f was an
    // rvalue, pass static_cast&lt;T&amp;&amp;&gt;(x) to g; otherwise, pass x.
    g( forward&lt;T&gt;(x) );
}
</pre></blockquote>

<p>
Attempting to engineer <tt>forward</tt> to accomodate uses other than perfect
forwarding dilutes its idiomatic meaning.  The solution proposed here
declares that <tt>forward&lt;T&gt;(x)</tt> means nothing more than <tt>static_cast&lt;T&amp;&amp;&gt;(x)</tt>,
with a patchwork of restrictions on what <tt>T</tt> and <tt>x</tt> can be that can't be
expressed in simple English.
</p>

<p>
I would be happy with either of two approaches, whose code I hope (but
can't guarantee) I got right.
</p>

<ol>
<li>
<p>
Use a simple definition of <tt>forward</tt> that accomplishes its original
purpose without complications to accomodate other uses:
</p>

<blockquote><pre>template &lt;class T, class U&gt;
T&amp;&amp; forward(U&amp; x)
{
    return static_cast&lt;T&amp;&amp;&gt;(x);
}
</pre></blockquote>
</li>

<li>
<p>
Use a definition of <tt>forward</tt> that protects the user from as many
potential mistakes as possible, by actively preventing <em>all</em> other
uses:
</p>

<blockquote><pre>template &lt;class T, class U&gt;
boost::enable_if_c&lt;
    // in forward&lt;T&gt;(x), x is a parameter of the caller, thus an lvalue
    is_lvalue_reference&lt;U&gt;::value
    // in caller's deduced T&amp;&amp; argument, T can only be non-ref or lvalue ref
    &amp;&amp; !is_rvalue_reference&lt;T&gt;::value
    // Must not cast cv-qualifications or do any type conversions
    &amp;&amp; is_same&lt;T&amp;,U&amp;&gt;::value
    , T&amp;&amp;&gt;::type forward(U&amp;&amp; a)
{
    return static_cast&lt;T&amp;&amp;&gt;(a);
}
</pre></blockquote>
</li>
</ol>

</blockquote>

<p><i>[
2009-09-27 Howard adds:
]</i></p>


<blockquote>
A paper,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a>,
is available which compares several implementations (including David's) with respect to several
use cases (including Jason's) and provides wording for one implementation.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="1055"></a>1055. Response to UK 98</h3>
<p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 98</b></p>

<p>
It would be useful to be able to determine the underlying
type of an arbitrary enumeration type. This would allow
safe casting to an integral type (especially needed for
scoped enums, which do not promote), and would allow
use of <tt>numeric_limits</tt>. In general it makes generic
programming with enumerations easier.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Pete observes (and Tom concurs)
that the proposed resolution seems to require compiler support
for its implementation,
as it seems necessary to look at the range of values
of the enumerated type.
To a first approximation,
a library solution could give an answer based on the size of the type.
If the user has specialized <tt>numeric_limits</tt> for the enumerated type,
then the library might be able to do better,
but there is no such requirement.
Keep status as Open
and solicit input from CWG.
</blockquote>

<p><i>[
2009-05-23 Alisdair adds:
]</i></p>


<blockquote>
Just to confirm that the BSI originator of this comment assumed it did
indeed imply a compiler intrinsic.  Rather than request a Core extension, it
seemed in keeping with that the type traits interface provides a library API
to unspecified compiler features - where we require several other traits
(e.g. <tt>has_trivial_*</tt>) to get the 'right' answer now, unlike in TR1.
</blockquote>

<p><i>[
Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add a new row to the table in 20.7.7.6 [meta.trans.other]:
</p>

<blockquote>
<table border="1">
<caption>Table 41 -- Other transformations</caption>
<tbody><tr>
<th>Template</th>
<th>Condition</th>
<th>Comments</th>
</tr>
<tr>
<td>
<tt>template&lt;&nbsp;class&nbsp;T&nbsp;&gt; struct enum_base;</tt>
</td>
<td>
<tt>T</tt> shall be an enumeration type (7.2 [dcl.enum])
</td>
<td>
The member typedef <tt>type</tt> shall name the underlying type
of the enum <tt>T</tt>.
</td>
</tr>
</tbody></table>
</blockquote>





<hr>
<h3><a name="1065"></a>1065. Response to UK 168</h3>
<p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 168</b></p>
<p>
We should make it clear (either by note or normatively) that namespace
<tt>std</tt> may contain inline namespaces, and that entities specified to be
defined in std may in fact be defined in one of these inline namespaces.
(If we're going to use them for versioning, eg when TR2 comes along,
we're going to need that.)
</p>

<p>
Replace "namespace std or namespaces nested within namespace std" with
"namespace std or namespaces nested within namespace std or inline
namespaces nested directly or indirectly within namespace std"
</p>

<p><i>[
Summit:
]</i></p>

<blockquote>
adopt UK words (some have reservations whether it is correct)
</blockquote>

<p><i>[
2009-05-09 Alisdair improves the wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Bill believes there is strictly speaking no need to say that
because no portable test can detect the difference.
However he agrees that it doesn't hurt to say this.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 17.6.1.1 [contents] p2:
</p>

<blockquote>
All library entities except macros, <tt>operator new</tt> and
<tt>operator delete</tt> are defined within the namespace <tt>std</tt> or
namespaces nested within namespace <tt>std</tt>.
<ins>It is unspecified whether names declared in a specific namespace
are declared directly in that namespace, or in an inline namespace inside
that namespace. [<i>Footnote:</i> This gives implementers freedom to support
multiple configurations of the library.]</ins>
</blockquote>





<hr>
<h3><a name="1066"></a>1066. Response to UK 189 and JP 27</h3>
<p><b>Section:</b> 18 [language.support] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 189 and JP 27</b></p>
<p>
The addition of the <tt>[[noreturn]]</tt> attribute to the language will be an
important aid for static analysis tools.
</p>

<p>
The following functions should be declared in C++ with the
<tt>[[noreturn]]</tt> attribute: <tt>abort</tt> <tt>exit</tt>
<tt>quick_exit</tt> <tt>terminate</tt> <tt>unexpected</tt>
<tt>rethrow_exception</tt> <tt>throw_with_nested</tt>.
</p>

<p><i>[
Summit:
]</i></p>

<blockquote>
Agreed.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 18.5 [support.start.term] p3:
</p>

<blockquote>
<p>-2- ...</p>
<pre><ins>void</ins> abort <ins>[[noreturn]]</ins> (void)
</pre>
<p>-3- ...</p>
<p>-6- ...</p>
<pre><ins>void</ins> exit<ins> [[noreturn]] </ins>(int status)
</pre>
<p>-7- ...</p>
<p>-11- ...</p>
<pre>void quick_exit<ins> [[noreturn]] </ins>(int status)
</pre>
<p>-12- ...</p>
</blockquote>

<p>
Change the <tt>&lt;exception&gt;</tt> synopsis in 18.8 [support.exception]:
</p>

<blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
...
void terminate<ins> [[noreturn]] </ins>();
...
void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
...
template &lt;class T&gt; void throw_with_nested<ins> [[noreturn]] </ins>(T&amp;&amp; t); <del>// [[noreturn]]</del>
</pre></blockquote>

<p>
Change D.13.3 [unexpected]:
</p>

<blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
</pre></blockquote>

<p>
Change 18.8.3.3 [terminate]:
</p>

<blockquote><pre>void terminate<ins> [[noreturn]] </ins>();
</pre></blockquote>

<p>
Change 18.8.5 [propagation]:
</p>

<blockquote><pre>void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
</pre></blockquote>

<p>
In the synopsis of 18.8.6 [except.nested] and the definition area change:
</p>

<blockquote><pre>template &lt;class T&gt; void throw_with_nested<ins> [[noreturn]] </ins>(T&amp;&amp; t); <del>// [[noreturn]]</del>
</pre></blockquote>





<hr>
<h3><a name="1070"></a>1070. Ambiguous move overloads in function</h3>
<p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The synopsis in 20.8.14.2 [func.wrap.func] says:
</p>

<blockquote><pre>template&lt;Returnable R, CopyConstructible... ArgTypes&gt; 
class function&lt;R(ArgTypes...)&gt;
{
    ...
    template&lt;class F&gt; 
      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
      function(F); 
    template&lt;class F&gt; 
      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
      function(F&amp;&amp;);
    ...
    template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F); 
    template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F&amp;&amp;);
    ...
    template&lt;class F&gt; 
      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes..&gt; 
            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type 
      function&amp; operator=(F); 
    template&lt;class F&gt; 
      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
      function&amp; operator=(F&amp;&amp;);
    ...
};
</pre></blockquote>

<p>
Each of the 3 pairs above are ambiguous.  We need only one of each pair, and we
could do it with either one.  If we choose the <tt>F&amp;&amp;</tt> version we
need to bring <tt>decay</tt> into the definition to get the pass-by-value behavior.
In the proposed wording I've gotten lazy and just used the pass-by-value signature.
</p>

<p><i>[
2009-05-01 Daniel adds:
]</i></p>


<blockquote>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a> modifies the second removed constructor.
</blockquote>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We briefly discussed whether we ought support moveable function objects,
but decided that should be a separate issue if someone cares to propose it.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change the synopsis of 20.8.14.2 [func.wrap.func], and remove the associated definitions in
20.8.14.2.1 [func.wrap.func.con]:
</p>

<blockquote><pre>template&lt;Returnable R, CopyConstructible... ArgTypes&gt; 
class function&lt;R(ArgTypes...)&gt;
{
    ...
    template&lt;class F&gt; 
      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
      function(F); 
    <del>template&lt;class F&gt; 
      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
      function(F&amp;&amp;);</del>
    ...
    template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F); 
    <del>template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F&amp;&amp;);</del>
    ...
    template&lt;class F&gt; 
      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes..&gt; 
            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type 
      function&amp; operator=(F); 
    <del>template&lt;class F&gt; 
      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
      function&amp; operator=(F&amp;&amp;);</del>
    ...
};
</pre></blockquote>






<hr>
<h3><a name="1071"></a>1071. is_bind_expression should derive from integral_constant&lt;bool&gt;</h3>
<p><b>Section:</b> 20.8.10.1.1 [func.bind.isbind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.isbind">issues</a> in [func.bind.isbind].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Class template is_bind_expression 20.8.10.1.1 [func.bind.isbind]:
</p>

<blockquote><pre>namespace std {
  template&lt;class T&gt; struct is_bind_expression {
    static const bool value = see below;
  };
}
</pre></blockquote>
<p>
<tt>is_bind_expression</tt> should derive from <tt>std::integral_constant&lt;bool&gt;</tt> like
other similar trait types.
</p>

<p><i>[
Daniel adds:
]</i></p>

<blockquote>
We need the same thing for the trait <tt>is_placeholder</tt> as well.
</blockquote>
<p><i>[
2009-03-22 Daniel provided wording.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We recommend this be deferred until after the next Committee Draft is issued.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-05-31 Peter adds:
]</i></p>


<blockquote>
<p>
I am opposed to the proposed resolution and to the premise of the issue
in general. The traits's default definitions should NOT derive from
<tt>integral_constant</tt>, because this is harmful, as it misleads people into
thinking that <tt>is_bind_expression&lt;E&gt;</tt> always derives from
<tt>integral_constant</tt>, whereas it may not.
</p>
<p>
<tt>is_bind_expression</tt> and <tt>is_placeholder</tt> allow user
specializations, and in fact, this is their primary purpose. Such user
specializations may not derive from <tt>integral_constant</tt>, and the
places where <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> are
used intentionally do not require such derivation.
</p>
<p>
The long-term approach here is to switch to
<tt>BindExpression&lt;E&gt;</tt> and <tt>Placeholder&lt;P&gt;</tt>
explicit concepts, of course, but until that happens, I say leave them
alone.
</p>
</blockquote>

<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Tentatively Ready.  We are comfortable with requiring user specializations
to derive from <tt>integral_constant</tt>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
In 20.8.10.1.1 [func.bind.isbind] change as indicated:
</p>
<blockquote><pre>namespace std {
 template&lt;class T&gt; struct is_bind_expression <ins>: integral_constant&lt;bool, <i>see below</i>&gt; { };</ins><del>{
   static const bool value = <i>see below</i>;
 };</del>
}
</pre></blockquote>
</li>
<li>
<p>
In 20.8.10.1.1 [func.bind.isbind]/2 change as indicated:
</p>
<blockquote><pre><del>static const bool value;</del>
</pre>
<blockquote>
-2- <del><tt>true</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>false</tt> otherwise.</del>
  <ins>If <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>is_bind_expression&lt;T&gt;</tt> shall
be publicly derived from
        <tt>integral_constant&lt;bool, true&gt;</tt>, otherwise it shall be
publicly derived from
          <tt>integral_constant&lt;bool, false&gt;</tt>.</ins>
</blockquote>
</blockquote>
</li>
<li>
<p>
In  [func.bind.isplace] change as indicated:
</p>
<blockquote><pre>namespace std {
 template&lt;class T&gt; struct is_placeholder <ins>: integral_constant&lt;int, <i>see below</i>&gt; { };</ins><del>{
   static const int value = <i>see below</i>;
 };</del>
}
</pre></blockquote>
</li>
<li>
<p>
In  [func.bind.isplace]/2 change as indicated:
</p>
<blockquote><pre><del>static const int value;</del>
</pre>
<blockquote>
-2- <del>value is <tt>J</tt> if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, 0 otherwise.</del>
  <ins>If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder&lt;T&gt;</tt>
shall be publicly
          derived from <tt>integral_constant&lt;int, J&gt;</tt> otherwise it shall
be publicly derived
          from <tt>integral_constant&lt;int, 0&gt;</tt>.</ins>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="1073"></a>1073. Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt></h3>
<p><b>Section:</b> 20.9 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt> to ensure constant
initialization.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.  Move to Tentatively Ready.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.9 [memory] p2:
</p>

<blockquote><pre>// 20.8.1, allocator argument tag
struct allocator_arg_t { };
const<ins>expr</ins> allocator_arg_t allocator_arg = allocator_arg_t();
</pre></blockquote>






<hr>
<h3><a name="1075"></a>1075. Response to US 65, US 74.1</h3>
<p><b>Section:</b> 20 [utilities], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US 65 and US 74.1</b></p>

<p>US 65:</p>

<blockquote>
Scoped allocators and allocator propagation traits add a small amount of
utility at the cost of a great deal of machinery. The machinery is user
visible, and it extends to library components that don't have any
obvious connection to allocators, including basic concepts and simple
components like <tt>pair</tt> and <tt>tuple</tt>.

<p>Suggested resolution:</p>

<p>
Sketch of proposed resolution: Eliminate scoped allocators, replace
allocator propagation traits with a simple uniform rule (e.g. always
propagate on copy and move), remove all mention of allocators from
components that don't explicitly allocate memory (e.g. pair), and adjust
container interfaces to reflect this simplification.
</p>
<p>
Components that I propose eliminating include HasAllocatorType,
is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor,
and ConstructibleAsElement.
</p>
</blockquote>

<p>US 74.1:</p>

<blockquote>
<p>
Scoped allocators represent a poor trade-off for standardization, since
(1) scoped-allocator--aware containers can be implemented outside the
C++ standard library but used with its algorithms, (2) scoped
allocators only benefit a tiny proportion of the C++ community
(since few C++ programmers even use today's allocators), and (3) all C++
users, especially the vast majority of the C++ community that won't ever
use scoped allocators are forced to cope with the interface complexity
introduced by scoped allocators.
</p>
<p>
In essence, the larger community will suffer to support a very small
subset of the community who can already implement their own
data structures outside of the standard library. Therefore, scoped
allocators should be removed from the working paper.
</p>
<p>
Some evidence of the complexity introduced by scoped allocators:
</p>
<blockquote>
<p>
20.3.5 [pairs], 20.4 [tuple]: Large increase in the
number of pair and tuple constructors.
</p>
<p>
23 [containers]: Confusing "AllocatableElement" requirements throughout.
</p>
</blockquote>
<p>Suggested resolution:</p>

<p>
Remove support for scoped allocators from the working paper. This
includes at least the following changes:
</p>

<blockquote>
<p>
Remove X [allocator.element.concepts]
</p>
<p>
Remove 20.10 [allocator.adaptor]
</p>
<p>
Remove  [construct.element]
</p>
<p>
In Clause 23 [containers]: replace requirements naming the
<tt>AllocatableElement</tt> concept with requirements naming <tt>CopyConstructible</tt>,
<tt>MoveConstructible</tt>, <tt>DefaultConstructible</tt>, or <tt>Constructible</tt>, as
appropriate.
</p>
</blockquote>

</blockquote>

<p><i>[
Post Summit Alan moved from NAD to Open.
]</i></p>


<p><i>[
2009-05-15 Ganesh adds:
]</i></p>


<blockquote>
<p>
The requirement <tt>AllocatableElement</tt> should not be replaced with
<tt>Constructible</tt> on the <tt>emplace_xxx()</tt> functions as suggested. In the
one-parameter case the <tt>Constructible</tt> requirement is not satisfied when
the constructor is explicit (as per  [concept.map.fct], twelfth
bullet) but we do want to allow explicit constructors in emplace, as the
following example shows:
</p>

<blockquote><pre>vector&lt;shared_ptr&lt;int&gt;&gt; v;
v.emplace_back(new int); <font color="#C80000">// should be allowed</font>
</pre></blockquote>

<p>
If the issue is accepted and scoped allocators are removed, I suggest to
add a new pair of concepts to  [concept.construct], namely:
</p>

<blockquote><pre>auto concept HasExplicitConstructor&lt;typename T, typename... Args&gt; {
 explicit T::T(Args...);
}

auto concept ExplicitConstructible&lt;typename T, typename... Args&gt;
 : HasExplicitConstructor&lt;T, Args...&gt;, NothrowDestructible&lt;T&gt;
{ }
</pre></blockquote>

<p>
We should then use <tt>ExplicitConstructible</tt> as the requirement for all
<tt>emplace_xxx()</tt> member functions.
</p>
<p>
For coherence and consistency with the similar concepts
<tt>Convertible/ExplicitlyConvertible</tt>, we might also consider changing
<tt>Constructible</tt> to:
</p>

<blockquote><pre>auto concept Constructible&lt;typename T, typename... Args&gt;
 : HasConstructor&lt;T, Args...&gt;, ExplicitConstructible&lt;T, Args...&gt;
{ }
</pre></blockquote>

<p>
Moreover, all emplace-related concepts in  [container.concepts]
should also use <tt>ExplicitConstructible</tt> instead of <tt>Constructible</tt> in the
definitions of their axioms. In fact the concepts in  [container.concepts] should be
corrected even if the issue is not accepted.
</p>
<p>
On the other hand, if the issue is not accepted, the scoped allocator
adaptors should be fixed because the following code:
</p>

<blockquote><pre>template &lt;typename T&gt; using scoped_allocator = scoped_allocator_adaptor&lt;allocator&lt;T&gt;&gt;;

vector&lt;shared_ptr&lt;int&gt;, scoped_allocator&lt;shared_ptr&lt;int&gt;&gt;&gt; v;
v.emplace_back(new int); <font color="#C80000">// ops! doesn't compile</font>
</pre></blockquote>

<p>
doesn't compile, as the member function <tt>construct()</tt> of the scoped
allocator requires non-explicit constructors through concept
<tt>ConstructibleWithAllocator</tt>. Fixing that is not difficult but probably
more work than it's worth and is therefore, IMHO, one more reason in
support of the complete removal of scoped allocators.
</p>
</blockquote>

<p><i>[
2009-06-09 Alan adds:
]</i></p>


<blockquote>
<p>
I reopened this issue because I did not think that these National Body
comments were adequately addressed by marking them NAD. My understanding
is that something can be marked NAD if it is clearly a misunderstanding
or trivial, but a substantive issue that has any technical merit
requires a disposition that addresses the concerns.
</p>
<p>
The notes in the NB comment list (US 65 &amp; US 74.1) say that:
</p>
<ol type="a">
<li>
this issue has not introduced any new arguments not previously discussed,
</li>
<li>
the vote (4-9-3) was not a consensus for removing scoped allocators,
</li>
<li>
the issue is resolved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>.
</li>
</ol>
<p>
My opinion is:
</p>
<ol type="a">
<li>
there are new arguments in both comments regarding concepts (which were
not present in the library when the scoped allocator proposal was voted
in),
</li>
<li>
the vote was clearly not a consensus for removal, but just saying there
was a vote does not provide a rationale,
</li>
<li>
I do not believe that N2840 addresses these comments (although it does
many other things and was voted in with strong approval).
</li>
</ol>

<p>
My motivation to open the issue was to ensure that the NB comments were
adequately addressed in a way that would not risk a "no" vote on our
FCD. If there are responses to the technical concerns raised, then
perhaps they should be recorded. If the members of the NB who authored
the comments are satisfied with N2840 and the other disposition remarks
in the comment list, then I am sure they will say so. In either case,
this issue can be closed very quickly in Frankfurt, and hopefully will
have helped make us more confident of approval with little effort. If in
fact there is controversy, my thought is that it is better to know now
rather than later so there is more time to deal with it.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Addressed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>


<p><b>Rationale:</b></p>
Scoped allocators have been revised significantly.





<hr>
<h3><a name="1079"></a>1079. UK-265: <code>RandomAccessIterator</code>'s <code>operator-</code> has nonsensical effects clause</h3>
<p><b>Section:</b> 24.2.7 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 265</b></p>

<p>UK-265:</p>
<p>
This effects clause is nonesense. It looks more like an axiom stating
equivalence, and certainly an effects clause cannot change the state of
two arguments passed by const reference
</p>

<p><i>[
2009-09-18 Alisdair adds:
]</i></p>


<blockquote>
<p>
For random access iterators, the definitions of <tt>(b-a)</tt> and
<tt>(a&lt;b)</tt> are circular:
</p>

<p>
From table Table 104 -- Random access iterator requirements:
</p>

<blockquote><pre>b - a :==&gt;  (a &lt; b) ? distance(a,b) : -distance(b,a)

a &lt; b :==&gt;  b - a &gt; 0
</pre></blockquote>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>

<p><i>[
2010-02-13 Alisdair opens.
]</i></p>


<blockquote>
<p>
Looking again at LWG #1079, the wording in the issue no longer exists, and
appears to be entirely an artefact of the concepts wording.
</p>

<p>
This issue is currently on our Ready list (not even Tentative!) but I think it
has to be pulled as there is no way to apply the resolution.
</p>

<p>
Looking at the current paper, I think this issue is now "NAD, solved by the
removal of concepts".  Unfortunately it is too late to poll again, so we will
have to perform that review in Pittsburgh.
</p>
</blockquote>

<p><i>[
2010-02-13 Daniel updates the wording to address the circularity problem.
]</i></p>


<blockquote>
<p><i>[
The previous wording is preserved here:
]</i></p>

<blockquote>

<p>Modify 24.2.7 [random.access.iterators]p7-9 as follows:</p>

<blockquote><pre>difference_type operator-(const X&amp; a, const X&amp; b);
</pre>
<ol start="7">
  <li><i>Precondition</i>: there exists a value <code>n</code> of
  <code>difference_type</code> such that <code>a == b + n</code>.</li>
  <li><del><i>Effects</i>: <code>b == a + (b - a)</code></del></li>
  <li><i>Returns</i>: <del><code>(a &lt; b) ? distance(a,b) :
  -distance(b,a)</code></del><ins><code>n</code></ins></li>
</ol>
</blockquote>

</blockquote>
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Moved to Ready for Pittsburgh.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Modify Table 105 in 24.2.7 [random.access.iterators]:
</p>

<blockquote>
<table border="1">
<caption>Table 105 � Random access iterator requirements (in addition to
bidirectional iterator)</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion/note<br>pre-/post-condition</th>
</tr>

<tr>
<td><tt>b - a</tt></td>
<td><tt>Distance</tt></td>
<td><tt><del>distance(a,b)</del></tt>
<ins>return <tt>n</tt></ins></td>
<td>pre: there exists a value <tt>n</tt> of <tt>Distance</tt> such that <tt>a +
n == b</tt>. <tt>b == a + (b - a)</tt>.</td>
</tr>

</tbody></table>
</blockquote>





<hr>
<h3><a name="1089"></a>1089. Response to JP 76</h3>
<p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP 76</b></p>

<p>
A description for "Throws: Nothing." are not unified.
</p>

<p>
At the part without throw, "Throws: Nothing." should be described.
</p>

<p>
Add "Throws: Nothing." to the following.
</p>

<ul>
<li>
30.3.1.6 [thread.thread.static] p1
</li>
<li>
30.4.2.1 [thread.lock.guard] p4
</li>
<li>
30.4.2.2.1 [thread.lock.unique.cons] p6
</li>
<li>
30.5.1 [thread.condition.condvar] p7 and p8
</li>
<li>
30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25
</li>
</ul>

<p><i>[
Summit:
]</i></p>

<blockquote>
Pass on to editor.
</blockquote>

<p><i>[
Post Summit:  Editor declares this non-editorial.
]</i></p>


<p><i>[
2009-08-01 Howard provided wording:
]</i></p>


<blockquote>

<p>
The definition of "<i>Throws:</i> Nothing." that I added is probably going to
be controversial, but I beg you to consider it seriously.
</p>

<blockquote>
<p>
In C++ there are three "flow control" options for a function:
</p>

<ol>
<li>
It can return, either with a value, or with <tt>void</tt>.
</li>
<li>
It can call a function which never returns, such as <tt>std::exit</tt> or
<tt>std::terminate</tt>.
</li>
<li>
It can throw an exception.
</li>
</ol>

The above list can be abbreviated with:

<ol>
<li><b>R</b>eturns.</li>
<li><b>E</b>nds program.</li>
<li><b>T</b>hrows exception.</li>
</ol>

<p>
In general a function can have the behavior of any of these 3, or any combination
of any of these three, depending upon run time data.
</p>

<ol>
<li><b>R</b></li>
<li><b>E</b></li>
<li><b>T</b></li>
<li><b>RE</b></li>
<li><b>RT</b></li>
<li><b>ET</b></li>
<li><b>RET</b></li>
</ol>

<p>
A function with no throw spec, and no documentation, is in general a <b>RET</b>
function.  It may return, it may end the program, or it may throw.  When we
specify a function with an empty throw spec:
</p>

<blockquote><pre>void f() throw();
</pre></blockquote>

<p>
We are saying that <tt>f()</tt> is an <b>RE</b> function:  It may return or end
the program, but it will not throw.
</p>

<p>
I posit that there are very few places in the library half of the standard
where we intend for functions to be able to end the program (call <tt>terminate</tt>).
And none of those places where we do say <tt>terminate</tt> could be called,
do we currently say "<i>Throws:</i> Nothing.".
</p>

<p>
I believe that if we define "<i>Throws:</i> Nothing." to mean <b>R</b>,
we will both clarify many, many places in the standard, <em>and</em> give us a
good rationale for choosing between "<i>Throws:</i> Nothing." (<b>R</b>)
and <tt>throw()</tt> (<b>RE</b>) in the future.  Indeed, this may give us motivation
to change several <tt>throw()</tt>s to "<i>Throws:</i> Nothing.".
</p>
</blockquote>

<p>
I did not add the following changes as JP 76 requested as I believe we want to
allow these functions to throw:
</p>

<blockquote>
<p>
Add a paragraph under 30.4.2.1 [thread.lock.guard] p4:
</p>

<blockquote><pre>explicit lock_guard(mutex_type&amp; m);
</pre>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>

<p>
Add a paragraph under 30.4.2.2.1 [thread.lock.unique.cons] p6:
</p>

<blockquote><pre>explicit unique_lock(mutex_type&amp; m);
</pre>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>

<p>
Add a paragraph under 30.5.2 [thread.condition.condvarany] p19, p21 and p25:
</p>

<blockquote><pre>template &lt;class Lock, class Rep, class Period&gt; 
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>

<blockquote><pre>template &lt;class Lock, class Duration, class Predicate&gt; 
  bool wait_until(Lock&amp; lock, const chrono::time_point&lt;Clock, Duration&gt;&amp; rel_time, Predicate pred);
</pre>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>

<blockquote><pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
</pre>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>

</blockquote>

</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Defer pending further developments with exception restriction annotations.
</blockquote>

<p><i>[
2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-02-24 Pete moved to Open:
]</i></p>


<blockquote>
A "<i>Throws:</i> Nothing" specification is not the place to say that a function
is not allowed to call <tt>exit()</tt>. While I agree with the thrust of the
proposed resolution, "doesn't throw exceptions" is a subset of "always returns
normally". If it's important to say that most library functions don't call
<tt>exit()</tt>, say so.
</blockquote>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Move to Ready except for the added paragraph to 17.5.1.4 [structure.specifications].
</blockquote>



<p><b>Proposed resolution:</b></p>


<p>
Add a paragraph under 30.3.1.6 [thread.thread.static] p1:
</p>

<blockquote><pre>unsigned hardware_concurrency();
</pre>

<p>
-1- <i>Returns:</i> ...
</p>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>

<p>
Add a paragraph under 30.5.1 [thread.condition.condvar] p7 and p8:
</p>

<blockquote>
<p>
<i>[Informational, not to be incluced in the WP: The POSIX spec allows only:</i>
</p>
<dl>
<dt><i>[EINVAL]</i></dt>
<dd><i>The value <tt>cond</tt> does not refer to an initialized condition variable. � end informational]</i></dd>
</dl>

<pre>void notify_one();
</pre>

<p>
-7- <i>Effects:</i> ...
</p>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>

<blockquote><pre>void notify_all();
</pre>

<p>
-8- <i>Effects:</i> ...
</p>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>


<p>
Add a paragraph under 30.5.2 [thread.condition.condvarany] p6 and p7:
</p>

<blockquote>
<pre>void notify_one();
</pre>

<p>
-6- <i>Effects:</i> ...
</p>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>

<blockquote><pre>void notify_all();
</pre>

<p>
-7- <i>Effects:</i> ...
</p>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>
</blockquote>







<hr>
<h3><a name="1094"></a>1094. Response to JP 65 and JP 66</h3>
<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-24 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP 65 and JP 66</b></p>

<p>
Switch from "unspecified-bool-type" to "explicit operator bool() const". 
</p>

<p>
Replace <tt>operator unspecified-bool-type() const;</tt>" with <tt>explicit operator bool() const;</tt>
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
We agree with the proposed resolution.
Move to Review.
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change the synopis in 27.5.4 [ios]:
</p>

<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
</pre></blockquote>

<p>
Change 27.5.4.3 [iostate.flags]:
</p>

<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
</pre>

<blockquote>
<p>
-1- <i>Returns:</i> <ins><tt>!fail()</tt></ins> <del>If <tt>fail()</tt> then a value that will evaluate
false in a boolean context; otherwise a value that will evaluate true in
a boolean context. The value type returned shall not be convertible to
int.</del>
</p>
<p>
<del>[<i>Note:</i> This conversion can be used in contexts where a bool is expected
(e.g., an <tt>if</tt> condition); however, implicit conversions (e.g.,
to <tt>int</tt>) that can occur with <tt>bool</tt> are not allowed,
eliminating some sources of user error. One possible implementation
choice for this type is pointer-to-member. <i>-- end note</i>]</del>
</p>
</blockquote>
</blockquote>







<hr>
<h3><a name="1095"></a>1095. <i>Shared objects and the library</i> wording unclear</h3>
<p><b>Section:</b> 17.6.3.10 [res.on.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-27 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm">N2775</a>,
<i>Small library thread-safety revisions</i>, among other changes, removed a note from
17.6.3.10 [res.on.objects] that read:
</p>

<blockquote>
[<i>Note:</i> This prohibition against concurrent non-const access means that
modifying an object of a standard library type shared between threads
without using a locking mechanism may result in a data race. <i>--end note</i>.]
</blockquote>

<p>
That resulted in wording which is technically correct but can only be
understood by reading the lengthy and complex 17.6.4.9 [res.on.data.races]
Data race avoidance. This has the effect of making
17.6.3.10 [res.on.objects] unclear, and has already resulted in a query
to the LWG reflector. See c++std-lib-23194.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
The proposed wording seems to need a bit of tweaking
("really bad idea" isn't quite up to standardese).
We would like feedback
as to whether the original Note's removal was intentional.
</p>
<p>
Change the phrase "is a really bad idea"
to "risks undefined behavior" and
move to Review status.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Note: Change to read: "Modifying...", Delete 'thus', move to Ready
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 17.6.3.10 [res.on.objects] as indicated:
</p>

<blockquote>
<p>
The behavior of a program is undefined if calls to standard library
functions from different threads may introduce a data race. The
conditions under which this may occur are specified in 17.6.4.7.
</p>
<p><ins>
[<i>Note:</i> Modifying an object of a standard library type shared between
threads risks undefined behavior unless objects of the type are explicitly
specified as being sharable without data races or the user supplies a
locking mechanism. <i>--end note</i>]
</ins></p>
</blockquote>





<hr>
<h3><a name="1097"></a>1097. #define __STDCPP_THREADS</h3>
<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE 18</b></p>

<p>
Freestanding implementations do not (necessarily) have
  support for multiple threads (see 1.10 [intro.multithread]).
  Applications and libraries may want to optimize for the
  absence of threads.  I therefore propose a preprocessor
  macro to indicate whether multiple threads can occur.
</p>

<p>
There is ample prior implementation experience for this
  feature with various spellings of the macro name.  For
  example, gcc implicitly defines <tt>_REENTRANT</tt>
  if multi-threading support is selected on the compiler
  command-line.
</p>

<p>
While this is submitted as a library issue, it may be more
  appropriate to add the macro in 16.8 cpp.predefined in the
  core language.
</p>

<p>
See also
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We agree with the issue, and believe it is properly a library issue.
</p>
<p>
We prefer that the macro be conditionally defined
as part of the <tt>&lt;thread&gt;</tt> header.
</p>
<p>
Move to Review.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
2010-02-25 Pete moved to Open:
]</i></p>


<blockquote>
<p>
The proposed resolution adds a feature-test macro named
<tt>__STDCPP_THREADS</tt>, described after the following new text:
</p>

<blockquote>
The standard library defines the following macros; no explicit prior inclusion
of any header file is necessary.
</blockquote>

<p>
The correct term here is "header", not "header file". But that's minor. The real
problem is that library entities are always defined in headers. If
<tt>__STDCPP_THREADS</tt> is defined without including any header it's part of
the language and belongs with the other predefined macros in the Preprocessor
clause.
</p>

<p>
Oddly enough, the comments from Batavia say "We prefer that the macro be
conditionally defined as part of the <tt>&lt;thread&gt;</tt> header." There's no
mention of a decision to change this.
</p>
</blockquote>

<p><i>[
2010-02-26 Ganesh updates wording.
]</i></p>


<p><i>[
2010 Pittsburgh:  Adopt Ganesh's wording and move to Review.
]</i></p>


<p><i>[
2010-03-08 Pete adds:
]</i></p>


<blockquote>
Most macros we have begin and end with with double underbars, this one
only begins with double underbars.
</blockquote>

<p><i>[
2010 Pittsburgh:  Ganesh's wording adopted and moved to Ready for Pittsburgh.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Change 17.6.1.3 [compliance]/3:
</p>

<blockquote>
3 The supplied version of the header <tt>&lt;cstdlib&gt;</tt> shall
declare at least the functions <tt>abort()</tt>, <tt>atexit()</tt>, and
<tt>exit()</tt> (18.5). <ins>The supplied version of the header
<tt>&lt;thread&gt;</tt> either shall meet the same requirements as for a
hosted implementation or including it shall have no effect.</ins> The
other headers listed in this table shall meet the same requirements as
for a hosted implementation.
</blockquote>

<p>
Add the following line to table 15:
</p>

<blockquote>
<table border="1">
<caption>Table 15 � C++ headers for freestanding implementations</caption>

<tbody><tr>
<th>Subclause</th>
<th>Header(s)</th>
</tr>

<tr>
<td colspan="2">...</td>
</tr>

<tr>
<td><ins>30.3 [thread.threads] Threads</ins></td>
<td><ins><tt>&lt;thread&gt;</tt></ins></td>
</tr>

</tbody></table>

</blockquote>

<p>
Add to the <tt>&lt;thread&gt;</tt> synopsis in 30.3 [thread.threads]/1 the line:
</p>

<blockquote><pre>namespace std {

<ins>#define __STDCPP_THREADS __cplusplus</ins>

  class thread;
  ...
</pre></blockquote>









<hr>
<h3><a name="1098"></a>1098. definition of get_pointer_safety()</h3>
<p><b>Section:</b> 20.9.11 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE 18</b></p>

<p>
 In 20.9.11 [util.dynamic.safety], <tt>get_pointer_safety()</tt> purports
to define behavior for
 non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]).  However,
 the cited core-language section in paragraph 4 specifies undefined behavior
 for the use of such pointer values.  This seems an unfortunate near-contradiction.
 I suggest to specify the term <i>relaxed pointer safety</i> in
 the core language section and refer to it from the library description.
 This issue deals with the library part, the corresponding core issue (c++std-core-13940)
 deals with the core modifications.
</p>

<p>
See also
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
We recommend if this issue is to be moved,
the issue be moved concurrently with the cited Core issue.
</p>
<p>
We agree with the intent of the proposed resolution.
We would like input from garbage collection specialists.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
The core issue is 853 and is in Ready status.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In 20.9.11 [util.dynamic.safety] p16, replace the description of
<tt>get_pointer_safety()</tt> with:
</p>

<blockquote>
<p>
<tt>pointer_safety get_pointer_safety();</tt>
</p>
<blockquote>
<p>
<del><i>Returns:</i> an enumeration value indicating the implementation's treatment
of pointers that are not safely derived (3.7.4.3). Returns
<tt>pointer_safety::relaxed</tt> if pointers that are not safely derived will be
treated the same as pointers that are safely derived for the duration of
the program. Returns <tt>pointer_safety::preferred</tt> if pointers that are not
safely derived will be treated the same as pointers that are safely
derived for the duration of the program but allows the implementation to
hint that it could be desirable to avoid dereferencing pointers that are
not safely derived as described. [<i>Example:</i> <tt>pointer_safety::preferred</tt>
might be returned to detect if a leak detector is running to avoid
spurious leak reports. -- <i>end note</i>] Returns <tt>pointer_safety::strict</tt> if
pointers that are not safely derived might be treated differently than
pointers that are safely derived.</del>
</p>
<p><ins>
<i>Returns:</i> Returns <tt>pointer_safety::strict</tt> if the implementation has
   strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is
   implementation-defined whether <tt>get_pointer_safety</tt> returns
   <tt>pointer_safety::relaxed</tt> or <tt>pointer_safety::preferred</tt> if the
   implementation has relaxed pointer safety
   (3.7.4.3 [basic.stc.dynamic.safety]).<sup>Footnote</sup>
</ins></p>

<p><ins>
<i>Throws:</i> nothing
</ins></p>

<p><ins>
Footnote) <tt>pointer_safety::preferred</tt> might be returned to indicate to the
   program that a leak detector is running so that the program can avoid
   spurious leak reports.
</ins>
</p>

</blockquote>
</blockquote>





<hr>
<h3><a name="1100"></a>1100. <tt>auto_ptr</tt> to <tt>unique_ptr</tt> conversion</h3>
<p><b>Section:</b> 20.9.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Message c++std-lib-23182 led to a discussion in which several people
expressed interest in being able to convert an <tt>auto_ptr</tt> to a
<tt>unique_ptr</tt> without the need to call <tt>release</tt>.  Below is
wording to accomplish this.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Pete believes it not a good idea to separate parts of a class's definition.
Therefore, if we do this,
it should be part of <tt>unique-ptr</tt>'s specification.
</p>
<p>
Alisdair believes the lvalue overload may be not necessary.
</p>
<p>
Marc believes it is more than just sugar,
as it does ease the transition to <tt>unique-ptr</tt>.
</p>
<p>
We agree with the resolution as presented.
Move to Tentatively Ready.
</p>
</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
Moved from Tentatively Ready to Open only because the wording needs to be
tweaked for concepts removal.
</blockquote>

<p><i>[
2009-08-01 Howard deconceptifies wording:
]</i></p>


<blockquote>
I also moved the change from D.12 [depr.auto.ptr]
to 20.9.9.2 [unique.ptr.single] per the Editor's request
in Batavia (as long as I was making changes anyway).  Set back
to Review.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>

<p><i>[
2010-03-14 Howard adds:
]</i></p>


<blockquote>
We moved
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
to the formal motions page in Pittsburgh which should obsolete this issue.  I've
moved this issue to NAD Editorial, solved by N3073.
</blockquote>



<p><b>Rationale:</b></p>
<p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Add to 20.9.9.2 [unique.ptr.single]:
</p>

<blockquote><pre>template &lt;class T, class D&gt;
class unique_ptr
{
public:
<ins>    template &lt;class U&gt;
      unique_ptr(auto_ptr&lt;U&gt;&amp; u);
    template &lt;class U&gt;
      unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);</ins>
};
</pre></blockquote>

<p>
Add to 20.9.9.2.1 [unique.ptr.single.ctor]:
</p>

<blockquote><pre>template &lt;class U&gt;
  unique_ptr(auto_ptr&lt;U&gt;&amp; u);
template &lt;class U&gt;
  unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
<i>Effects:</i> Constructs a <tt>unique_ptr</tt> with <tt>u.release()</tt>.
</p>

<p>
<i>Postconditions:</i> <tt>get() == </tt> the value <tt>u.get()</tt> had before
the construciton, modulo any required offset adjustments resulting from the cast from
<tt>U*</tt> to <tt>T*</tt>.  <tt>u.get() == nullptr</tt>.
</p>

<p>
<i>Throws:</i> nothing.
</p>

<p>
<i>Remarks:</i> <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt> and
<tt>D</tt> shall be the same type as <tt>default_delete&lt;T&gt;</tt>, else these
constructors shall not participate in overload resolution.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="1103"></a>1103. <tt>system_error</tt> constructor postcondition overly strict</h3>
<p><b>Section:</b> 19.5.6.2 [syserr.syserr.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
19.5.6.2 [syserr.syserr.members] says:
</p>

<blockquote><pre>system_error(error_code ec, const string&amp; what_arg);
</pre>
<blockquote>
<p>
<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
</p>
<p>
<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
</p>
</blockquote>
</blockquote>

<p>
However the intent is for:
</p>

<blockquote><pre>std::system_error se(std::errc::not_a_directory, "In FooBar");
...
se.what();  <font color="#C80000">// returns something along the lines of:</font>
            <font color="#C80000">//   "In FooBar: Not a directory"</font>
</pre></blockquote>

<p>
The way the constructor postconditions are set up now, to achieve both
conformance, and the desired intent in the <tt>what()</tt> string, the
<tt>system_error</tt> constructor must store "In FooBar" in the base class,
and then form the desired output each time <tt>what()</tt> is called.  Or
alternatively, store "In FooBar" in the base class, and store the desired
<tt>what()</tt> string in the derived <tt>system_error</tt>, and override
<tt>what()</tt> to return the string in the derived part.
</p>

<p>
Both of the above implementations seem suboptimal to me.  In one I'm computing
a new string every time <tt>what()</tt> is called.  And since <tt>what()</tt>
can't propagate exceptions, the client may get a different string on different
calls.
</p>

<p>
The second solution requires storing two strings instead of one.
</p>

<p>
What I would like to be able to do is form the desired <tt>what()</tt> string
once in the <tt>system_error</tt> constructor, and store <em>that</em> in the
base class.  Now I'm:
</p>

<ol>
<li>Computing the desired <tt>what()</tt> only once.</li>
<li>The base class <tt>what()</tt> definition is sufficient and nothrow.</li>
<li>I'm not storing multiple strings.</li>
</ol>

<p>
This is smaller code, smaller data, and faster.
</p>

<p>
<tt>ios_base::failure</tt> has the same issue.
</p>

<p><i>[
Comments about this change received favorable comments from the <tt>system_error</tt>
designers.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>


<blockquote>
<p>
We agree with the proposed resolution.
</p>
<p>
Move to Tentatively Ready.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 19.5.6.2 [syserr.syserr.members], change the following constructor postconditions:
</p>

<blockquote>
<pre>system_error(error_code ec, const string&amp; what_arg);
</pre>
<blockquote>
-2- <i>Postconditions:</i> <tt>code() == ec</tt>
and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
</blockquote>

<pre>system_error(error_code ec, const char* what_arg);
</pre>
<blockquote>
-4- <i>Postconditions:</i> <tt>code() == ec</tt>
and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
</blockquote>

<pre>system_error(error_code ec);
</pre>
<blockquote>
-6- <i>Postconditions:</i> <tt>code() == ec</tt>
<del>and <tt>strcmp(runtime_error::what(), ""</tt></del>.
</blockquote>

<pre>system_error(int ev, const error_category&amp; ecat, const string&amp; what_arg);
</pre>
<blockquote>
-8- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
</blockquote>

<pre>system_error(int ev, const error_category&amp; ecat, const char* what_arg);
</pre>
<blockquote>
-10- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
</blockquote>

<pre>system_error(int ev, const error_category&amp; ecat);
</pre>
<blockquote>
-12- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
<del>and <tt>strcmp(runtime_error::what(), "") == 0</tt></del>.
</blockquote>

</blockquote>

<p>
In 19.5.6.2 [syserr.syserr.members], change the description of <tt>what()</tt>:
</p>

<blockquote>
<pre>const char *what() const throw();
</pre>
<blockquote>
<p>
-14- <i>Returns:</i> An NTBS incorporating <del><tt>runtime_error::what()</tt> and
<tt>code().message()</tt></del> <ins>the arguments supplied in the constructor</ins>.
</p>
<p>
[<i>Note:</i> <del>One possible implementation would be:</del>
<ins>The return NTBS might take the form: <tt>what_arg + ": " + code().message()</tt></ins>
</p>
<blockquote><pre><del>
if (msg.empty()) { 
  try { 
    string tmp = runtime_error::what(); 
    if (code()) { 
      if (!tmp.empty()) 
        tmp += ": "; 
      tmp += code().message(); 
    } 
    swap(msg, tmp); 
  } catch(...) { 
    return runtime_error::what(); 
  } 
return msg.c_str();
</del></pre></blockquote>
<p>
� <i>end note</i>]
</p>
</blockquote>
</blockquote>

<p>
In 27.5.2.1.1 [ios::failure], change the synopsis:
</p>

<blockquote><pre>namespace std { 
  class ios_base::failure : public system_error { 
  public: 
    explicit failure(const string&amp; msg, const error_code&amp; ec = io_errc::stream); 
    explicit failure(const char* msg, const error_code&amp; ec = io_errc::stream); 
    <del>virtual const char* what() const throw();</del>
  }; 
}
</pre></blockquote>

<p>
In 27.5.2.1.1 [ios::failure], change the description of the constructors:
</p>

<blockquote>

<pre>explicit failure(const string&amp; msg, , const error_code&amp; ec = io_errc::stream);
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
<ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
</p>
<p>
<del>-4- <i>Postcondition:</i> <tt>code() == ec</tt> and <tt>strcmp(what(), msg.c_str()) == 0</tt></del>
</p>
</blockquote>

<pre>explicit failure(const char* msg, const error_code&amp; ec = io_errc::stream);
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
<ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
</p>
<p>
<del>-6- <i>Postcondition:</i> <tt>code() == ec and strcmp(what(), msg) == 0</tt></del>
</p>
</blockquote>

</blockquote>

<p>
In 27.5.2.1.1 [ios::failure], remove <tt>what</tt> (the base class definition
need not be repeated here).
</p>

<blockquote>
<pre><del>const char* what() const;</del>
</pre>
<blockquote>
<del>-7- <i>Returns:</i> The message <tt>msg</tt> with which the exception was created.</del>
</blockquote>

</blockquote>






<hr>
<h3><a name="1104"></a>1104. <tt>basic_ios::move</tt> should accept lvalues</h3>
<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
With the rvalue reference changes in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
<tt>basic_ios::move</tt> no longer has the most convenient signature:
</p>

<blockquote><pre>void move(basic_ios&amp;&amp; rhs);
</pre></blockquote>

<p>
This signature should be changed to accept lvalues.  It does not need to be
overloaded to accept rvalues.  This is a special case that only derived clients
will see.  The generic <tt>move</tt> still needs to accept rvalues.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Tom prefers, on general principles, to provide both overloads.
Alisdair agrees.
</p>
<p>
Howard points out that there is no backward compatibility issue
as this is new to C++0X.
</p>
<p>
We agree that both overloads should be provided,
and Howard will provide the additional wording.
Move to Open.
</p>
</blockquote>

<p><i>[
2009-05-23 Howard adds:
]</i></p>


<blockquote>
Added overload, moved to Review.
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add a signature to the existing prototype in the synopsis of 27.5.4 [ios]
and in 27.5.4.2 [basic.ios.members]:
</p>

<blockquote><pre><ins>void move(basic_ios&amp; rhs);</ins>
void move(basic_ios&amp;&amp; rhs);
</pre></blockquote>





<hr>
<h3><a name="1108"></a>1108. thread.req.exception overly constrains implementations</h3>
<p><b>Section:</b> 30.2.2 [thread.req.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current formulation of 30.2.2 [thread.req.exception]/2 reads:
</p>
<blockquote>
The error_category of the <tt>error_code</tt> reported by such an
exception's <tt>code()</tt> member function is as specified in the error
condition Clause.
</blockquote>
<p>
This constraint on the code's associated <tt>error_categor</tt> means an
implementation must perform a mapping from the system-generated
error to a <tt>generic_category()</tt> error code. The problems with this
include:
</p>

<ul>
<li>
The mapping is always performed, even if the resultant value is
 never used.
</li>
<li>
<p>
The original error produced by the operating system is lost.
</p>
</li>
</ul>
<p>
The latter was one of Peter Dimov's main objections (in a private
email discussion) to the original <tt>error_code</tt>-only design, and led to
the creation of <tt>error_condition</tt> in the first place. Specifically,
<tt>error_code</tt> and <tt>error_condition</tt> are intended to perform the following
roles:
</p>
<ul>
<li>
<tt>error_code</tt> holds the original error produced by the operating
 system.
</li>
<li>
<tt>error_condition</tt> and the generic category provide a set of well
 known error constants that error codes may be tested against.
</li>
</ul>
<p>
Any mapping determining correspondence of the returned error code to
the conditions listed in the error condition clause falls under the
"latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects].
(Although obviously their latitude is restricted a little by the
need to match the right error condition when returning an error code
from a library function.)
</p>
<p>
It is important that this <tt>error_code/error_condition</tt> usage is done
correctly for the thread library since it is likely to set the
pattern for future TR libraries that interact with the operating
system.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Move to Open, and recommend the issue be deferred until after the next
Committee Draft is issued.
</blockquote>

<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 30.2.2 [thread.req.exception]/2:
</p>

<blockquote>
<p>
-2- <del>The <tt>error_category</tt> (19.5.1.1) of the <tt>error_code</tt> reported by
such an exception's <tt>code()</tt> member function 
is as specified in the error condition Clause.</del>
<ins>
The <tt>error_code</tt> reported by such an exception's <tt>code()</tt> member
function shall compare equal to one of the conditions specified in
the function's error condition Clause. [<i>Example:</i> When the thread
constructor fails:
</ins>
</p>
<blockquote><pre><ins>
ec.category() == implementation-defined // probably system_category
ec == errc::resource_unavailable_try_again // holds true
</ins></pre></blockquote>

<p><ins>
� <i>end example</i>]
</ins></p>

</blockquote>






<hr>
<h3><a name="1110"></a>1110. Is <tt>for_each</tt> overconstrained?</h3>
<p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Quoting working paper for reference (25.2.4 [alg.foreach]):
</p>

<blockquote>
<pre>template&lt;InputIterator Iter, Callable&lt;auto, Iter::reference&gt; Function&gt;
  requires CopyConstructible&lt;Function&gt;
  Function for_each(Iter first, Iter last, Function f);
</pre>
<blockquote>
<p>
1 Effects: Applies f to the result of dereferencing every iterator in the
 range [first,last), starting from first and proceeding to last - 1.
</p>
<p>
2 Returns: f.
</p>
<p>
3 Complexity: Applies f exactly last - first times.
</p>
</blockquote>
</blockquote>

<p>
P2 implies the passed object <tt>f</tt> should be invoked at each stage, rather than
some copy of <tt>f</tt>.  This is important if the return value is to usefully
accumulate changes.  So the requirements are an object of type <tt>Function</tt> can
be passed-by-value, invoked multiple times, and then return by value.  In
this case, <tt>MoveConstructible</tt> is sufficient. This would open support for
move-only functors, which might become important in concurrent code as you
can assume there are no other references (copies) of a move-only type and so
freely use them concurrently without additional locks.
</p>

<p><i>[
See further discussion starting with c++std-lib-23686.
]</i></p>


<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Pete suggests we may want to look at this in a broader context
involving other algorithms.
We should also consider the implications of parallelism.
</p>
<p>
Move to Open, and recommend the issue be deferred until after the next
Committee Draft is issued.
</p>
</blockquote>

<p><i>[
2009-10-14 Daniel de-conceptified the proposed resolution.
]</i></p>


<blockquote>
<p>
The note in 25.1 [algorithms.general]/9 already says the right thing:
</p>
<blockquote>
Unless otherwise specified, algorithms that take function objects
as arguments are permitted to copy those function objects freely.
</blockquote>
<p>
So we only need to ensure that the wording for <tt>for_each</tt> is sufficiently
clear, which is the intend of the following rewording.
</p>
</blockquote>

<p><i>[
2009-10-15 Daniel proposes:
]</i></p>


<blockquote>
<ul>
<li>
<p>
Add a new Requires clause just after the prototype declaration (25.2.4 [alg.foreach]):
</p>
<blockquote>
<p>
<ins><i>Requires:</i> <tt>Function</tt> shall be <tt>MoveConstructible</tt>
( [moveconstructible]), <tt>CopyConstructible</tt> is not required.</ins>
</p>
</blockquote>
</li>
<li>
<p>
Change 25.2.4 [alg.foreach]/2 as indicated:
</p>

<blockquote>
<i>Returns:</i> <ins>std::move(</ins>f<ins>)</ins>.
</blockquote>
</li>
</ul>
</blockquote>

<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Tentatively Ready, using Daniel's wording without the portion
saying "CopyConstructible is not required".
</blockquote>

<p><i>[
2009-10-27 Daniel adds:
]</i></p>


<blockquote>
<p>
I see that during the Santa Cruz meeting the originally proposed addition
</p>

<blockquote>
, <tt>CopyConstructible</tt> is not required.
</blockquote>

<p>
was removed. I don't think that this removal was a good idea. The combination
of 25.1 [algorithms.general]/9
</p>

<blockquote>
[<i>Note:</i> Unless otherwise specified, algorithms that take function objects
as arguments are permitted to copy those function objects freely.[..]
</blockquote>

<p>
with the fact that <tt>CopyConstructible</tt> is a refinement <tt>MoveConstructible</tt>
makes it necessary that such an explicit statement is given. Even the
existence of the usage of <tt>std::move</tt> in the <i>Returns</i> clause doesn't
help much, because this would still be well-formed for a <tt>CopyConstructible</tt>
without move constructor. Let me add that the originally proposed
addition reflects current practice in the standard, e.g. 25.3.9 [alg.unique]/5
usages a similar terminology.
</p>

<p>
For similar wording need in case for auto_ptr see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>.
</p>

<p><i>[
Howard: Moved from Tentatively Ready to Open.
]</i></p>

</blockquote>

<p><i>[
2009-11-20 Howard restores "not <tt>CopyConstructible</tt>" to the spec.
]</i></p>


<p><i>[
2009-11-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<ul>
<li>
<p>
Add a new Requires clause just after the prototype declaration (25.2.4 [alg.foreach]):
</p>
<blockquote>
<p>
<ins><i>Requires:</i> <tt>Function</tt> shall meet the requirements of
<tt>MoveConstructible</tt> ( [moveconstructible]). 
<tt>Function</tt> need not meet the requirements of
<tt>CopyConstructible</tt> ( [copyconstructible]).</ins>
</p>
</blockquote>
</li>
<li>
<p>
Change 25.2.4 [alg.foreach]/2 as indicated:
</p>

<blockquote>
<i>Returns:</i> <ins>std::move(</ins>f<ins>)</ins>.
</blockquote>
</li>
</ul>








<hr>
<h3><a name="1113"></a>1113. <tt>bitset::to_string</tt> could be simplified</h3>
<p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> our resolution is changing the signature by adding two
defaulting arguments to 3 calls.  In principle, this means that ABI breakage
is not an issue, while API is preserved.
</p>
<p>
With that observation, it would be very nice to use the new ability to
supply default template parameters to function templates to collapse all 3
signatures into 1.  In that spirit, this issue offers an alternative resolution
than that of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>.
</p>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
Move to Open,
and look at the issue again after <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> has been accepted.
We further recommend this be deferred until after the next Committee Draft.
</blockquote>

<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>

<ol type="A">
<li>
<p>
In 20.5 [template.bitset]/1 (class bitset) ammend:
</p>
<blockquote><pre>template &lt;class charT <ins>= char</ins>,
            class traits <ins>= char_traits&lt;charT&gt;</ins>,
            class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt; 
  basic_string&lt;charT, traits, Allocator&gt;
  to_string(charT zero = charT('0'), charT one = charT('1')) const;
<del>template &lt;class charT, class traits&gt; 
  basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string() const; 
template &lt;class charT&gt; 
  basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string() const; 
basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string() const;</del>
</pre></blockquote>
</li>
<li>
<p>
In 20.5.2 [bitset.members] prior to p35 ammend:
</p>
<blockquote><pre>template &lt;class charT <ins>= char</ins>,
            class traits <ins>= char_traits&lt;charT&gt;</ins>,
            class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt; 
  basic_string&lt;charT, traits, Allocator&gt;
  to_string(charT zero = charT('0'), charT one = charT('1')) const;
</pre></blockquote>
</li>
<li>
Strike 20.5.2 [bitset.members] paragraphs 37 -&gt; 39 (including signature
above 37)
</li>
</ol>






<hr>
<h3><a name="1114"></a>1114. Type traits underspecified</h3>
<p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-05-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.
</p>

<p>
The current wording in 20.7.1 [meta.rqmts] is still unclear concerning
it's requirements on the type traits classes regarding ambiguities.
Specifically it's unclear
</p>

<ul>
<li>
if a predicate trait (20.7.4 [meta.unary], 20.7.6 [meta.rel]) could derive from both
<tt>true_type</tt>/<tt>false_type</tt>.
</li>
<li>
if any of the type traits (20.7.1 [meta.rqmts], 20.7.4 [meta.unary], 20.7.6 [meta.rel]) could ambiguously derive
from the same specified result type.
</li>
<li>
if any of the type traits (20.7.1 [meta.rqmts], 20.7.4 [meta.unary], 20.7.6 [meta.rel]) could derive from other
<tt>integral_constant</tt> types making the contained names ambiguous
</li>
<li>
if any of the type traits (20.7.1 [meta.rqmts], 20.7.4 [meta.unary], 20.7.6 [meta.rel]) could have other base
classes that contain members hiding the name of the result type members
or make the contained member names ambiguous.
</li>
</ul>

<p><i>[
Batavia (2009-05):
]</i></p>

<blockquote>
<p>
Alisdair would prefer to factor some of the repeated text,
but modulo a corner case or two,
he believes the proposed wording is otherwise substantially correct.
</p>
<p>
Move to Open.
</p>
</blockquote>

<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Tentatively Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p><i>[
The usage of the notion of a <i>BaseCharacteristic</i> below might be
useful in other places - e.g. to define the base class relation in 20.8.4 [refwrap], 20.8.13 [func.memfn], or 20.8.14.2 [func.wrap.func]. In this case it's definition should probably
be moved to Clause 17
]</i></p>


<ol>
<li>
<p>
Change 20.7.1 [meta.rqmts]/1 as indicated:
</p>
<blockquote>
[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
<ins>and unambiguously</ins> derived, directly or indirectly, from
<ins>its <i>BaseCharacteristic</i>, which is</ins> a specialization of the
template <tt>integral_constant</tt> (20.6.3), with the arguments to the template
<tt>integral_constant</tt> determined by the requirements for the particular
property being described. <ins>The member names of the
<i>BaseCharacteristic</i> shall be unhidden and unambiguously
available in the <i>UnaryTypeTrait</i>.</ins>
</blockquote>
</li>
<li>
<p>
Change 20.7.1 [meta.rqmts]/2 as indicated:
</p>
<blockquote>
[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
<ins>and unambiguously</ins> derived, directly or indirectly, from
<del>an instance</del> <ins>its <i>BaseCharacteristic</i>, which is a
specialization</ins> of the template <tt>integral_constant</tt> (20.6.3), with
the arguments to the template <tt>integral_constant</tt> determined by the
requirements for the particular relationship being described. <ins>The
member names of the <i>BaseCharacteristic</i> shall be unhidden
and unambiguously available in the <i>BinaryTypeTrait</i>.</ins>
</blockquote>
</li>
<li>
<p>
Change 20.7.4 [meta.unary]/2 as indicated:
</p>
<blockquote>
Each of these templates shall be a <i>UnaryTypeTrait</i> (20.6.1),
<del>publicly derived directly or indirectly from <tt>true_type</tt> if the
corresponding condition is true, otherwise from <tt>false_type</tt></del>
<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
corresponding condition is true, otherwise <tt>false_type</tt></ins>.
</blockquote>
</li>
<li>
<p>
Change 20.7.6 [meta.rel]/2 as indicated:
</p>

<blockquote>
Each of these templates shall be a <i>BinaryTypeTrait</i> (20.6.1),
<del>publicly derived directly or indirectly from <tt>true_type</tt> if the
corresponding condition is true, otherwise from <tt>false_type</tt></del>
<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
corresponding condition is true, otherwise <tt>false_type</tt></ins>.
</blockquote>
</li>
</ol>






<hr>
<h3><a name="1116"></a>1116. Literal constructors for tuple</h3>
<p><b>Section:</b> 20.4.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is not currently possible to construct <tt>tuple</tt> literal values,
even if the elements are all literal types.  This is because parameters
are passed to constructor by reference.
</p>
<p>
An alternative would be to pass all constructor arguments by value, where it
is known that *all* elements are literal types.  This can be determined with
concepts, although note that the negative constraint really requires
factoring out a separate concept, as there is no way to provide an 'any of
these fails' constraint inline.
</p>
<p>
Note that we will have similar issues with <tt>pair</tt> (and
<tt>tuple</tt> constructors from <tt>pair</tt>) although I am steering
clear of that class while other constructor-related issues settle.
</p>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Ammend the tuple class template declaration in 20.4.2 [tuple.tuple] as
follows
</p>

<blockquote>
<p>
Add the following concept:
</p>

<blockquote><pre>auto concept AllLiteral&lt; typename ... Types &gt; {
  requires LiteralType&lt;Types&gt;...;
}
</pre></blockquote>

<p>
ammend the constructor 
</p>

<blockquote><pre><ins>template &lt;class... UTypes&gt;
  requires AllLiteral&lt;Types...&gt;
        &amp;&amp; Constructible&lt;Types, UTypes&gt;...
  explicit tuple(UTypes...);</ins>

template &lt;class... UTypes&gt;
  requires <ins>!AllLiteral&lt;Types...&gt;</ins>
        <ins>&amp;&amp;</ins> Constructible&lt;Types, UTypes&amp;&amp;&gt;...
  explicit tuple(UTypes&amp;&amp;...);
</pre></blockquote>

<p>
ammend the constructor
</p>

<blockquote><pre><ins>template &lt;class... UTypes&gt;
  requires AllLiteral&lt;Types...&gt;
        &amp;&amp; Constructible&lt;Types, UTypes&gt;...
  tuple(tuple&lt;UTypes...&gt;);</ins>

template &lt;class... UTypes&gt;
  requires <ins>!AllLiteral&lt;Types...&gt;</ins>
        <ins>&amp;&amp;</ins> Constructible&lt;Types, const UTypes&amp;&gt;...
  tuple(const tuple&lt;UTypes...&gt;&amp;);
</pre></blockquote>

</blockquote>

<p>
Update the same signatures in 20.4.2.1 [tuple.cnstr], paras 3 and 5.
</p>





<hr>
<h3><a name="1117"></a>1117. tuple copy constructor</h3>
<p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The copy constructor for the <tt>tuple</tt> template is constrained.  This seems an
unusual strategy, as the copy constructor will be implicitly deleted if the
constraints are not met.  This is exactly the same effect as requesting an
<tt>=default;</tt> constructor.  The advantage of the latter is that it retains
triviality, and provides support for <tt>tuple</tt>s as literal types if issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1116">1116</a> is also accepted.
</p>
<p>
Actually, it might be worth checking with core if a constrained copy
constructor is treated as a constructor template, and as such does not
suppress the implicit generation of the copy constructor which would hide
the template in this case.
</p>

<p><i>[
2009-05-27 Daniel adds:
]</i></p>


<blockquote>
This would solve one half of the suggested changes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#801">801</a>.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.htm">N2994</a>.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 20.4.2 [tuple.tuple] and 20.4.2.1 [tuple.cnstr] p4:
</p>

<blockquote><pre><del>requires CopyConstructible&lt;Types&gt;...</del> tuple(const tuple&amp;)<ins> = default</ins>;
</pre></blockquote>





<hr>
<h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3>
<p><b>Section:</b> 20.4.2.5 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The APIs <tt>tuple_size</tt> and <tt>tuple_element</tt> do not support
cv-qualified <tt>tuple</tt>s, <tt>pair</tt>s or <tt>array</tt>s.
</p>
<p>
The most generic solution would be to supply partial specializations once
for each cv-type in the <tt>tuple</tt> header.  However, requiring this header for
cv-qualified <tt>pair</tt>s/<tt>array</tt>s seems unhelpful.  The BSI editorial
suggestion (UK-198/US-69,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.html">N2533</a>)
to merge <tt>tuple</tt> into <tt>&lt;utility&gt;</tt> would help with <tt>pair</tt>,
but not <tt>array</tt>.  That might be resolved by making a dependency between the
<tt>&lt;array&gt;</tt> header and <tt>&lt;utility&gt;</tt>, or simply recognising
the dependency be fulfilled in a Remark.
</p>

<p><i>[
2009-05-24 Daniel adds:
]</i></p>


<blockquote>
<p>
All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g.
</p>

<blockquote><pre>template &lt;IdentityOf T&gt; class tuple_size&lt; const T &gt; :
   <ins>public</ins> tuple_size&lt;T&gt; {};
</pre></blockquote>

<p>
The same applies to the tuple_element class hierarchies.
</p>
<p>
What is actually meant with the comment
</p>
<blockquote>
this solution relies on 'metafunction forwarding' to inherit the
nested typename type
</blockquote>
<p>
?
</p>
<p>
I ask, because all base classes are currently unconstrained and their
instantiation is invalid in the constrained context of the <tt>tuple_element</tt> partial
template specializations.
</p>
</blockquote>

<p><i>[
2009-05-24 Alisdair adds:
]</i></p>


<blockquote>
<p>
I think a better solution might be to ask Pete editorially to change all
declarations of tupling APIs to use the struct specifier instead of class.
</p>
<p>
"metafunction forwarding" refers to the MPL metafunction protocol, where a
metafunction result is declared as a nested typedef with the name "type",
allowing metafunctions to be chained by means of inheritance.  It is a
neater syntax than repeatedly declaring a typedef, and inheritance syntax is
slightly nicer when it comes to additional typename keywords.
</p>
<p>
The constrained template with an unconstrained base is a good observation
though.
</p>
</blockquote>

<p><i>[
2009-10 post-Santa Cruz:
]</i></p>


<blockquote>
Move to Open, Alisdair to provide wording. Once wording is
provided, Howard will move to Review.
</blockquote>

<p><i>[
2010-03-28 Daniel deconceptified wording.
]</i></p>


<p><i>[
Post-Rapperswil - Daniel provides wording:
]</i></p>


<p>
The below given P/R reflects the discussion from the Rapperswil meeting that the wording should not constrain 
implementation freedom to realize the actual issue target. Thus the original code form was replaced by
normative words.
</p>
<p>
While preparing this wording it turned out that several <tt>tuple_size</tt> specializations as 
that of <tt>pair</tt> and <tt>array</tt> are underspecified, because the underlying type of the member 
value is not specified except that it is an integral type. For the specializations we could introduce a 
canonical one - like <tt>size_t</tt> - or we could use the same type as the specialization of the 
unqualified type uses. The following wording follows the second approach.
</p>
<p>
The wording refers to N3126.
</p>

<blockquote>
Moved to Tentatively Ready after 6 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li>Change 20.4.1 [tuple.general]/2, header <tt>&lt;tuple&gt;</tt> synopsis, as indicated:
<blockquote><pre>// 20.4.2.5, tuple helper classes:
template &lt;class T&gt; class tuple_size; // undefined
<ins>template &lt;class T&gt; class tuple_size&lt;const T&gt;;</ins>
<ins>template &lt;class T&gt; class tuple_size&lt;volatile T&gt;;</ins>
<ins>template &lt;class T&gt; class tuple_size&lt;const volatile T&gt;;</ins>
<ins></ins>
template &lt;class... Types&gt; class tuple_size&lt;tuple&lt;Types...&gt; &gt;;
	
template &lt;size_t I, class T&gt; class tuple_element; // undefined
<ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const T&gt;;</ins>
<ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, volatile T&gt;;</ins>
<ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const volatile T&gt;;</ins>
<ins></ins>
template &lt;size_t I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
</pre></blockquote>
</li>
<li>Add the end of subclause 20.4.2.5 [tuple.helper] insert the following two paragraphs:
<blockquote><pre><ins>template &lt;class T&gt; class tuple_size&lt;const T&gt;;</ins>
<ins>template &lt;class T&gt; class tuple_size&lt;volatile T&gt;;</ins>
<ins>template &lt;class T&gt; class tuple_size&lt;const volatile T&gt;;</ins>
</pre><blockquote>
<ins>Let <em>TS</em> denote <tt>tuple_size&lt;T&gt;</tt> of the <em>cv</em>-unqualified type <tt>T</tt>. 
Then each of the three templates shall meet the UnaryTypeTrait requirements (20.7.1) with a BaseCharacteristic of 
<tt>integral_constant&lt;remove_cv&lt;decltype(<em>TS</em>::value)&gt;::type, <em>TS</em>::value&gt;</tt>.</ins>
</blockquote></blockquote>

<blockquote><pre><ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const T&gt;;</ins>
<ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, volatile T&gt;;</ins>
<ins>template &lt;size_t I, class T&gt; class tuple_element&lt;I, const volatile T&gt;;</ins>
</pre><blockquote>
<ins>Let <em>TE</em> denote <tt>tuple_element&lt;I, T&gt;</tt> of the <em>cv</em>-unqualified type <tt>T</tt>. Then each of the 
three templates shall meet the TransformationTrait requirements (20.7.1) with a member typedef <tt>type</tt> that shall name the 
same type as the following type:</ins>
<ul>
<li><ins>for the first specialization, the type <tt>add_const&lt;<em>TE</em>::type&gt;::type</tt>,</ins></li>
<li><ins>for the second specialization, the type <tt>add_volatile&lt;<em>TE</em>::type&gt;::type</tt>, and</ins></li>
<li><ins>for the third specialization, the type <tt>add_cv&lt;<em>TE</em>::type&gt;::type</tt></ins></li>
</ul>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="1122"></a>1122. Ratio values should be constexpr</h3>
<p><b>Section:</b> 20.6.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The values <tt>num</tt> and <tt>den</tt> in the <tt>ratio</tt> template
should be declared <tt>constexpr</tt>.
</p>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.htm">N2994</a>.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
20.6.1 [ratio.ratio]
</p>

<blockquote><pre>namespace std {
  template &lt;intmax_t N, intmax_t D = 1&gt;
  class ratio {
  public:
    static const<ins>expr</ins> intmax_t num;
    static const<ins>expr</ins> intmax_t den;
  };
}
</pre></blockquote>






<hr>
<h3><a name="1123"></a>1123. no requirement that standard streams be flushed</h3>
<p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> James Kanze <b>Opened:</b> 2009-05-14 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As currently formulated, the standard doesn't require that there 
is ever a flush of <tt>cout</tt>, etc.  (This implies, for example, that 
the classical hello, world program may have no output.)  In the 
current draft
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
there is a requirement that the objects 
be constructed before <tt>main</tt>, and before the dynamic 
initialization of any non-local objects defined after the 
inclusion of <tt>&lt;iostream&gt;</tt> in the same translation unit.  The only 
requirement that I can find concerning flushing, however, is in 
27.5.2.1.6 [ios::Init], where the destructor of the last 
<tt>std::ios_base::Init</tt> object flushes.  But there is, as far as I 
can see, no guarantee that such an object ever exists. 
</p>
<p>
Also, the wording in  [iostreams.objects] says that:
</p>
<blockquote>
The objects 
are constructed and the associations are established at some 
time prior to or during the first time an object of class 
<tt>ios_base::Init</tt> is constructed, and in any case before the body 
of main begins execution.
</blockquote>
<p>
In 27.5.2.1.6 [ios::Init], however, as an 
effect of the constructor, it says that
</p>
<blockquote>
If <tt>init_cnt</tt> is zero, 
the function stores the value one in <tt>init_cnt</tt>, then constructs 
and initializes the objects <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> 
<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>"
</blockquote>

<p>
which seems to forbid earlier 
construction. 
</p>

<p>
(Note that with these changes, the exposition only "<tt>static 
int init_cnt</tt>" in <tt>ios_base::Init</tt> can be dropped.) 
</p>
<p>
Of course, a determined programmer can still inhibit the 
flush with things like: 
</p>
<blockquote><pre>new std::ios_base::Init ;       //  never deleted 
</pre></blockquote>
<p>
or (in a function): 
</p>
<blockquote><pre>std::ios_base::Init ensureConstruction ; 
//  ... 
exit( EXIT_SUCCESS ) ; 
</pre></blockquote>
<p>
Perhaps some words somewhere to the effect that all 
<tt>std::ios_base::Init</tt> objects should have static lifetime 
would be in order. 
</p>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.  Some editorial changes are expected (in addition to the
proposed wording) to remove <tt>init_cnt</tt> from <tt>Init</tt>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 27.4 [iostream.objects]/2:
</p>

<blockquote>
-2- The objects are constructed and the associations are established at
some time prior to or during the first time an object of class
<tt>ios_base::Init</tt> is constructed, and in any case before the body
of main begins execution.<sup>292</sup> The objects are not destroyed
during program execution.<sup>293</sup>
<del>If a translation unit includes
<tt>&lt;iostream&gt;</tt> or explicitly constructs an
<tt>ios_base::Init</tt> object, these stream objects shall be
constructed before dynamic initialization of non-local objects defined
later in that translation unit.</del>
<ins>The results of including <tt>&lt;iostream&gt;</tt> in a translation
unit shall be as if <tt>&lt;iostream&gt;</tt> defined an instance of
<tt>ios_base::Init</tt> with static lifetime. Similarly, the entire
program shall behave as if there were at least one instance of
<tt>ios_base::Init</tt> with static lifetime.</ins>
</blockquote>

<p>
Change 27.5.2.1.6 [ios::Init]/3:
</p>

<blockquote>
<pre>Init();
</pre>
<blockquote>
-3- <i>Effects:</i> Constructs an object of class <tt>Init</tt>. 
<del>If <tt>init_cnt</tt> is zero, the function stores the value one in
<tt>init_cnt</tt>, then constructs and initializes the objects
<tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> (27.4.1),
<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>
(27.4.2). In any case, the function then adds one to the value stored in
<tt>init_cnt</tt>.</del>
<ins>Constructs and initializes the objects <tt>cin</tt>, <tt>cout</tt>,
<tt>cerr</tt>, <tt>clog</tt>, <tt>wcin</tt>, <tt>wcout</tt>,
<tt>wcerr</tt> and <tt>wclog</tt> if they have not already been
constructed and initialized.</ins>
</blockquote>
</blockquote>

<p>
Change 27.5.2.1.6 [ios::Init]/4:
</p>

<blockquote>
<pre>~Init();
</pre>
<blockquote>
-4- <i>Effects:</i> Destroys an object of class <tt>Init</tt>.
<del>The function subtracts one from the value stored in <tt>init_cnt</tt> and,
if the resulting stored value is one,</del>
<ins>If there are no other instances of the class still in
existance,</ins>
calls <tt>cout.flush()</tt>,
<tt>cerr.flush()</tt>, <tt>clog.flush()</tt>, <tt>wcout.flush()</tt>,
<tt>wcerr.flush()</tt>, <tt>wclog.flush()</tt>.
</blockquote>
</blockquote>






<hr>
<h3><a name="1126"></a>1126. <tt>istreambuff_iterator::equal</tt> needs a const &amp; parameter</h3>
<p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>equal</tt> member function of <tt>istreambuf_iterator</tt> is
declared <tt>const</tt>, but takes its argument by non-const reference.
</p>
<p>
This is not compatible with the <tt>operator==</tt> free function overload, which is
defined in terms of calling <tt>equal</tt> yet takes both arguments by reference to
const.
</p>

<p><i>[
The proposed wording is consistent with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a> with status TC1.
]</i></p>


<p><i>[
2009-11-02 Howard adds:
]</i></p>


<blockquote>
Set to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Ammend in both:<br>
24.6.3 [istreambuf.iterator]<br>
24.6.3.5 [istreambuf.iterator::equal]<br>
</p>

<blockquote><pre>bool equal(<ins>const </ins>istreambuf_iterator&amp; b) const;
</pre></blockquote>






<hr>
<h3><a name="1130"></a>1130. <tt>copy_exception</tt> name misleading</h3>
<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-05-13 <b>Last modified:</b> 2010-10-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The naming of <tt>std::copy_exception</tt> misleads almost everyone
(experts included!) to think that it is the function that copies an
<tt>exception_ptr</tt>:
</p>

<blockquote><pre>exception_ptr p1 = current_exception();
exception_ptr p2 = copy_exception( p1 );
</pre></blockquote>

<p>
But this is not at all what it does. The above actually creates an
<tt>exception_ptr p2</tt> that contains a copy of <tt>p1</tt>, not of
the exception to which <tt>p1</tt> refers!
</p>
<p>
This is, of course, all my fault; in my defence, I used <tt>copy_exception</tt>
because I was unable to think of a better name.
</p>
<p>
But I believe that, based on what we've seen so far, <em>any</em> other name would be better.
</p>
<p>
Therefore, I propose <tt>copy_exception</tt> to be renamed to
<tt>create_exception</tt>:
</p>

<blockquote><pre>template&lt;class E&gt; exception_ptr create_exception(E e);
</pre></blockquote>

<p>
with the following explanatory paragraph after it:
</p>

<blockquote>
Creates an <tt>exception_ptr</tt> that refers to a copy of <tt>e</tt>.
</blockquote>

<p><i>[
2009-05-13 Daniel adds:
]</i></p>


<blockquote>
<p>
What about
</p>
<blockquote><pre>make_exception_ptr
</pre></blockquote>
<p>
in similarity to <tt>make_pair</tt> and <tt>make_tuple</tt>, <tt>make_error_code</tt> and
<tt>make_error_condition</tt>, or <tt>make_shared</tt>? Or, if a stronger symmetry to
<tt>current_exception</tt> is preferred:
</p>

<blockquote><pre>make_exception
</pre></blockquote>
<p>
We have not a single <tt>create_*</tt> function in the library, it was always
<tt>make_*</tt> used.
</p>
</blockquote>

<p><i>[
2009-05-13 Peter adds:
]</i></p>


<blockquote>
<tt>make_exception_ptr</tt> works for me.
</blockquote>

<p><i>[
2009-06-02 Thomas J. Gritzan adds:
]</i></p>


<blockquote>
<p>
To avoid surprises and unwanted recursion, how about making a call to
<tt>std::make_exception_ptr</tt> with an <tt>exception_ptr</tt> illegal?
</p>
<p>
It might work like this:
</p>
<blockquote><pre>template&lt;class E&gt;
exception_ptr make_exception_ptr(E e);
template&lt;&gt;
exception_ptr make_exception_ptr&lt;exception_ptr&gt;(exception_ptr e) = delete;
</pre></blockquote>
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to Review for the time being. The subgroup thinks this is a good
idea, but doesn't want to break compatibility unnecessarily if someone
is already shipping this. Let's talk to Benjamin and PJP tomorrow to
make sure neither objects.
</blockquote>

<p><i>[
2009-11-16 Jonathan Wakely adds:
]</i></p>


<blockquote>
GCC 4.4 shipped with <tt>copy_exception</tt> but we could certainly keep that
symbol in the library (but not the headers) so it can still be found
by any apps foolishly relying on the experimental C++0x mode being ABI
stable.
</blockquote>

<p><i>[
2009-11-16 Peter adopts wording supplied by Daniel.
]</i></p>


<p><i>[
2009-11-16 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change 18.8 [support.exception]/1, header <tt>&lt;exception&gt;</tt>
synopsis as indicated:
</p>

<blockquote><pre>exception_ptr current_exception();
void rethrow_exception [[noreturn]] (exception_ptr p);
template&lt;class E&gt; exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
</pre></blockquote>
</li>

<li>
<p>
Change 18.8.5 [propagation]:
</p>

<blockquote>
<pre>template&lt;class E&gt; exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
</pre>

<blockquote>
<p>
-11- <i>Effects:</i> <ins>Creates an <tt>exception_ptr</tt> that refers
to a copy of <tt>e</tt>,</ins> as if
</p>

<blockquote><pre>try {
  throw e;
} catch(...) {
  return current_exception();
}
</pre></blockquote>

<p>...</p>
</blockquote>

</blockquote>
</li>

<li>
<p>
Change 30.6.5 [futures.promise]/7 as indicated:
</p>

<blockquote>
<i>Effects:</i> if the associated state of <tt>*this</tt> is not ready, stores an exception
object of type <tt>future_error</tt> with an error code of <tt>broken_promise</tt> as if by
<tt>this-&gt;set_exception(<del>copy_exception</del><ins>make_exception_ptr</ins>(
future_error(future_errc::broken_promise))</tt>.  Destroys ...
</blockquote>
</li>
</ol>






<hr>
<h3><a name="1131"></a>1131. C++0x does not need <tt>alignment_of</tt></h3>
<p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>alignment_of</tt> template is no longer necessary, now that the
core language will provide <tt>alignof</tt>. Scott Meyers raised this
issue at comp.std.c++,
<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/9b020306e803f08a">C++0x: alignof vs. alignment_of</a>,
May 21, 2009.  In a reply, Daniel Kr�gler pointed out that
<tt>alignof</tt> was added to the working paper <i>after</i>
<tt>alignment_of</tt>. So it appears that <tt>alignment_of</tt> is only
part of the current Working Draft 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
because it is in TR1.
</p>
<p>
Having both <tt>alignof</tt> and <tt>alignment_of</tt> would cause
unwanted confusion. In general, I think TR1 functionality should not be
brought into C++0x if it is entirely redundant with other C++0x language
or library features.
</p>

<p><i>[
2009-11-16 Chris adds:
]</i></p>


<blockquote>
<p>
I would like to suggest the following new wording for this issue, based on
recent discussions. Basically this doesn't delete <tt>alignment_of</tt>, it just
makes it clear that it is just a wrapper for <tt>alignof</tt>. This deletes the
first part of the proposed resolution, changes the second part by leaving in
<tt>alignof(T)</tt> but changing the precondition and leaves the 3rd part
unchanged.
</p>

<p>
Suggested Resolution:
</p>

<blockquote>
<p>
Change the first row of Table 44 ("Type property queries"), from Type properties
20.7.4.3 [meta.unary.prop]:
</p>

<blockquote>
<table border="1">
<caption>Table 44 � Type property queries</caption>
<tbody><tr>
<td>
<tt>template &lt;class T&gt; struct alignment_of;</tt>
</td>
<td>
<tt>alignof(T)</tt>.<br>
<i>Precondition:</i> <del><tt>T</tt> shall be a complete type, a reference type,
or an array of unknown bound, but shall not be a function type or (possibly
cv-qualified) <tt>void</tt>.</del> <ins><tt>alignof(T)</tt> shall be defined</ins>
</td>
</tr>

</tbody></table>
</blockquote>

<p>
Change text in Table 51 ("Other transformations"), from Other transformations
20.7.7.6 [meta.trans.other], as follows:
</p>

<blockquote>
<table border="1">
<caption>Table 51 � Other transformations</caption>
<tbody><tr><td>...<tt>aligned_storage;</tt></td>
<td>
<tt>Len</tt> shall not be zero. <tt>Align</tt> shall be equal to
<tt><del>alignment_of&lt;T&gt;::value</del> <ins>alignof(T)</ins></tt> for some
type <tt>T</tt> or to <i>default-alignment</i>.
</td>
<td>...</td>
</tr></tbody></table>
</blockquote>
</blockquote>
</blockquote>

<p><i>[
2010-01-30 Alisdair proposes that Chris' wording be moved into the proposed wording
section and tweaks it on the way.
]</i></p>


<blockquote>
<p>
Original proposed wording saved here:
</p>
<blockquote>
<p>
Remove from Header &lt;type_traits&gt; synopsis 20.7.2 [meta.type.synop]:
</p>
<blockquote><pre><del>template &lt;class T&gt; struct alignment_of;</del>
</pre></blockquote>

<p>
Remove the first row of Table 44 ("Type property queries"), from
Type properties 20.7.4.3 [meta.unary.prop]:
</p>
<blockquote>
<table border="1">
<caption>Table 44 � Type property queries</caption>
<tbody><tr>
<td><del><tt>template &lt;class T&gt; struct alignment_of;</tt></del></td>
<td><del><tt>alignof(T)</tt>.</del><br>
<del><i>Precondition:</i> <tt>T</tt> shall be a complete type, a reference
type, or an array of unknown bound, but shall not be a function type or
(possibly cv-qualified) <tt>void</tt>.</del>
</td>
</tr>
</tbody></table>
</blockquote>

<p>
Change text in Table 51 ("Other transformations"), from Other
transformations 20.7.7.6 [meta.trans.other], as follows:
</p>
<blockquote>
<table border="1">
<caption>Table 51 � Other transformations</caption>
<tbody><tr><td>...<tt>aligned_storage;</tt></td>
<td>
<tt>Len</tt> shall not be zero.  Align shall be equal to
<tt><del>alignment_of&lt;T&gt;::value</del> <ins>alignof(T)</ins></tt> for some
type <tt>T</tt> or to <i>default-alignment</i>.
</td>
<td>...</td>
</tr></tbody></table>
</blockquote>
</blockquote>
</blockquote>

<p><i>[
2010-01-30 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Change the first row of Table 43 ("Type property queries"), from Type properties
20.7.4.3 [meta.unary.prop]:
</p>

<blockquote>
<table border="1">
<caption>Table 43 � Type property queries</caption>
<tbody><tr>
<td>
<tt>template &lt;class T&gt; struct alignment_of;</tt>
</td>
<td>
<tt>alignof(T)</tt>.<br>
<i>Precondition:</i> <del><tt>T</tt> shall be a complete type, a reference type,
or an array of unknown bound, but shall not be a function type or (possibly
cv-qualified) <tt>void</tt>.</del> <ins><tt>alignof(T)</tt> is a valid
expression (5.3.6 [expr.alignof])</ins>
</td>
</tr>

</tbody></table>
</blockquote>

<p>
Change text in Table 51 ("Other transformations"), from Other transformations
20.7.7.6 [meta.trans.other], as follows:
</p>

<blockquote>
<table border="1">
<caption>Table 51 � Other transformations</caption>
<tbody><tr><td>...<tt>aligned_storage;</tt></td>
<td>
<tt>Len</tt> shall not be zero. <tt>Align</tt> shall be equal to
<tt><del>alignment_of&lt;T&gt;::value</del> <ins>alignof(T)</ins></tt> for some
type <tt>T</tt> or to <i>default-alignment</i>.
</td>
<td>...</td>
</tr></tbody></table>
</blockquote>






<hr>
<h3><a name="1133"></a>1133. Does N2844 break current specification of list::splice?</h3>
<p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
IIUC,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
means that lvalues will no longer bind to rvalue references.
Therefore, the current specification of <tt>list::splice</tt> (list
operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing
programs.  That is because we changed the signature to swallow via an rvalue
reference rather than the lvalue reference used in 03.
</p>
<p>
Retaining this form would be safer, requiring an explicit move when splicing
from lvalues.  However, this will break existing programs.
We have the same problem with <tt>forward_list</tt>, although without the risk of
breaking programs so here it might be viewed as a positive feature.
</p>
<p>
The problem signatures:
</p>
<blockquote><pre>void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x);
void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
                  const_iterator i);
void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
                  const_iterator first, const_iterator last);

void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x);
void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
            const_iterator i);
void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
            const_iterator first, const_iterator last);
</pre></blockquote>

<b>Possible resolutions:</b>

<p>
Option A.   Add an additional (non-const) lvalue-reference
overload in each case
</p>
<p>
Option B.   Change rvalue reference back to (non-const)
lvalue-reference overload in each case
</p>
<p>
Option C.   Add an additional (non-const) lvalue-reference
overload in just the <tt>std::list</tt> cases
</p>
<p>
I think (B) would be very unfortunate, I really like the <tt>forward_list</tt>
behaviour in (C) but feel (A) is needed for consistency.
</p>
<p>
My actual preference would be NAD, ship with this as a breaking change as it
is a more explicit interface.  I don't think that will fly though!
</p>

<p>
See the thread starting with c++std-lib-23725 for more discussion.
</p>

<p><i>[
2009-10-27 Christopher Jefferson provides proposed wording for Option C.
]</i></p>


<p><i>[
2009-12-08 Jonathan Wakely adds:
]</i></p>


<blockquote>
<p>
As Bill Plauger pointed out, <tt>list::merge</tt> needs similar treatment.
</p>
<p><i>[
Wording updated.
]</i></p>

</blockquote>

<p><i>[
2009-12-13 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
In 23.3.4 [list]
</p>

<p>
Add lvalue overloads before rvalue ones:
</p>

<blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x);</ins>
void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
<ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x, const_iterator i);</ins>
void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
<ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x,
            const_iterator first, const_iterator last);</ins>
void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x,
            const_iterator first, const_iterator last);
<ins>void merge(list&lt;T,Allocator&gt;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp; x, Compare comp);</ins>
void merge(list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);

</pre></blockquote>

<p>
In 23.3.4.4 [list.ops], similarly add lvalue overload before each rvalue one:
</p>
<p>
(After paragraph 2)
</p>

<blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x);</ins>
void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
</pre></blockquote>

<p>
(After paragraph 6)
</p>

<blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x, const_iterator i);</ins>
void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, <ins>const_</ins>iterator i);
</pre></blockquote>

<p>
(After paragraph 10)
</p>

<blockquote><pre><ins>void splice(const_iterator position, list&lt;T,Allocator&gt;&amp; x,
            const_iterator first, const_iterator last);</ins>
void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x,
            <ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
</pre></blockquote>

<p>
In 23.3.4.4 [list.ops], after paragraph 21
</p>

<blockquote><pre><ins>void merge(list&lt;T,Allocator&gt;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp; x, Compare comp);</ins>
void merge(list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
</pre></blockquote>






<hr>
<h3><a name="1134"></a>1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h</h3>
<p><b>Section:</b> X [stdinth], X [fenv], 26.8 [c.math], X [cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-05-26 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This is probably editorial.
</p>
<p>
The following items should be removed from the draft, because they're
redundant with Annex D, and they arguably make some *.h headers
non-deprecated:
</p>
<p>
X [stdinth] (regarding <tt>&lt;stdint.h&gt;</tt>) 
</p>
<p>
X [fenv] (regarding <tt>&lt;fenv.h&gt;</tt>
</p>
<p>
Line 3 of 26.8 [c.math] (regarding <tt>&lt;tgmath.h&gt;</tt>) 
</p>
<p>
X [cmplxh] (regarding <tt>&lt;complex.h&gt;</tt>, though the note in this subclause is not redundant) 
</p>

<p><i>[
2009-06-10 Ganesh adds:
]</i></p>


<blockquote>
While searching for <tt>stdint</tt> in the CD, I found that <tt>&lt;stdint.h&gt;</tt> is also
mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to
<tt>&lt;cstdint&gt;</tt> instead.
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Real issue. Maybe just editorial, maybe not. Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Remove the section X [stdinth].
</p>
<p>
Remove the section X [fenv].
</p>
<p>
Remove 26.8 [c.math], p3:
</p>

<blockquote>
<del>-3- The header <tt>&lt;tgmath.h&gt;</tt> effectively includes the headers <tt>&lt;complex.h&gt;</tt>
and <tt>&lt;math.h&gt;</tt>.</del>
</blockquote>
<p>
Remove the section X [cmplxh].
</p>





<hr>
<h3><a name="1135"></a>1135. <tt>exception_ptr</tt> should support contextual conversion to <tt>bool</tt></h3>
<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2010-11-19</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
18.8.5 [propagation]/5, the implementation-defined type
<tt>exception_ptr</tt> does provide the following ways to check whether
it is a null value:
</p>
<blockquote><pre>void f(std::exception_ptr p) {
  p == nullptr;
  p == 0;
  p == exception_ptr();
}
</pre></blockquote>
<p>
This is rather cumbersome way of checking for the null value
and I suggest to require support for evaluation in a boolean
context like so:
</p>

<blockquote><pre>void g(std::exception_ptr p) {
  if (p) {}
  !p;
}
</pre></blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready. Note to editor: considering putting in a cross-reference
to 4 [conv], paragraph 3, which defines the phrase
"contextually converted to <tt>bool</tt>".
</blockquote>

<p><i>[
2010-03-14 Howard adds:
]</i></p>


<blockquote>
We moved
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
to the formal motions page in Pittsburgh which should obsolete this issue.  I've
moved this issue to NAD Editorial, solved by N3073.
</blockquote>



<p><b>Rationale:</b></p>
<p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6:
</p>

<blockquote>
<ins>
An object <tt>e</tt> of type <tt>exception_ptr</tt> can be contextually converted to <tt>bool</tt>.
The effect shall be as if <tt>e != exception_ptr()</tt> had been evaluated in place
of <tt>e</tt>. There shall be no implicit conversion to arithmetic type, to
enumeration type or to pointer type.
</ins>
</blockquote>





<hr>
<h3><a name="1136"></a>1136. Incomplete specification of <tt>nested_exception::rethrow_nested()</tt></h3>
<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It was recently mentioned in a newsgroup article
<a href="http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d">http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d</a>
that the specification of the member function <tt>rethrow_nested()</tt> of the
class <tt>nested_exception</tt> is incomplete, specifically it remains unclear
what happens, if member <tt>nested_ptr()</tt> returns a null value. In
18.8.6 [except.nested] we find only the following paragraph related to that:
</p>
<blockquote><pre>void rethrow_nested() const; // [[noreturn]]
</pre>
<blockquote>
-4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> object.
</blockquote>
</blockquote>
<p>
This is a problem, because it is possible to create an object of
<tt>nested_exception</tt> with exactly such a state, e.g.
</p>
<blockquote><pre>#include &lt;exception&gt;
#include &lt;iostream&gt;

int main() try {
  std::nested_exception e; // OK, calls current_exception() and stores it's null value
  e.rethrow_nested(); // ?
  std::cout &lt;&lt; "A" &lt;&lt; std::endl;
}
catch(...) {
  std::cout &lt;&lt; "B" &lt;&lt; std::endl;
}
</pre></blockquote>
<p>
I suggest to follow the proposal of the reporter, namely to invoke
<tt>terminate()</tt> if <tt>nested_ptr()</tt> return a null value of <tt>exception_ptr</tt> instead
of relying on the fallback position of undefined behavior. This would
be consistent to the behavior of a <tt>throw;</tt> statement when no
exception is being handled.
</p>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change around 18.8.6 [except.nested]/4 as indicated:
</p>
<blockquote>
<p>
-4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt>
object<ins>, if <tt>nested_ptr() != nullptr</tt></ins>
</p>
<p>
<ins>- <i>Remarks:</i> If <tt>nested_ptr() == nullptr</tt>, <tt>terminate()</tt>
shall be called.</ins>
</p>
</blockquote>





<hr>
<h3><a name="1137"></a>1137. Return type of <tt>conj</tt> and <tt>proj</tt></h3>
<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-11 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In clause 1, the Working Draft 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
specifies overloads of the
functions
</p>
<blockquote><pre>arg, conj, imag, norm, proj, real
</pre></blockquote>
<p>
for non-complex arithmetic types (<tt>float</tt>, <tt>double</tt>,
<tt>long double</tt>, and integers).
The only requirement (clause 2) specifies effective type promotion of arguments.
</p>
<p>
I strongly suggest to add the following requirement on the return types:
</p>
<blockquote>
All the specified overloads must return real (i.e., non-complex) values,
specifically, the nested <tt>value_type</tt> of effectively promoted arguments.
</blockquote>

<p>
(This has no effect on <tt>arg</tt>, <tt>imag</tt>, <tt>norm</tt>, <tt>real</tt>:
they are real-valued anyway.)
</p>
<p><b>Rationale:</b></p>
<p>
Mathematically, <tt>conj()</tt> and <tt>proj()</tt>, like the transcendental functions, are
complex-valued in general but map the (extended) real line to itself.
In fact, both functions act as identity on the reals.
A typical user will expect <tt>conj()</tt> and <tt>proj()</tt> to preserve this essential
mathematical property in the same way as <tt>exp()</tt>, <tt>sin()</tt>, etc.
A typical use of <tt>conj()</tt>, e.g., is the generic scalar product of n-vectors:
</p>

<blockquote><pre>template&lt;typename T&gt;
inline T
scalar_product(size_t n, T const* x, T const* y) {
  T result = 0;
  for (size_t i = 0; i &lt; n; ++i)
    result += x[i] * std::conj(y[i]);
  return result;
}
</pre></blockquote>
<p>
This will work equally well for real and complex floating-point types <tt>T</tt> if
<tt>conj()</tt> returns <tt>T</tt>. It will not work with real types if <tt>conj()</tt>
returns complex values.
</p>
<p>
Instead, the implementation of <tt>scalar_product</tt> becomes either less efficient
and less useful (if a complex result is always returned), or unnecessarily
complicated (if overloaded versions with proper return types are defined).
In the second case, the real-argument overload of <tt>conj()</tt> cannot be used.
In fact, it must be avoided.
</p>
<p>
Overloaded <tt>conj()</tt> and <tt>proj()</tt> are principally needed in generic programming.
All such use cases will benefit from the proposed return type requirement,
in a similar way as the <tt>scalar_product</tt> example.
The requirement will not harm use cases where a complex return value
is expected, because of implicit conversion to complex.
Without the proposed return type guarantee, I find overloaded versions
of <tt>conj()</tt> and <tt>proj()</tt> not only useless but actually troublesome.
</p>


<p><i>[
2009-11-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Insert a new paragraph after 26.4.9 [cmplx.over]/2:
</p>

<blockquote>
<ins>
All of the specified overloads shall have a return type which is the nested <tt>value_type</tt> of
the effectively cast arguments.
</ins>
</blockquote>





<hr>
<h3><a name="1138"></a>1138. unusual return value for operator+</h3>
<p><b>Section:</b> 21.4.8.1 [string::op+] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-06-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Many of the <tt>basic_string operator+</tt> overloads return an rvalue-reference.  Is
that really intended?
</p>
<p>
I'm considering it might be a mild performance tweak to avoid making
un-necessary copies of a cheaply movable type, but it opens risk to dangling
references in code like:
</p>

<blockquote><pre>auto &amp;&amp; s = string{"x"} + string{y};
</pre></blockquote>

<p>
and I'm not sure about:
</p>

<blockquote><pre>auto s = string{"x"} + string{y};
</pre></blockquote>

<p><i>[
2009-10-11 Howard updated <i>Returns:</i> clause for each of these.
]</i></p>


<p><i>[
2009-11-05 Howard adds:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Strike the <tt>&amp;&amp;</tt> from the return type in the following function
signatures:
</p>

<blockquote>
<p>
21.3 [string.classes] p2 Header Synopsis
</p>

<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
              const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);

template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);

template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);


template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(const charT* lhs,
              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);

template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);

template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
              const charT* rhs);

template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
</pre></blockquote>

<p>
21.4.8.1 [string::op+]
</p>

<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
              const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt>
</blockquote>
<pre>template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt>
</blockquote>
<pre>template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt> [<i>Note:</i> Or equivalently
<tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt> � <i>end note</i>]
</blockquote>
<pre>template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(const charT* lhs,
              basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, lhs)<ins>)</ins></tt>.
</blockquote>
<pre>template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt><ins>std::move(</ins>rhs.insert(0, 1, lhs)<ins>)</ins></tt>.
</blockquote>
<pre>template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
              const charT* rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(rhs)<ins>)</ins></tt>.
</blockquote>
<pre>template&lt;class charT, class traits, class Allocator&gt;
  basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
    operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt><ins>std::move(</ins>lhs.append(1, rhs)<ins>)</ins></tt>.
</blockquote>
</blockquote>

</blockquote>






<hr>
<h3><a name="1144"></a>1144. "thread safe" is undefined</h3>
<p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 187</b></p>

<p>
The term "thread safe" is not defined nor used in this context
anywhere else in the standard.
</p>

<p><b>Suggested action:</b></p>
<p>
Clarify the meaning of "thread safe".
</p>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
<p>
The "thread safe" language has already been change in the WP. It was
changed to "happen before", but the current WP text is still a little
incomplete: "happen before" is binary, but the current WP text only
mentions one thing.
</p>
<p>
Move to Ready.
</p>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
For the following functions in 18.5 [support.start.term].
</p>
<blockquote><pre><code>
extern "C" int at_quick_exit(void (*f)(void));
extern "C++" int at_quick_exit(void (*f)(void));
</code></pre></blockquote>

<p>
Edit paragraph 10 as follows.
The intent is
to provide the other half of the happens before relation;
to note indeterminate ordering;
and to clean up some formatting.
</p>
<blockquote><p>
<i>Effects:</i>
The <code>at_quick_exit()</code> functions
register the function pointed to by <code>f</code>
to be called without arguments when <code>quick_exit</code> is called.
It is unspecified whether a call to <code>at_quick_exit()</code>
that does not <del>happen-before</del> <ins>happen before</ins> (1.10)
<ins>all calls to <code>quick_exit</code></ins>
will succeed.
[<i>Note:</i>
the <code>at_quick_exit()</code> functions
shall not introduce a data race (17.6.4.7).
<del>exitnote</del>
<ins>�<i>end note</i>]</ins>
<ins>
[<i>Note:</i>
The order of registration may be indeterminate
if <code>at_quick_exit</code> was called from more than one thread.
�<i>end note</i>]
</ins>
[<i>Note:</i> The <code>at_quick_exit</code> registrations
are distinct from the <code>atexit</code> registrations,
and applications may need to call both registration functions
with the same argument.
�<i>end note</i>]
</p></blockquote>

<p>
For the following function.
</p>
<blockquote><pre><code>
void quick_exit [[noreturn]] (int status)
</code></pre></blockquote>

<p>
Edit paragraph 13 as follows.
The intent is to note that thread-local variables may be different.
</p>
<blockquote><p>
<i>Effects:</i>
Functions registered by calls to <code>at_quick_exit</code>
are called in the reverse order of their registration,
except that a function shall be called
after any previously registered functions
that had already been called at the time it was registered.
Objects shall not be destroyed as a result of calling <code>quick_exit</code>.
If control leaves a registered function called by <code>quick_exit</code>
because the function does not provide a handler for a thrown exception,
<code>terminate()</code> shall be called.
<ins>
[<i>Note:</i>
Functions registered by one thread may be called by any thread,
and hence should not rely on the identity of thread-storage-duration objects.
�<i>end note</i>]
</ins>
After calling registered functions,
<code>quick_exit</code> shall call <code>_Exit(status)</code>.
[<i>Note:</i>
The standard file buffers are not flushed.
See: ISO C 7.20.4.4.
�<i>end note</i>]
</p></blockquote>





<hr>
<h3><a name="1151"></a>1151. Behavior of the library in the presence of threads is incompletely specified</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-11-19</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US 63</b></p>

   <p><b>Description</b></p>
        <p>The behavior of the library in the presence of threads
        is incompletely specified.</p>
        <p>For example, if thread 1 assigns to <tt>X</tt>, then writes data
        to file <tt>f</tt>, which is read by thread 2, and then accesses
        variable <tt>X</tt>, is thread 2 guaranteed to be able to see the
        value assigned to <tt>X</tt> by thread 1? In other words, does the
        write of the data "happen before" the read?</p>
        <p>Another example: does simultaneous access using <tt>operator
        at()</tt> to different characters in the same non-const string
        really introduce a data race?</p>
<p><b>Suggestion</b></p>
<p><b>Notes</b></p><p>17 SG: should go to threads group; misclassified in document
</p>

    <p>Concurrency SG: Create an issue. Hans will look into it.</p>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to "Open". Hans and the rest of the concurrency working group will
study this. We can't make progress without a thorough review and a
paper.
</blockquote>

<p><i>[
2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3069.html">N3069</a>.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="1152"></a>1152. expressions parsed differently than intended</h3>
<p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2009-06-27 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Table 73 -- Floating-point conversions, 22.4.2.2.2 [facet.num.put.virtuals], 
in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
we have the following entries: 
</p>
<table border="1">
<caption>Table 73 � Floating-point conversions</caption>
<tbody><tr>
<th>State</th> <th><tt>stdio</tt> equivalent</th>
</tr>
<tr>
<td><tt>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase</tt></td>
<td align="center"><tt>%a</tt></td>
</tr>

<tr>
<td><tt>floatfield == ios_base::fixed | ios_base::scientific</tt></td>
<td align="center"><tt>%A</tt></td>
</tr>
</tbody></table>

<p>
These expressions are supposed to mean: 
</p>

<blockquote><pre>floatfield == (ios_base::fixed | ios_base::scientific) &amp;&amp; !uppercase 
floatfield == (ios_base::fixed | ios_base::scientific) 
</pre></blockquote>
<p>
but technically parsed as: 
</p>
<blockquote><pre>((floatfield == ios_base::fixed) | ios_base::scientific) &amp;&amp; (!uppercase) 
((floatfield == ios_base::fixed) | ios_base::scientific) 
</pre></blockquote>
<p>
and should be corrected with additional parentheses, as shown above. 
</p>

<p><i>[
2009-10-28 Howard:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change Table 83 � Floating-point conversions in  22.4.2.2.2 [facet.num.put.virtuals]:
</p>

<table border="1">
<caption>Table 83 � Floating-point conversions</caption>
<tbody><tr>
<th>State</th> <th><tt>stdio</tt> equivalent</th>
</tr>
<tr>
<td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins> &amp;&amp; !uppercase</tt></td>
<td align="center"><tt>%a</tt></td>
</tr>

<tr>
<td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins></tt></td>
<td align="center"><tt>%A</tt></td>
</tr>
</tbody></table>





<hr>
<h3><a name="1157"></a>1157. Local types can now instantiate templates</h3>
<p><b>Section:</b> 17.6.3.2.1 [namespace.std] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 175</b></p>

<p><b>Description</b></p>
        <p>Local types can
        now be used to instantiate templates, but don't have
        external linkage.</p>
<p><b>Suggestion</b></p>
        <p>Remove the reference to external linkage.</p>

<p><b>Notes</b></p>
<p>We accept the proposed solution. Martin will draft an issue.</p>

<p><i>[
2009-07-28 Alisdair provided wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
17.6.3.2.1 [namespace.std]
</p>
<p>
Strike "of external linkage" in p1 and p2:
</p>

<blockquote>
<p>
-1- The behavior of a C++ program is undefined if it adds declarations or
definitions to namespace <tt>std</tt> or to a namespace within namespace <tt>std</tt>
unless otherwise specified. A program may add a concept map for any
standard library concept or a template specialization for any standard
library template to namespace <tt>std</tt> only if the declaration depends on a
user-defined type <del>of external linkage</del> and the specialization meets the
standard library requirements for the original template and is not
explicitly prohibited.<sup>179</sup>
</p>

<p>
-2- The behavior of a C++ program is undefined if it declares
</p>
<ul>
<li>
an explicit specialization of any member function of a standard library
class template, or
</li>
<li>
an explicit specialization of any member function template of a standard
library class or class template, or
</li>
<li>
an explicit or partial specialization of any member class template of a
standard library class or class template.
</li>
</ul>
<p>
A program may explicitly instantiate a template defined in the standard
library only if the declaration depends on the name of a user-defined
type <del>of external linkage</del> and the instantiation meets the standard
library requirements for the original template.
</p>
</blockquote>






<hr>
<h3><a name="1158"></a>1158. Encouragement to use monotonic clock</h3>
<p><b>Section:</b> 30.2.4 [thread.req.timing] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.req.timing">issues</a> in [thread.req.timing].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 322, US 96</b></p>

<p><b>Description</b></p>
        <p>Not all systems
        can provide a monotonic clock. How are they expected to
        treat a _for function?</p>
<p><b>Suggestion</b></p>
        <p>Add at least a note explaining the intent
        for systems that do not support a monotonic clock.</p>

<p><b>Notes</b></p>
<p>Create an issue, together with UK 96. Note that the specification as is 
    already allows a non-monotonic clock due to the word �should� rather than 
    �shall�. If this wording is kept, a footnote should be added to make the 
    meaning clear.</p>

<p><i>[ 2009-06-29 Beman provided a proposed resolution. ] </i></p>

<p><i>[
2009-10-31 Howard adds:
]</i></p>


<blockquote>
Set to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
2010-02-24 Pete moved to Open:
]</i></p>


<blockquote>
LWG 1158's proposed resolution replaces the ISO-specified normative term
"should" with "are encouraged but not required to", which presumably means the
same thing, but has no ISO normative status. The WD used the latter formulation
in quite a few non-normative places, but only three normative ones. I've changed
all the normative uses to "should".
</blockquote>

<p><i>[
2010-03-06 Beman updates wording.
]</i></p>


<p><i>[
2010 Pittsburgh:  Moved to Ready.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>Change Timing specifications 30.2.4 [thread.req.timing] as indicated:</i></p>

<p>
The member functions whose names end in <tt>_for</tt> take an argument that
specifies a relative time. Implementations should use a monotonic clock to
measure time for these functions.  <ins>[<i>Note:</i> Implementations are not
required to use a monotonic clock because such a clock may be unavailable.
� <i>end note</i>]</ins>
</p>






<hr>
<h3><a name="1159"></a>1159. Unclear spec for <tt>resource_deadlock_would_occur</tt></h3>
<p><b>Section:</b> 30.4.2.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a></p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 327, UK 328</b></p>

<p><b>UK 327 Description</b></p>
        <p>Not clear what
        the specification for error condition
        <tt>resource_deadlock_would_occur</tt> means. It is perfectly
        possible for this thread to own the mutex without setting
        owns to true on this specific lock object. It is also
        possible for lock operations to succeed even if the thread
        does own the mutex, if the mutex is recursive. Likewise, if
        the mutex is not recursive and the mutex has been locked
        externally, it is not always possible to know that this
        error condition should be raised, depending on the host
        operating system facilities. It is possible that 'i.e.' was
        supposed to be 'e.g.' and that suggests that recursive
        locks are not allowed. That makes sense, as the
        exposition-only member owns is boolean and not a integer to
        count recursive locks.</p>
        
<p><b>UK 327 Suggestion</b></p>
        <p>Add a precondition <tt>!owns</tt>. Change the 'i.e.'
        in the error condition to be 'e.g.' to allow for this
        condition to propogate deadlock detection by the host OS.</p>
<p><b>UK 327 Notes</b></p>
<p>Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock 
    means for recursive locks when you are the owner. POSIX has language on 
    this, which should ideally be followed. Proposed fix is not quite right, for 
    example, try_lock should have different wording from lock.</p>

<p><b>UK 328 Description</b></p>

        <p>There is a missing precondition that <tt>owns</tt>
        is true, or an <tt>if(owns)</tt> test is missing from the effect
        clause</p>
<p><b>UK 328 Suggestion</b></p>
        <p>Add a
        precondition that <tt>owns == true</tt>. Add an error condition to
        detect a violation, rather than yield undefined behaviour.</p>
<p><b>UK 328 Notes</b></p>
<p>Handle in same issue as UK 327. Also uncertain that the proposed resolution 
    is the correct one.</p>

<p><i>[
2009-11-11 Alisdair notes that this issue is very closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1219">1219</a>,
if not a dup.
]</i></p>


<p><i>[
2010-02-12 Anthony provided wording.
]</i></p>


<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
Wording updated and moved to Ready for Pittsburgh.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Modify 30.4.2.2.2 [thread.lock.unique.locking] p3 to say:
</p>

<blockquote>
<pre>void lock();</pre>
<blockquote>
<p>...</p>
<p>
3 <i>Throws:</i> <ins>Any exception thrown by <tt>pm-&gt;lock()</tt>.
<tt>std::system_error</tt> if an exception is required (30.2.2 [thread.req.exception]).
<tt>std::system_error</tt> with an error condition of
<tt>operation_not_permitted</tt> if <tt>pm</tt> is <tt>0</tt>.
<tt>std::system_error</tt> with an error condition of
<tt>resource_deadlock_would_occur</tt> if on entry <tt>owns</tt> is <tt>true</tt>.</ins>
<del><tt>std::system_error</tt> when the
postcondition cannot be achieved.</del>
</p>
</blockquote>
</blockquote>

<p>
Remove 30.4.2.2.2 [thread.lock.unique.locking] p4 (Error condition clause).
</p>

<p>
Modify 30.4.2.2.2 [thread.lock.unique.locking] p8 to say:
</p>

<blockquote>
<pre>bool try_lock();</pre>
<blockquote>
<p>...</p>
<p>
8 <i>Throws:</i> <ins>Any exception thrown by <tt>pm-&gt;try_lock()</tt>.
<tt>std::system_error</tt> if an exception is required (30.2.2 [thread.req.exception]).
<tt>std::system_error</tt> with an error condition of
<tt>operation_not_permitted</tt> if <tt>pm</tt> is <tt>0</tt>.
<tt>std::system_error</tt> with an error condition of
<tt>resource_deadlock_would_occur</tt> if on entry <tt>owns</tt> is <tt>true</tt>.</ins>
<del><tt>std::system_error</tt> when the
postcondition cannot be achieved.</del>
</p>
</blockquote>
</blockquote>

<p>
Remove 30.4.2.2.2 [thread.lock.unique.locking] p9 (Error condition clause).
</p>

<p>
Modify 30.4.2.2.2 [thread.lock.unique.locking] p13 to say:
</p>

<blockquote>
<pre>template &lt;class Clock, class Duration&gt;
  bool try_lock_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);</pre>
<blockquote>
<p>...</p>
<p>
13 <i>Throws:</i> <ins>Any exception thrown by <tt>pm-&gt;try_lock_until()</tt>.
<tt>std::system_error</tt> if an exception is required (30.2.2 [thread.req.exception]).
<tt>std::system_error</tt> with an error condition of
<tt>operation_not_permitted</tt> if <tt>pm</tt> is <tt>0</tt>.
<tt>std::system_error</tt> with an error condition of
<tt>resource_deadlock_would_occur</tt> if on entry <tt>owns</tt> is <tt>true</tt>.</ins>
<del><tt>std::system_error</tt> when the
postcondition cannot be achieved.</del>
</p>
</blockquote>
</blockquote>

<p>
Remove 30.4.2.2.2 [thread.lock.unique.locking] p14 (Error condition clause).
</p>

<p>
Modify 30.4.2.2.2 [thread.lock.unique.locking] p18 to say:
</p>

<blockquote>
<pre>template &lt;class Rep, class Period&gt;
  bool try_lock_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
<blockquote>
<p>...</p>
<p>
18 <i>Throws:</i> <ins>Any exception thrown by <tt>pm-&gt;try_lock_for()</tt>.
<tt>std::system_error</tt> if an exception is required (30.2.2 [thread.req.exception]).
<tt>std::system_error</tt> with an error condition of
<tt>operation_not_permitted</tt> if <tt>pm</tt> is <tt>0</tt>.
<tt>std::system_error</tt> with an error condition of
<tt>resource_deadlock_would_occur</tt> if on entry <tt>owns</tt> is <tt>true</tt>.</ins>
<del><tt>std::system_error</tt> when the
postcondition cannot be achieved.</del>
</p>
</blockquote>
</blockquote>

<p>
Remove 30.4.2.2.2 [thread.lock.unique.locking] p19 (Error condition clause).
</p>






<hr>
<h3><a name="1170"></a>1170. String <i>char-like types</i> no longer PODs</h3>
<p><b>Section:</b> 21.1 [strings.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-22 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p><b>Addresses UK 218</b></p>

<p>Prior to the introduction of constant expressions into the library, 
<tt>basic_string</tt> elements had to be POD types, and thus had to be both trivially 
copyable and standard-layout. This ensured that they could be memcpy'ed and 
would be compatible with other libraries and languages, particularly the C 
language and its library.</p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>,
Constant Expressions in the Standard Library Revision 2, changed the 
requirement in 21/1 from "POD type" to "literal type". That change had the 
effect of removing the trivially copyable and standard-layout requirements from 
<tt>basic_string</tt> elements.</p>
<p>This means that <tt>basic_string</tt> elements no longer are guaranteed to be 
memcpy'able, and are no longer guaranteed to be standard-layout types:</p>
<blockquote>
  <p>3.9/p2 and 3.9/p3 both make it clear that a "trivially copyable type" is 
  required for memcpy to be guaranteed to work.</p>
  <p>Literal types (3.9p12) may have a non-trivial copy assignment operator, and 
  that violates the trivially copyable requirements given in 9/p 6, bullet item 
  2. </p>
  <p>Literal types (3.9p12) have no standard-layout requirement, either.</p>
</blockquote>
<p>This situation probably arose because the wording for "Constant Expressions 
in the Standard Library" was in process at the same time the C++ POD 
deconstruction wording was in process. </p>
<p>Since trivially copyable types meet the C++0x requirements for literal types, 
and thus work with constant expressions, it seems an easy fix to revert the 
<tt>basic_string</tt> element wording to its original state.</p>

 <p><i>[
 2009-07-28 Alisdair adds:
 ]</i></p>

 
<blockquote>
When looking for any resolution for this issue, consider the definition of
"character container type" in 17.3.5 [defns.character.container].  This
does require the character type to be a POD, and this term is used in a
number of places through clause 21 and 28. This suggests the PODness
constraint remains, but is much more subtle than before.  Meanwhile, I
suspect the change from POD type to literal type was intentional with
the assumption that trivially copyable types with
non-trivial-but-constexpr constructors should serve as well.  I don't
believe the current wording offers the right guarantees for either of
the above designs.
</blockquote>

<p><i>[
2009-11-04 Howard modifies proposed wording to disallow array types as
char-like types.
]</i></p>


<p><i>[
2010-01-23 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>Change General 21.1 [strings.general] as indicated:</i></p>
<blockquote>
<p>This Clause describes components for manipulating sequences of any
<del>literal</del> <ins>non-array POD</ins> (3.9) type. In this Clause
such types are called <i>char-like types</i>, and objects of char-like
types are called <i>char-like objects</i> or simply
<i>characters</i>.</p>
</blockquote>






<hr>
<h3><a name="1171"></a>1171. duration types should be literal</h3>
<p><b>Section:</b> 20.11.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-06 <b>Last modified:</b> 2010-11-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>duration</tt> types in 20.11.3 [time.duration] are exactly the sort of type
that should be "literal types" in the new standard.  Likewise,
arithmetic operations on <tt>duration</tt>s should be declared <tt>constexpr</tt>.
</p>

<p><i>[
2009-09-21 Daniel adds:
]</i></p>


<blockquote>
An alternative (and possibly preferable solution for potentially
heap-allocating big_int representation types) would be to ask the core
language to allow references to <tt>const</tt> literal types as feasible
arguments for <tt>constexpr</tt> functions.
</blockquote>

<p><i>[
2009-10-30 Alisdair adds:
]</i></p>


<blockquote>
<p>
I suggest this issue moves from New to Open.
</p>

<p>
Half of this issue was dealt with in paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">n2994</a>
on constexpr constructors.
</p>

<p>
The other half (duration arithmetic) is on hold pending Core support for
<tt>const &amp;</tt> in <tt>constexpr</tt> functions.
</p>

</blockquote>

<p><i>[
2010-03-15 Alisdair updated wording to be consistent with
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3078.html">N3078</a>.
]</i></p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote>
This issue was the motivation for Core adding the facility for <tt>constexpr</tt> functions to take parameters by <tt>const &amp;</tt>.

Move to Tentatively Ready.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add <tt>constexpr</tt> to declaration of following functions and constructors:
</p>
<p>
Modify p1 20.11 [time], and the prototype definitions in 20.11.3.5 [time.duration.nonmember], 20.11.3.6 [time.duration.comparisons],
and 20.11.3.7 [time.duration.cast]:
</p>

<blockquote>
<p>
<b>Header <tt>&lt;chrono&gt;</tt> synopsis</b>
</p>

<pre><i>// duration arithmetic</i>
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
   <ins>constexpr</ins> operator+(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
   <ins>constexpr</ins> operator-(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period, class Rep2&gt;
   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
   <ins>constexpr</ins> operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
template &lt;class Rep1, class Period, class Rep2&gt;
   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
   <ins>constexpr</ins> operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
template &lt;class Rep1, class Period, class Rep2&gt;
   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
   <ins>constexpr</ins> operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   typename common_type&lt;Rep1, Rep2&gt;::type
   <ins>constexpr</ins> operator/(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);

<i>// duration comparisons</i>
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator==(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator!=(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator&lt; (const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator&lt;=(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator&gt; (const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
   <ins>constexpr</ins> bool operator&gt;=(const  duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);

<i>// duration_cast</i>
template &lt;class ToDuration, class Rep, class Period&gt;
   <ins>constexpr</ins> ToDuration duration_cast(const duration&lt;Rep, Period&gt;&amp; d);
</pre>

</blockquote>

<p>
Change 20.11.3 [time.duration]:
</p>

<blockquote>

<pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
class duration {
  ...
public:
  ...
  <ins>constexpr</ins> duration(const duration&amp;) = default;
  ...

};
</pre>
</blockquote>
<p><i>[
Note - this edit already seems assumed by definition of the duration static members <tt>zero/min/max</tt>.
They cannot meaningfully be <tt>constexpr</tt> without this change.
]</i></p>






<hr>
<h3><a name="1174"></a>1174. type property predicates</h3>
<p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2009-07-16 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I've been implementing compiler support for <tt>is_standard_layout</tt>, and
noticed a few nits about 20.7.4.3 [meta.unary.prop]:
</p>

<ol>
<li>
There's no trait for "trivially copyable type", which is now the
property that lets you do bitwise copying of a type, and therefore seems
useful to be able to query.  <tt>has_trivial_assign</tt> &amp;&amp;
<tt>has_trivial_copy_constructor</tt> &amp;&amp; <tt>has_trivial_destructor</tt>
is similar, but
not identical, specifically with respect to const types.
</li>
<li>
<tt>has_trivial_copy_constructor</tt> and <tt>has_trivial_assign</tt> lack the "or an
array of such a class type" language that most other traits in that
section, including <tt>has_nothrow_copy_constructor</tt> and <tt>has_nothrow_assign</tt>,
have; this seems like an oversight.
</li>
</ol>

<p><i>[
See the thread starting with c++std-lib-24420 for further discussion.
]</i></p>


<p><i>[
Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
<del>NAD Editorial</del><ins>Resolved</ins>.  Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
</p>





<hr>
<h3><a name="1177"></a>1177. Improve "diagnostic required" wording</h3>
<p><b>Section:</b> 20.11.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
"diagnostic required" has been used (by me) for code words meaning "use
<tt>enable_if</tt> to constrain templated functions.  This needs to be
improved by referring to the function signature as not participating in
the overload set, and moving this wording to a <i>Remarks</i> paragraph.
</p>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>

<p><i>[
2009-11-19 Pete opens:
]</i></p>


<blockquote>
<p>
Oh, and speaking of 1177, most of the changes result in rather convoluted prose.
Instead of saying
</p>

<blockquote>
A shall be B, else C
</blockquote>

<p>
it should be
</p>

<blockquote>
C if A is not B
</blockquote>

<p>
That is:
</p>

<blockquote>
<tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>, else
this signature shall not participate in overload resolution.
</blockquote>

<p>
should be
</p>

<blockquote>
This signature shall not participate in overload resolution if <tt>Rep2</tt> is
not implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.
</blockquote>

<p>
That is clearer, and eliminates the false requirement that <tt>Rep2</tt> "shall
be" convertible.
</p>

</blockquote>

<p><i>[
2009-11-19 Howard adds:
]</i></p>


<blockquote>
I've updated the wording to match Pete's suggestion and included bullet 16
from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1195">1195</a>.
</blockquote>

<p><i>[
2009-11-19 Jens adds:
]</i></p>


<blockquote>
<p>
Further wording suggestion using "unless":
</p>

<blockquote>
This signature shall not participate in overload resolution unless <tt>Rep2</tt>
is implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.
</blockquote>
</blockquote>

<p><i>[
2009-11-20 Howard adds:
]</i></p>


<blockquote>
I've updated the wording to match Jens' suggestion.
</blockquote>

<p><i>[
2009-11-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>[
This proposed resolution addresses <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#947">947</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#974">974</a>. 
]</i></p>


<ol>
<li>
<p>
Change 20.11.3.1 [time.duration.cons] (and reorder the <i>Remarks</i>
paragraphs per 17.5.1.4 [structure.specifications]):
</p>

<blockquote>
<pre>template &lt;class Rep2&gt; 
  explicit duration(const Rep2&amp; r);
</pre>
<blockquote>
<p>
<i><del>Requires:</del> <ins>Remarks:</ins></i> <ins>This constructor shall not
participate in overload resolution unless</ins> <tt>Rep2</tt> <del>shall be</del>
<ins>is</ins> implicitly convertible to <tt>rep</tt> and
</p>
<ul>
<li>
<tt>treat_as_floating_point&lt;rep&gt;::value</tt> <del>shall be</del>
<ins>is</ins> <tt>true</tt><ins>,</ins> or
</li>
<li>
<tt>treat_as_floating_point&lt;Rep2&gt;::value</tt> <del>shall be</del>
<ins>is</ins> <tt>false</tt>.
</li>
</ul>
<p>
<del>Diagnostic required</del> [<i>Example:</i>
</p>
<blockquote><pre>duration&lt;int, milli&gt; d(3); // OK 
duration&lt;int, milli&gt; d(3.5); // error 
</pre></blockquote>

<p>
� <i>end example</i>]
</p>

<p>
<i>Effects:</i> Constructs an object of type <tt>duration</tt>.
</p>

<p>
<i>Postcondition:</i> <tt>count() == static_cast&lt;rep&gt;(r)</tt>.
</p>

</blockquote>

<pre>template &lt;class Rep2, class Period2&gt;
  duration(const duration&lt;Rep2, Period2&gt;&amp; d);
</pre>
<blockquote>
<p>
<i><del>Requires:</del> <ins>Remarks:</ins></i> <ins>This constructor shall not
participate in overload resolution unless</ins>
<tt>treat_as_floating_point&lt;rep&gt;::value</tt> <del>shall be</del>
<ins>is</ins> <tt>true</tt> or <tt>ratio_divide&lt;Period2,
period&gt;::type::den</tt> <del>shall be</del> <ins>is</ins> 1. <del>Diagnostic
required.</del> [<i>Note:</i> This requirement prevents implicit truncation
error when converting between integral-based duration types. Such a construction
could easily lead to confusion about the value of the duration. � <i>end
note</i>] [<i>Example:</i>
</p>

<blockquote><pre>duration&lt;int, milli&gt; ms(3); 
duration&lt;int, micro&gt; us = ms; // OK 
duration&lt;int, milli&gt; ms2 = us; // error 
</pre></blockquote>

<p>
� <i>end example</i>]
</p>

<p>
<i>Effects:</i> Constructs an object of type <tt>duration</tt>, constructing
<tt>rep_</tt> from
<tt>duration_cast&lt;duration&gt;(d).count()</tt>.
</p>

</blockquote>


</blockquote>
</li>

<li>
<p>
Change the following paragraphs in 20.11.3.5 [time.duration.nonmember]:
</p>

<blockquote>
<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
  operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This operator shall not
participate in overload resolution unless</ins> <tt>Rep2</tt> <del>shall
be</del> <ins>is</ins> implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.
<del>Diagnostic required.</del>
</blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
  operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
</pre>
<blockquote>
<i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This operator shall not
participate in overload resolution unless</ins> <tt>Rep1</tt> <del>shall
be</del> <ins>is</ins> implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.
<del>Diagnostic required.</del>
</blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
  operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This operator shall not
participate in overload resolution unless</ins> <tt>Rep2</tt> <del>shall
be</del> <ins>is</ins> implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
<tt>Rep2</tt> <del>shall not be</del> <ins>is not</ins> an instantiation of
<tt>duration</tt>. <del>Diagnostic required.</del>
</blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt; 
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt; 
  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This operator shall not
participate in overload resolution unless</ins> <tt>Rep2</tt> <del>shall
be</del> <ins>is</ins> implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
<tt>Rep2</tt> <del>shall not be</del> <ins>is not</ins> an instantiation of
<tt>duration</tt>. <del>Diagnostic required.</del>
</blockquote>

</blockquote>
</li>

<li>
<p>
Change the following paragraphs in 20.11.3.7 [time.duration.cast]:
</p>

<blockquote><pre>template &lt;class ToDuration, class Rep, class Period&gt; 
  ToDuration duration_cast(const duration&lt;Rep, Period&gt;&amp; d);
</pre>

<blockquote>
<i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This function shall not
participate in overload resolution unless</ins> <tt>ToDuration</tt> <del>shall
be</del> <ins>is</ins> an instantiation of <tt>duration</tt>. <del>Diagnostic
required.</del>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.11.4.1 [time.point.cons]/3 as indicated:
</p>

<blockquote>
<p>
<del><i>Requires:</i> <tt>Duration2</tt> shall be implicitly convertible to <tt>duration</tt>.
Diagnostic required.</del>
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>Duration2</tt> is implicitly convertible to
<tt>duration</tt>.</ins>
</p>
</blockquote>

</li>

<li>
<p>
Change the following paragraphs in 20.11.4.7 [time.point.cast]:
</p>

<blockquote><pre>template &lt;class ToDuration, class Clock, class Duration&gt; 
  time_point&lt;Clock, ToDuration&gt; time_point_cast(const time_point&lt;Clock, Duration&gt;&amp; t);
</pre>

<blockquote>
<i><del>Requires</del> <ins>Remarks</ins>:</i> <ins>This function shall not
participate in overload resolution unless</ins> <tt>ToDuration</tt> <del>shall
be</del> <ins>is</ins> an instantiation of <tt>duration</tt>. <del>Diagnostic
required.</del>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="1178"></a>1178. Header dependencies</h3>
<p><b>Section:</b> 17.6.4.2 [res.on.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-07-18 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See Frankfurt notes of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>

<blockquote>

<p>
A C++ header may include other C++
headers.<del><sup>[footnote]</sup></del> <ins>A C++ header shall provide
the declarations and definitions that appear in its synopsis
(3.2 [basic.def.odr]). A C++ header shown in its synopsis as including 
other C++ headers shall provide the declarations and definitions that appear in
the synopses of those other headers.</ins>
</p>

  <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains 
  any needed definition (3.2).</del></p>
</blockquote>






<hr>
<h3><a name="1180"></a>1180. Missing string_type member typedef in class <tt>sub_match</tt></h3>
<p><b>Section:</b> 28.9.1 [re.submatch.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-07-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The definition of class template <tt>sub_match</tt> is strongly dependent
on the type <tt>basic_string&lt;value_type&gt;</tt>, both in interface and effects,
but does not provide a corresponding typedef <tt>string_type</tt>, as e.g.
class <tt>match_results</tt> does, which looks like an oversight to me that
should be fixed.
</p>

<p><i>[
2009-11-15 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>

<ol>
<li>
<p>
In the class template <tt>sub_match</tt> synopsis 28.9 [re.submatch]/1
change as indicated:
</p>

<blockquote><pre>template &lt;class BidirectionalIterator&gt;
class sub_match : public std::pair&lt;BidirectionalIterator, BidirectionalIterator&gt; {
public:
  typedef typename iterator_traits&lt;BidirectionalIterator&gt;::value_type value_type;
  typedef typename iterator_traits&lt;BidirectionalIterator&gt;::difference_type difference_type;
  typedef BidirectionalIterator iterator;
  <ins>typedef basic_string&lt;value_type&gt; string_type;</ins>

  bool matched;

  difference_type length() const;
  operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
  <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
  int compare(const sub_match&amp; s) const;
  int compare(const <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>&amp; s) const;
  int compare(const value_type* s) const;
};
</pre></blockquote>
</li>

<li>
<p>
In 28.9.1 [re.submatch.members]/2 change as indicated:
</p>

<blockquote><pre>operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
</pre>

<blockquote>
<i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
<ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
<ins>string_type</ins>()</tt>.
</blockquote>
</blockquote>
</li>

<li>
<p>
In 28.9.1 [re.submatch.members]/3 change as indicated:
</p>

<blockquote><pre><del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
</pre>

<blockquote>
<i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
<ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
<ins>string_type</ins>()</tt>.
</blockquote>
</blockquote>
</li>

<li>
<p>
In 28.9.1 [re.submatch.members]/5 change as indicated:
</p>

<blockquote><pre>int compare(const <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>&amp; s) const;
</pre></blockquote>
</li>
</ol>






<hr>
<h3><a name="1181"></a>1181. Invalid <tt>sub_match</tt> comparison operators</h3>
<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-07-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Several heterogeneous comparison operators of class template
<tt>sub_match</tt> are specified by return clauses that are not valid
in general. E.g. 28.9.2 [re.submatch.op]/7:
</p>

<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
bool operator==(
  const basic_string&lt;
    typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
  const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt>lhs == rhs.str()</tt>.
</blockquote>
</blockquote>

<p>
The returns clause would be ill-formed for all cases where
<tt>ST != std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;</tt>
or <tt>SA != std::allocator&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;</tt>.
</p>
<p>
The generic character of the comparison was intended, so
there are basically two approaches to fix the problem: The
first one would define the semantics of the comparison
using the traits class <tt>ST</tt> (The semantic of <tt>basic_string::compare</tt>
is defined in terms of the compare function of the corresponding
traits class), the second one would define the semantics of the
comparison using the traits class
</p>

<blockquote><pre>std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;
</pre></blockquote>

<p>
which is essentially identical to
</p>

<blockquote><pre>std::char_traits&lt;sub_match&lt;BiIter&gt;::value_type&gt;
</pre></blockquote>

<p>
I suggest to follow the second approach, because
this emphasizes the central role of the <tt>sub_match</tt>
object as part of the comparison and would also
make sure that a <tt>sub_match</tt> comparison using some
<tt>basic_string&lt;char_t, ..&gt;</tt> always is equivalent to
a corresponding comparison with a string literal
because of the existence of further overloads (beginning
from 28.9.2 [re.submatch.op]/19). If users really want to
take advantage of their own <tt>traits::compare</tt>, they can
simply write a corresponding compare function that
does so.
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<p>
The following update is a result of the discussion during the Rapperswil meeting, the P/R expresses all comparisons by 
delegating to sub_match's compare functions. The processing is rather mechanical: Only <tt>==</tt> and <tt>&lt;</tt>
where defined by referring to <tt>sub_match</tt>'s compare function, all remaining ones where replaced by the canonical
definitions in terms of these two.
</p>

<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
<i>The wording refers to N3126.</i>
</p>

<ol>
<li>Change 28.9.2 [re.submatch.op]/7 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator==(
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
7 <em>Returns</em>: <tt><del>lhs == rhs.str()</del><ins>rhs.compare(lhs.c_str()) == 0</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/8 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator!=(
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
8 <em>Returns</em>: <tt><del>lhs != rhs.str()</del><ins>!(lhs == rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/9 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator&lt;(
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
9 <em>Returns</em>: <tt><del>lhs &lt; rhs.str()</del><ins>rhs.compare(lhs.c_str()) &gt; 0</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/10 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator&gt;(
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
10 <em>Returns</em>: <tt><del>lhs &gt; rhs.str()</del><ins>rhs &lt; lhs</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/11 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator&gt;=(
   const basic_string&lt;
   typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
 const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
11 <em>Returns</em>: <tt><del>lhs &gt;= rhs.str()</del><ins>!(lhs &lt; rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/12 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator&lt;=(
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
12 <em>Returns</em>: <tt><del>lhs &lt;= rhs.str()</del><ins>!(rhs &lt; lhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/13 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>
13 <em>Returns</em>: <tt><del>lhs.str() == rhs</del><ins>lhs.compare(rhs.c_str()) == 0</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/14 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>
14 <em>Returns</em>: <tt><del>lhs.str() != rhs</del><ins>!(lhs == rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/15 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>
15 <em>Returns</em>: <tt><del>lhs.str() &lt; rhs</del><ins>lhs.compare(rhs.c_str()) &lt; 0</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/16 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>
16 <em>Returns</em>: <tt><del>lhs.str() &gt; rhs</del><ins>rhs &lt; lhs</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/17 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>
17 <em>Returns</em>: <tt><del>lhs.str() &gt;= rhs</del><ins>!(lhs &lt; rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/18 as indicated:
<blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
 bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
   const basic_string&lt;
     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
</pre>
18 <em>Returns</em>: <tt><del>lhs.str() &lt;= rhs</del><ins>!(rhs &lt; lhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/19 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
19 <em>Returns</em>: <tt><del>lhs == rhs.str()</del><ins>rhs.compare(lhs) == 0</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/20 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator!=(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
20 <em>Returns</em>: <tt><del>lhs != rhs.str()</del><ins>!(lhs == rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/21 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&lt;(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
21 <em>Returns</em>: <tt><del>lhs &lt; rhs.str()</del><ins>rhs.compare(lhs) &gt; 0</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/22 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&gt;(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
22 <em>Returns</em>: <tt><del>lhs &gt; rhs.str()</del><ins>rhs &lt; lhs</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/23 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&gt;=(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
23 <em>Returns</em>: <tt><del>lhs &gt;= rhs.str()</del><ins>!(lhs &lt; rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/24 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&lt;=(typename iterator_traits&lt;BiIter&gt;::value_type const* lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
24 <em>Returns</em>: <tt><del>lhs &lt;= rhs.str()</del><ins>!(rhs &lt; lhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/25 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
</pre>
25 <em>Returns</em>: <tt><del>lhs.str() == rhs</del><ins>lhs.compare(rhs) == 0</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/26 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
</pre>
26 <em>Returns</em>: <tt><del>lhs.str() != rhs</del><ins>!(lhs == rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/27 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
</pre>
27 <em>Returns</em>: <tt><del>lhs.str() &lt; rhs</del><ins>lhs.compare(rhs) &lt; 0</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/28 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
</pre>
28 <em>Returns</em>: <tt><del>lhs.str() &gt; rhs</del><ins>rhs &lt; lhs</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/29 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
</pre>
29 <em>Returns</em>: <tt><del>lhs.str() &gt;= rhs</del><ins>!(lhs &lt; rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/30 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const* rhs);
</pre>
30 <em>Returns</em>: <tt><del>lhs.str() &lt;= rhs</del><ins>!(rhs &lt; lhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/31 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
<del>31 <em>Returns</em>: <tt>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1,	lhs) == rhs.str()</tt>.</del><br>
<ins>31 <em>Returns</em>: <tt>rhs.compare(typename sub_match&lt;BiIter&gt;::string_type(1, lhs)) == 0</tt>.</ins>
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/32 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator!=(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
32 <em>Returns</em>: <tt><del>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) !=
rhs.str()</del><ins>!(lhs == rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/33 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&lt;(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
<del>33 <em>Returns</em>: <tt>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) &lt; rhs.str()</tt>.</del><br>
<ins>33 <em>Returns</em>: <tt>rhs.compare(typename sub_match&lt;BiIter&gt;::string_type(1, lhs)) &gt; 0</tt>.</ins>
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/34 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&gt;(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
34 <em>Returns</em>: <tt><del>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) &gt; rhs.str()</del><ins>rhs &lt; lhs</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/35 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&gt;=(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
35 <em>Returns</em>: <tt><del>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) &gt;= rhs.str()</del><ins>!(lhs &lt; rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/36 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&lt;=(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
   const sub_match&lt;BiIter&gt;&amp; rhs);
</pre>
36 <em>Returns</em>: <tt><del>basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, lhs) &lt;= rhs.str()</del><ins>!(rhs &lt; lhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/37 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
</pre>
<del>37 <em>Returns</em>: <tt>lhs.str() == basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</tt>.</del><br>
<ins>37 <em>Returns</em>: <tt>lhs.compare(typename sub_match&lt;BiIter&gt;::string_type(1, rhs)) == 0</tt>.</ins>
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/38 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
</pre>
38 <em>Returns</em>: <tt><del>lhs.str() != basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</del><ins>!(lhs == rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/39 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
</pre>
<del>39 <em>Returns</em>: <tt>lhs.str() &lt; basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</tt>.</del><br>
<ins>39 <em>Returns</em>: <tt>lhs.compare(typename sub_match&lt;BiIter&gt;::string_type(1, rhs)) &lt; 0</tt>.</ins>
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/40 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
</pre>
40 <em>Returns</em>: <tt><del>lhs.str() &gt; basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</del><ins>rhs &lt; lhs</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/41 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
</pre>
41 <em>Returns</em>: <tt><del>lhs.str() &gt;= basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</del><ins>!(lhs &lt; rhs)</ins></tt>.
</blockquote>
</li>
<li>Change 28.9.2 [re.submatch.op]/42 as indicated:
<blockquote><pre>template &lt;class BiIter&gt;
 bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
   typename iterator_traits&lt;BiIter&gt;::value_type const&amp; rhs);
</pre>
42 <em>Returns</em>: <tt><del>lhs.str() &lt;= basic_string&lt;typename iterator_traits&lt;BiIter&gt;::value_type&gt;(1, rhs)</del><ins>!(rhs &lt; lhs)</ins></tt>.
</blockquote>
</li>
</ol>






<hr>
<h3><a name="1182"></a>1182. Unfortunate hash dependencies</h3>
<p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-28 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 324</b></p>

<p>
The implied library dependencies created by spelling out all the <tt>hash</tt>
template specializations in the <tt>&lt;functional&gt;</tt> synopsis are unfortunate. 
The potential coupling is greatly reduced if the <tt>hash</tt> specialization is
declared in the appropriate header for each library type, as it is much
simpler to forward declare the primary template and provide a single
specialization than it is to implement a <tt>hash</tt> function for a <tt>string</tt> or
<tt>vector</tt> without providing a definition for the whole <tt>string/vector</tt>
template in order to access the necessary bits.
</p>

<p>
Note that the proposed resolution purely involves moving the
declarations of a few specializations, it specifically does not make any
changes to 20.8.15 [unord.hash].
</p>

<p><i>[
2009-09-15 Daniel adds:
]</i></p>


<blockquote>
</blockquote>
<p>
I suggest to add to the current existing
proposed resolution the following items.
</p>

<ul>
<li>
<p>
Add to the very first strike-list of the currently suggested resolution
the following lines:
</p>

<blockquote><pre><del>template &lt;&gt; struct hash&lt;std::error_code&gt;;</del>
<del>template &lt;&gt; struct hash&lt;std::thread::id&gt;;</del>
</pre></blockquote>
</li>

<li>
<p>
Add the following declarations to 19.5 [syserr], header
<tt>&lt;system_error&gt;</tt> synopsis after // 19.5.4:
</p>

<blockquote><pre><ins>
// 19.5.x hash support
template &lt;class T&gt; struct hash;
template &lt;&gt; struct hash&lt;error_code&gt;;
</ins>
</pre></blockquote>
</li>

<li>
<p>
Add a new clause 19.5.X (probably after 19.5.4):
</p>

<blockquote>
<p><ins>
19.5.X Hash support [syserr.hash]
</ins></p>

<pre><ins>
template &lt;&gt; struct hash&lt;error_code&gt;;
</ins></pre>

<blockquote><ins>
An explicit specialization of the class template hash (20.8.15 [unord.hash])
shall be provided
for the type <tt>error_code</tt> suitable for using this type as key in
unordered associative
containers (23.7 [unord]).
</ins></blockquote>
</blockquote>
</li>

<li>
<p>
Add the following declarations to 30.3.1.1 [thread.thread.id] just after the
declaration of
the comparison operators:
</p>

<blockquote><pre><ins>
template &lt;class T&gt; struct hash;
template &lt;&gt; struct hash&lt;thread::id&gt;;
</ins></pre></blockquote>
</li>

<li>
<p>
Add a new paragraph at the end of 30.3.1.1 [thread.thread.id]:
</p>

<blockquote>
<pre><ins>
template &lt;&gt; struct hash&lt;thread::id&gt;;
</ins></pre>

<blockquote><ins>
An explicit specialization of the class template hash (20.8.15 [unord.hash])
shall be provided
for the type <tt>thread::id</tt> suitable for using this type as key in
unordered associative
containers (23.7 [unord]).
</ins></blockquote>
</blockquote>
</li>

<li>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a> independently suggests moving the specialization
<tt>std::hash&lt;std::thread::id&gt;</tt> to header <tt>&lt;thread&gt;</tt>.
</li>
</ul>

<p><i>[
2009-11-13 Alisdair adopts Daniel's suggestion and the extended note from
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#889">889</a>.
]</i></p>


<p><i>[
2010-01-31 Alisdair: related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1245">1245</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a>.
]</i></p>


<p><i>[
2010-02-07 Proposed wording updated by Beman, Daniel, Alisdair and Ganesh.
]</i></p>


<p><i>[
2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>Strike the following specializations declared in the <tt>&lt;functional&gt;</tt> 
synopsis p2 20.8 [function.objects] </i> </p>
<blockquote>
  <pre><del>template &lt;&gt; struct hash&lt;std::string&gt;;</del>
<del>template &lt;&gt; struct hash&lt;std::u16string&gt;;</del>
<del>template &lt;&gt; struct hash&lt;std::u32string&gt;;</del>
<del>template &lt;&gt; struct hash&lt;std::wstring&gt;;</del>

<del>template &lt;&gt; struct hash&lt;std::error_code&gt;;</del>
<del>template &lt;&gt; struct hash&lt;std::thread::id&gt;;</del>
<del>template &lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool, Allocator&gt; &gt;;</del>
<del>template &lt;std::size_t N&gt; struct hash&lt;std::bitset&lt;N&gt; &gt;;</del></pre>
</blockquote>
<p><i>Add the following at the end of 20.8.15 [unord.hash]:</i></p>
<blockquote>
  <pre><ins>template &lt;&gt; struct hash&lt;bool&gt;;
template &lt;&gt; struct hash&lt;char&gt;;
template &lt;&gt; struct hash&lt;signed char&gt;;
template &lt;&gt; struct hash&lt;unsigned char&gt;;
template &lt;&gt; struct hash&lt;char16_t&gt;;
template &lt;&gt; struct hash&lt;char32_t&gt;;
template &lt;&gt; struct hash&lt;wchar_t&gt;;
template &lt;&gt; struct hash&lt;short&gt;;
template &lt;&gt; struct hash&lt;unsigned short&gt;;
template &lt;&gt; struct hash&lt;int&gt;;
template &lt;&gt; struct hash&lt;unsigned int&gt;;
template &lt;&gt; struct hash&lt;long&gt;;
template &lt;&gt; struct hash&lt;long long&gt;;
template &lt;&gt; struct hash&lt;unsigned long&gt;;
template &lt;&gt; struct hash&lt;unsigned long long&gt;;
template &lt;&gt; struct hash&lt;float&gt;;
template &lt;&gt; struct hash&lt;double&gt;;
template &lt;&gt; struct hash&lt;long double&gt;;
template&lt;class T&gt; struct hash&lt;T*&gt;;</ins></pre>
  <p><ins>
  Specializations meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
</blockquote>
<p><i>Add the following declarations to 19.5 [syserr], header <tt>&lt;system_error&gt;</tt> 
synopsis after // 19.5.4: </i> </p>
<blockquote>
  <pre><ins>// [syserr.hash] hash support
template &lt;class T&gt; struct hash;
template &lt;&gt; struct hash&lt;error_code&gt;;</ins></pre>
</blockquote>
<p><i>Add a new clause 19.5.X (probably after 19.5.4): </i> </p>
<blockquote>
  <p><ins>19.5.X Hash support [syserr.hash] </ins></p>
  <pre><ins>template &lt;&gt; struct hash&lt;error_code&gt;;</ins></pre>
    <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
</blockquote>
<p><i>Add the following declarations to the synopsis of <tt>&lt;string&gt;</tt> in 21.3 [string.classes]
</i>
</p>
<blockquote>
  <pre><ins>// [basic.string.hash] hash support
template &lt;class T&gt; struct hash;
template &lt;&gt; struct hash&lt;string&gt;;
template &lt;&gt; struct hash&lt;u16string&gt;;
template &lt;&gt; struct hash&lt;u32string&gt;;
template &lt;&gt; struct hash&lt;wstring&gt;;</ins></pre>
</blockquote>
<p><i>Add a new clause 21.4.X </i> </p>
<blockquote>
  <p><ins>21.4.X Hash support [basic.string.hash]&gt;</ins></p>
  <pre><ins>template &lt;&gt; struct hash&lt;string&gt;;
template &lt;&gt; struct hash&lt;u16string&gt;;
template &lt;&gt; struct hash&lt;u32string&gt;;
template &lt;&gt; struct hash&lt;wstring&gt;;</ins></pre>
    <p><ins>Specializations meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
</blockquote>
<p><i>Add the following declarations to the synopsis of <tt>&lt;vector&gt;</tt> in
23.3 [sequences]</i> </p>
<blockquote>
  <pre><ins>// 21.4.x hash support
template &lt;class T&gt; struct hash;
template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;</ins></pre>
</blockquote>
<p><i>Add a new paragraph to the end of 23.4.2 [vector.bool] </i> </p>
<blockquote>
  <pre><ins>template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;</ins></pre>
    <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
</blockquote>
<p><i>Add the following declarations to the synopsis of <tt>&lt;bitset&gt;</tt> in 20.5 [template.bitset] </i> </p>
<blockquote>
  <pre><ins>// [bitset.hash] hash support
template &lt;class T&gt; struct hash;
template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;</ins></pre>
</blockquote>
<p><i>Add a new subclause 20.3.7.X [bitset.hash] </i> </p>
<blockquote>
  <p><ins>20.3.7.X bitset hash support [bitset.hash]</ins></p>
  <pre><ins>template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;</ins></pre>
    <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
</blockquote>
<p><i>Add the following declarations to 30.3.1.1 [thread.thread.id] synopsis just after the 
declaration of the comparison operators: </i> </p>
<blockquote>
  <pre><ins>template &lt;class T&gt; struct hash;
template &lt;&gt; struct hash&lt;thread::id&gt;;</ins></pre>
</blockquote>
<p><i>Add a new paragraph at the end of 30.3.1.1 [thread.thread.id]: </i> </p>
<blockquote>
  <pre><ins>template &lt;&gt; struct hash&lt;thread::id&gt;;</ins></pre>
  <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> 20.8.15 [unord.hash].</ins></p>
</blockquote>

<p><i>Change Header &lt;typeindex&gt; synopsis 20.13.1 [type.index.synopsis] as 
indicated:</i></p>
<blockquote>
<pre>namespace std {
class type_index;
  <ins>// [type.index.hash] hash support</ins>
  template &lt;class T&gt; struct hash;
  template&lt;&gt; struct hash&lt;type_index&gt;<ins>;</ins> <del> : public unary_function&lt;type_index, size_t&gt; {
    size_t operator()(type_index index) const;
  }</del>
}</pre>
</blockquote>

<p><i>Change Template specialization hash&lt;type_index&gt;  [type.index.templ]
  as indicated:</i></p>

<blockquote>

  <p>20.11.4 <del>Template specialization hash&lt;type_index&gt; [type.index.templ]</del>
  <ins>Hash support [type.index.hash]</ins></p>

  <pre><del>size_t operator()(type_index index) const;</del></pre>
  <blockquote>
    <p><del><i>Returns:</i> <tt>index.hash_code()</tt></del></p>
  </blockquote>
  
  <pre><ins>template&lt;&gt; struct hash&lt;type_index&gt;;</ins></pre>
  <p><ins>Specialization meeting the requirements of class template <tt>hash</tt> [unord.hash]. 
  For an object <tt>index</tt> of type <tt>type_index</tt>, <tt>hash&lt;type_index&gt;()(index)</tt> 
  shall evaluate to the same value as <tt>index.hash_code()</tt>.</ins></p>
  
</blockquote>






<hr>
<h3><a name="1183"></a>1183. <tt>basic_ios::set_rdbuf</tt> may break class invariants</h3>
<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-07-28 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The protected member function <tt>set_rdbuf</tt> had been added during the
process of adding move and swap semantics to IO classes. A relevant
property of this function is described by it's effects in
27.5.4.2 [basic.ios.members]/19:
</p>

<blockquote>
<i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed to by sb with
this stream without calling <tt>clear()</tt>.
</blockquote>

<p>
This means that implementors of or those who derive from existing IO classes
could cause an internal state where the stream buffer could be 0, but the
IO class has the state <tt>good()</tt>. This would break several currently existing
implementations which rely on the fact that setting a stream buffer via the
currently only ways, i.e. either by calling
</p>

<blockquote><pre>void init(basic_streambuf&lt;charT,traits&gt;* sb);
</pre></blockquote>

<p>
or by calling
</p>

<blockquote><pre>basic_streambuf&lt;charT,traits&gt;* rdbuf(basic_streambuf&lt;charT,traits&gt;* sb);
</pre></blockquote>

<p>
to set <tt>rdstate()</tt> to <tt>badbit</tt>, if the buffer is 0. This has the effect that many
internal functions can simply check <tt>rdstate()</tt> instead of <tt>rdbuf()</tt> for being 0.
</p>

<p>
I therefore suggest that a requirement is added for callers of <tt>set_rdbuf</tt> to
set a non-0 value.
</p>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Open.  Martin volunteers to provide new wording, where
<tt>set_rdbuf()</tt> sets the <tt>badbit</tt> but does not cause an
exception to be thrown like a call to <tt>clear()</tt> would.
</blockquote>

<p><i>[
2009-10-20 Martin provides wording:
]</i></p>


<p>
Change 27.5.4.2 [basic.ios.members] around p. 19 as indicated:
</p>

<blockquote><pre>void set_rdbuf(basic_streambuf&lt;charT, traits&gt;* sb);
</pre>

<blockquote>
<p><del>
<i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed
to by <tt>sb</tt> with this stream without calling <tt>clear()</tt>.
<i>Postconditions:</i> <tt>rdbuf() == sb</tt>.
</del></p>

<p><ins>
<i>Effects:</i> As if:
</ins></p>

<blockquote><pre><ins>
iostate state = rdstate();
try { rdbuf(sb); }
catch(ios_base::failure) {
   if (0 == (state &amp; ios_base::badbit))
       unsetf(badbit);
}
</ins></pre></blockquote>

<p>
<i>Throws:</i> Nothing.
</p>

</blockquote>
</blockquote>

<p><b>Rationale:</b></p>
We need to be able to call <tt>set_rdbuf()</tt> on stream objects
for which (<tt>rdbuf() == 0</tt>) holds without causing <tt>ios_base::failure</tt> to
be thrown. We also don't want <tt>badbit</tt> to be set as a result of
setting <tt>rdbuf()</tt> to 0 if it wasn't set before the call. This changed
Effects clause maintains the current behavior (as of N2914) without
requiring that <tt>sb</tt> be non-null.


<p><i>[
Post-Rapperswil
]</i></p>


<p>
Several reviewers and the submitter believe that the best solution would be to add a pre-condition that the 
buffer shall not be a null pointer value.
</p>

<blockquote>
Moved to Tentatively Ready with revised wording provided by Daniel after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>Add a new pre-condition just before 27.5.4.2 [basic.ios.members]/23 as indicated:
<blockquote><pre>void set_rdbuf(basic_streambuf&lt;charT, traits&gt;* sb);
</pre>
<blockquote>
<ins>?? <em>Requires</em>: <tt>sb != nullptr</tt>.</ins>
<p>
23 <em>Effects</em>: Associates the <tt>basic_streambuf</tt> object pointed to by <tt>sb</tt> with this stream without calling <tt>clear()</tt>.
</p>
<p>
24 <em>Postconditions</em>: <tt>rdbuf() == sb</tt>.
</p>
<p>
25 <em>Throws</em>: Nothing.
</p>
</blockquote></blockquote>
</li>
</ol>


<p><b>Rationale:</b></p>
We believe that setting a <tt>nullptr</tt> stream buffer can be prevented.





<hr>
<h3><a name="1187"></a>1187. std::decay</h3>
<p><b>Section:</b> 20.7.7.6 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2009-08-07 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I notice that <tt>std::decay</tt> is specified to strip the cv-quals from
anything but an array or pointer.  This seems incorrect for values of
class type, since class rvalues can have cv-qualified type (3.10 [basic.lval]/9).
</p>

<p><i>[
2009-08-09 Howard adds:
]</i></p>


<blockquote>
See the thread starting with c++std-lib-24568 for further discussion.  And
here is a convenience link to the
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2069.html">original proposal</a>.
Also see the closely related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>.
</blockquote>

<p><i>[
2010 Pittsburgh:  Moved to Ready.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Add a note to <tt>decay</tt> in 20.7.7.6 [meta.trans.other]:
</p>

<blockquote>
[<i>Note:</i> This behavior is similar to the lvalue-to-rvalue (4.1),
array-to-pointer (4.2), and function-to-pointer (4.3) conversions
applied when an lvalue expression is used as an rvalue, but also strips
cv-qualifiers from class types in order to more closely model by-value
argument passing. � <i>end note</i>]
</blockquote>








<hr>
<h3><a name="1189"></a>1189. Awkward interface for changing the number of buckets in an unordered associative container</h3>
<p><b>Section:</b> 23.2.5 [unord.req], 23.7 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-08-10 <b>Last modified:</b> 2010-10-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider a typical use case: I create an <tt>unordered_map</tt> and then start
adding elements to it one at a time. I know that it will eventually need
to store a few million elements, so, for performance reasons, I would
like to reserve enough capacity that none of the calls to <tt>insert</tt> will
trigger a rehash.
</p>

<p>
Unfortunately, the existing interface makes this awkward. The user
naturally sees the problem in terms of the number of elements, but the
interface presents it as buckets. If <tt>m</tt> is the map and <tt>n</tt> is the expected
number of elements, this operation is written <tt>m.rehash(n /
m.max_load_factor())</tt> � not very novice friendly.
</p>

<p><i>[
2009-09-30 Daniel adds:
]</i></p>


<blockquote>
I recommend to replace "<tt>resize</tt>" by a different name like
"<tt>reserve</tt>", because that would better match the intended
use-case. Rational: Any existing resize function has the on-success
post-condition that the provided size is equal to <tt>size()</tt>, which
is not satisfied for the proposal. Reserve seems to fit the purpose of
the actual renaming suggestion.
</blockquote>

<p><i>[
2009-10-28 Ganesh summarizes alternative resolutions and expresses a
strong preference for the second (and opposition to the first):
]</i></p>


<blockquote>
<ol>
<li>
<p>
In the unordered associative container requirements (23.2.5 [unord.req]),
remove the row for
rehash and replace it with:
</p>

<blockquote>
<table border="1">
<caption>Table 87 � Unordered associative container requirements
(in addition to container)</caption>

<tbody><tr>
<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td><tt>a.<del>rehash</del><ins>reserve</ins>(n)</tt></td>
<td><tt>void</tt></td>
<td>
Post: <tt>a.bucket_count &gt; <ins>max(</ins>a.size()<ins>, n)</ins>
/ a.max_load_factor()</tt><del> and <tt>a.bucket_count()
&gt;= n</tt></del>.
</td>
<td>
Average case linear in <tt>a.size()</tt>, worst case quadratic.
</td>
</tr>
</tbody></table>
</blockquote>

<p>
Make the corresponding change in the class synopses in 23.7.1 [unord.map], 23.7.2 [unord.multimap],  23.7.3 [unord.set], and 23.7.4 [unord.multiset].
</p>
</li>
<li>

<p>
In 23.2.5 [unord.req]/9, table 98, append a new row after the last one:
</p>

<blockquote>
<table border="1">
<caption>Table 87 � Unordered associative container requirements
(in addition to container)</caption>

<tbody><tr>
<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td><tt>a.rehash(n)</tt></td>
<td><tt>void</tt></td>
<td>
Post: <tt>a.bucket_count &gt; a.size()
/ a.max_load_factor()</tt> and <tt>a.bucket_count()
&gt;= n</tt>.
</td>
<td>
Average case linear in <tt>a.size()</tt>, worst case quadratic.
</td>
</tr>
<tr>
<td><ins>
<tt>a.reserve(n)</tt>
</ins></td>
<td><ins>
<tt>void</tt>
</ins></td>
<td><ins>
Same as <tt>a.rehash(ceil(n / a.max_load_factor()))</tt>
</ins></td>
<td><ins>
Average case linear in <tt>a.size()</tt>, worst case quadratic.
</ins></td>
</tr>
</tbody></table>
</blockquote>

<p>
In 23.7.1 [unord.map]/3 in the definition of class template <tt>unordered_map</tt>, in
23.7.2 [unord.multimap]/3 in the definition of class template <tt>unordered_multimap</tt>, in
23.7.3 [unord.set]/3 in the definition of class template <tt>unordered_set</tt> and in
23.7.4 [unord.multiset]/3 in the definition of class template <tt>unordered_multiset</tt>, add the
following line after member function <tt>rehash()</tt>:
</p>

<blockquote><pre>void reserve(size_type n);
</pre></blockquote>

</li>
</ol>
</blockquote>

<p><i>[
2009-10-28 Howard:
]</i></p>


<blockquote>
<p>
Moved to Tentatively Ready after 5 votes in favor of Ganesh's option 2 above.
The original proposed wording now appears here:
</p>

<blockquote>
<p>
Informally: instead of providing <tt>rehash(n)</tt> provide <tt>resize(n)</tt>, with the
semantics "make the container a good size for <tt>n</tt> elements".
</p>

<p>
In the unordered associative container requirements (23.2.5 [unord.req]),
remove the row for
rehash and replace it with:
</p>

<blockquote>
<table border="1">
<caption>Table 87 � Unordered associative container requirements
(in addition to container)</caption>

<tbody><tr>
<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td><tt>a.<del>rehash</del><ins>resize</ins>(n)</tt></td>
<td><tt>void</tt></td>
<td>
Post: <tt>a.bucket_count &gt; <ins>max(</ins>a.size()<ins>, n)</ins>
/ a.max_load_factor()</tt><del> and <tt>a.bucket_count()
&gt;= n</tt></del>.
</td>
<td>
Average case linear in <tt>a.size()</tt>, worst case quadratic.
</td>
</tr>
</tbody></table>
</blockquote>

<p>
Make the corresponding change in the class synopses in 23.7.1 [unord.map], 23.7.2 [unord.multimap],  23.7.3 [unord.set], and 23.7.4 [unord.multiset].
</p>

</blockquote>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
In 23.2.5 [unord.req]/9, table 98, append a new row after the last one:
</p>

<blockquote>
<table border="1">
<caption>Table 87 � Unordered associative container requirements
(in addition to container)</caption>

<tbody><tr>
<th>Expression</th><th>Return type</th><th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td><tt>a.rehash(n)</tt></td>
<td><tt>void</tt></td>
<td>
Post: <tt>a.bucket_count &gt; a.size()
/ a.max_load_factor()</tt> and <tt>a.bucket_count()
&gt;= n</tt>.
</td>
<td>
Average case linear in <tt>a.size()</tt>, worst case quadratic.
</td>
</tr>
<tr>
<td><ins>
<tt>a.reserve(n)</tt>
</ins></td>
<td><ins>
<tt>void</tt>
</ins></td>
<td><ins>
Same as <tt>a.rehash(ceil(n / a.max_load_factor()))</tt>
</ins></td>
<td><ins>
Average case linear in <tt>a.size()</tt>, worst case quadratic.
</ins></td>
</tr>
</tbody></table>
</blockquote>

<p>
In 23.7.1 [unord.map]/3 in the definition of class template <tt>unordered_map</tt>, in
23.7.2 [unord.multimap]/3 in the definition of class template <tt>unordered_multimap</tt>, in
23.7.3 [unord.set]/3 in the definition of class template <tt>unordered_set</tt> and in
23.7.4 [unord.multiset]/3 in the definition of class template <tt>unordered_multiset</tt>, add the
following line after member function <tt>rehash()</tt>:
</p>

<blockquote><pre>void reserve(size_type n);
</pre></blockquote>





<hr>
<h3><a name="1191"></a>1191. <tt>tuple get</tt> API should respect rvalues</h3>
<p><b>Section:</b> 20.4.2.6 [tuple.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-08-18 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>tuple get</tt> API should respect rvalues.  This would allow for moving a
single element out of a <tt>tuple</tt>-like type.
</p>

<p><i>[
2009-10-30 Alisdair adds:
]</i></p>


<blockquote>
<p>
The issue of rvalue overloads of get for tuple-like types was briefly
discussed in Santa Cruz.
</p>

<p>
The feedback was this would be welcome, but we need full wording for the
other types (<tt>pair</tt> and <tt>array</tt>) before advancing.
</p>

<p>
I suggest the issue moves to Open from New as it has been considered,
feedback given, and it has not (yet) been rejected as NAD.
</p>
</blockquote>


<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote>
Note that wording has been provided, and this issue becomes more important now that we have added a function to support forwarding argument lists as <tt>tuple</tt>s.

Move to Tentatively Ready.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add the following signature to p2 20.4.1 [tuple.general]
</p>

<blockquote><pre><ins>
template &lt;size_t I, class ... Types&gt;
typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp; get(tuple&lt;Types...&gt; &amp;&amp;);
</ins></pre></blockquote>

<p>
And again to 20.4.2.6 [tuple.elem].
</p>

<blockquote><pre><ins>
template &lt;size_t I, class ... Types&gt;
typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp; get(tuple&lt;Types...&gt;&amp;&amp; t);
</ins></pre>

<blockquote>
<p><ins>
<i>Effects:</i> Equivalent to <tt>return std::forward&lt;typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp;&amp;&gt;(get&lt;I&gt;(t));</tt>
</ins></p>


<p><ins>
[<i>Note:</i> If a <tt>T</tt> in <tt>Types</tt> is some reference type <tt>X&amp;</tt>,
the return type is <tt>X&amp;</tt>, not <tt>X&amp;&amp;</tt>.
However, if the element type is non-reference type <tt>T</tt>,
the return type is <tt>T&amp;&amp;</tt>. � <i>end note</i>]
</ins></p>

</blockquote>
</blockquote>

<p>
Add the following signature to p1 20.3 [utility]
</p>

<blockquote><pre><ins>
template &lt;size_t I, class T1, class T2&gt;
typename tuple_element&lt;I, pair&lt;T1,T2&gt; &gt;::type&amp;&amp; get(pair&lt;T1, T2&gt;&amp;&amp;);
</ins></pre></blockquote>

<p>
And to p5 20.3.5.4 [pair.astuple]
</p>

<blockquote><pre><ins>
template &lt;size_t I, class T1, class T2&gt;
typename tuple_element&lt;I, pair&lt;T1,T2&gt; &gt;::type&amp;&amp; get(pair&lt;T1, T2&gt;&amp;&amp; p);
</ins></pre>

<blockquote>
<p><ins>
<i>Returns:</i> If <tt>I == 0</tt> returns <tt>std::forward&lt;T1&amp;&amp;&gt;(p.first)</tt>;
if <tt>I == 1</tt>
returns <tt>std::forward&lt;T2&amp;&amp;&gt;(p.second)</tt>; otherwise the program is ill-formed.
</ins></p>

<p><ins>
<i>Throws:</i> Nothing.
</ins></p>

</blockquote>

</blockquote>

<p>
Add the following signature to 23.3 [sequences] <tt>&lt;array&gt;</tt> synopsis
</p>

<blockquote><pre><ins>template &lt;size_t I, class T, size_t N&gt;
T&amp;&amp; get(array&lt;T,N&gt; &amp;&amp;);
</ins></pre></blockquote>

<p>
And after p8 23.3.1.8 [array.tuple]
</p>

<blockquote><pre><ins>template &lt;size_t I, class T, size_t N&gt;
T&amp;&amp; get(array&lt;T,N&gt; &amp;&amp; a);
</ins></pre>

<blockquote><ins>
<i>Effects:</i> Equivalent to <tt>return std::move(get&lt;I&gt;(a));</tt>
</ins></blockquote>
</blockquote>






<hr>
<h3><a name="1192"></a>1192. <tt>basic_string</tt> missing definitions for <tt>cbegin</tt> / <tt>cend</tt> / <tt>crbegin</tt> / <tt>crend</tt></h3>
<p><b>Section:</b> 21.4.3 [string.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-08-14 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Unlike the containers in clause 23, <tt>basic_string</tt> has definitions for
<tt>begin()</tt> and <tt>end()</tt>, but these have not been updated to include <tt>cbegin</tt>,
<tt>cend</tt>, <tt>crbegin</tt> and <tt>crend</tt>.
</p>

<p><i>[
2009-10-28 Howard:
]</i></p>


<blockquote>
Moved to Tentatively NAD after 5 positive votes on c++std-lib.  Added
rationale.
</blockquote>

<p><i>[
2009-10-28 Alisdair disagrees:
]</i></p>


<blockquote>
<p>
I'm going to have to speak up as the dissenting voice.
</p>

<p>
I agree the issue could be handled editorially, and that would be my
preference if Pete feels this is appropriate. Failing that, I really
think this issue should be accepted and moved to ready.  The other
begin/end functions all have a semantic definition for this template,
and it is confusing if a small few are missing.
</p>

<p>
I agree that an alternative would be to strike <em>all</em> the definitions for
<tt>begin/end/rbegin/rend</tt> and defer completely to the requirements tables in
clause 23.  I think that might be confusing without a forward reference
though, as those tables are defined in a *later* clause than the
basic_string template itself.  If someone wants to pursue this I would
support it, but recommend it as a separate issue.
</p>

<p>
So my preference is strongly to move Ready over NAD, and a stronger
preference for NAD Editorial if Pete is happy to make these changes.
</p>

</blockquote>

<p><i>[
2009-10-29 Howard:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.  Removed
rationale to mark it NAD.  :-)
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add to 21.4.3 [string.iterators]
</p>

<blockquote><pre>iterator       begin();
const_iterator begin() const;
<ins>const_iterator cbegin() const;</ins>
</pre>

<p>...</p>

<pre>iterator       end();
const_iterator end() const;
<ins>const_iterator cend() const;</ins>
</pre>

<p>...</p>

<pre>reverse_iterator       rbegin();
const_reverse_iterator rbegin() const;
<ins>const_reverse_iterator crbegin() const;</ins>
</pre>

<p>...</p>

<pre>reverse_iterator       rend();
const_reverse_iterator rend() const;
<ins>const_reverse_iterator crend() const;</ins>
</pre>

</blockquote>





<hr>
<h3><a name="1193"></a>1193. <tt>default_delete</tt> cannot be instantiated with  incomplete types</h3>
<p><b>Section:</b> 20.9.9.1 [unique.ptr.dltr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-08-18 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to the general rules of 17.6.3.8 [res.on.functions]/2 b 5 the effects
are undefined, if an incomplete type is used to instantiate a library template. But neither in
20.9.9.1 [unique.ptr.dltr] nor
in any other place of the standard such explicit allowance is given.
Since this template is intended to be instantiated with incomplete
types, this must
be fixed.
</p>

<p><i>[
2009-11-15 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2009-11-17 Alisdair Opens:
]</i></p>


<blockquote>
<p>
LWG 1193 tries to support unique_ptr for incomplete types.  I believe the
proposed wording goes too far:
</p>

<blockquote>
The template parameter <tt>T</tt> of <tt>default_delete</tt> may be an
incomplete type.
</blockquote>

<p>
Do we really want to support <tt>cv-void</tt>?  Suggested ammendment:
</p>

<blockquote>
The template parameter <tt>T</tt> of <tt>default_delete</tt> may be an
incomplete type <ins>other than <tt>cv-void</tt></ins>.
</blockquote>

<p>
We might also consider saying something about arrays of incomplete types.
</p>

<p>
Did we lose support for <tt>unique_ptr&lt;function-type&gt;</tt> when the
concept-enabled work was shelved?  If so, we might want a
<tt>default_delete</tt> partial specialization for function types that does
nothing.  Alternatively, function types should <em>not</em> be supported by
default, but there is no reason a user cannot support them via their own
deletion policy.
</p>

<p>
Function-type support might also lead to conditionally supporting a
function-call operator in the general case, and that seems way too inventive at
this stage to me, even if we could largely steal wording directly from
<tt>reference_wrapper</tt>.  <tt>shared_ptr</tt> would have similar problems
too.
</p>

</blockquote>

<p><i>[
2010-01-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add two new paragraphs directly to 20.9.9.1 [unique.ptr.dltr] (before
20.9.9.1.2 [unique.ptr.dltr.dflt]) with the following
content:
</p>

<blockquote>
<p><ins>
The class template <tt>default_delete</tt> serves as the default deleter (destruction policy) for
the class template <tt>unique_ptr</tt>.
</ins></p>

<p><ins>
The template parameter <tt>T</tt> of <tt>default_delete</tt> may be an incomplete type.
</ins></p>
</blockquote>





<hr>
<h3><a name="1194"></a>1194. Unintended <tt>queue</tt> constructor</h3>
<p><b>Section:</b> 23.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-08-20 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.5.1.1 [queue.defn] has the following <tt>queue</tt> constructor:
</p>

<blockquote><pre>template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
</pre></blockquote>

<p>
This will be implemented like so:
</p>

<blockquote><pre>template &lt;class Alloc&gt; explicit queue(const Alloc&amp; a) : c(a) {}
</pre></blockquote>

<p>
The issue is that <tt>Alloc</tt> can be anything that a container will construct
from, for example an <tt>int</tt>.  Is this intended to compile?
</p>

<blockquote><pre>queue&lt;int&gt; q(5);
</pre></blockquote>

<p>
Before the addition of this constructor, <tt>queue&lt;int&gt;(5)</tt> would not compile.
I ask, not because this crashes, but because it is new and appears to be
unintended.  We do not want to be in a position of accidently introducing this
"feature" in C++0X and later attempting to remove it.
</p>

<p>
I've picked on <tt>queue</tt>.  <tt>priority_queue</tt> and <tt>stack</tt> have
the same issue.  Is it useful to create a <tt>priority_queue</tt> of 5
identical elements?
</p>

<p><i>[
Daniel, Howard and Pablo collaborated on the proposed wording.
]</i></p>


<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>

<p><i>[
This resolution includes a semi-editorial clean up, giving definitions to members
which in some cases weren't defined since C++98.
This resolution also offers editorially different wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>,
and it also provides wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>.
]</i></p>


<p>
Change  container.adaptors, p1:
</p>

<blockquote>
The container adaptors each take a <tt>Container</tt> template parameter, and
each constructor takes a <tt>Container</tt> reference argument. This container is
copied into the <tt>Container</tt> member of each adaptor. If the container takes
an allocator, then a compatible allocator may be passed in to the
adaptor's constructor. Otherwise, normal copy or move construction is
used for the container argument. <del>[<i>Note:</i> it is not necessary for an
implementation to distinguish between the one-argument constructor that
takes a <tt>Container</tt> and the one- argument constructor that takes an
allocator_type. Both forms use their argument to construct an instance
of the container. � <i>end note</i>]</del>
</blockquote>

<p>
Change  queue.defn, p1:
</p>

<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
class queue {
public:
  typedef typename Container::value_type      value_type;
  typedef typename Container::reference       reference;
  typedef typename Container::const_reference const_reference;
  typedef typename Container::size_type       size_type;
  typedef Container                           container_type;
protected:
  Container c;

public:
  explicit queue(const Container&amp;);
  explicit queue(Container&amp;&amp; = Container());
  queue(queue&amp;&amp; q)<ins>;</ins><del> : c(std::move(q.c)) {}</del>
  template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
  template &lt;class Alloc&gt; queue(const Container&amp;, const Alloc&amp;);
  template &lt;class Alloc&gt; queue(Container&amp;&amp;, const Alloc&amp;);
  template &lt;class Alloc&gt; queue(queue&amp;&amp;, const Alloc&amp;);
  queue&amp; operator=(queue&amp;&amp; q)<ins>;</ins><del> { c = std::move(q.c); return *this; }</del>

  bool empty() const          { return c.empty(); }
  ...
};
</pre></blockquote>

<p>
Add a new section after 23.5.1.1 [queue.defn], [queue.cons]:
</p>

<blockquote>
<p><b><tt>queue</tt> constructors [queue.cons]</b></p>

<pre>explicit queue(const Container&amp; cont);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt>.
</p>

</blockquote>

<pre>explicit queue(Container&amp;&amp; cont = Container());
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt>.
</p>

</blockquote>

<pre>queue(queue&amp;&amp; q)
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt>.
</p>

</blockquote>

<p>
For each of the following constructors,
if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
then the constructor shall not participate in overload resolution.
</p>

<pre>template &lt;class Alloc&gt; 
  explicit queue(const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt>.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt; 
  queue(const container_type&amp; cont, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the first
argument and <tt>a</tt> as the second argument.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt; 
  queue(container_type&amp;&amp; cont, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as the
first argument and <tt>a</tt> as the second argument.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt; 
  queue(queue&amp;&amp; q, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> as the
first argument and <tt>a</tt> as the second argument.
</p>

</blockquote>

<pre>queue&amp; operator=(queue&amp;&amp; q);
</pre>

<blockquote>

<p>
<i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(q.c)</tt>.
</p>

<p>
<i>Returns:</i> <tt>*this</tt>.
</p>

</blockquote>



</blockquote>

<p>
Add to 23.5.2.1 [priqueue.cons]:
</p>

<blockquote>

<pre>priority_queue(priority_queue&amp;&amp; q);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> and
initializes <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
</p>

</blockquote>

<p>
For each of the following constructors,
if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
then the constructor shall not participate in overload resolution.
</p>

<pre>template &lt;class Alloc&gt;
  explicit priority_queue(const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt> and value-initializes <tt>comp</tt>.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt;
  priority_queue(const Compare&amp; compare, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt> and initializes <tt>comp</tt>
with <tt>compare</tt>.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt;
  priority_queue(const Compare&amp; compare, const Container&amp; cont, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the first argument
and <tt>a</tt> as the second argument,
and initializes <tt>comp</tt> with <tt>compare</tt>.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt;
  priority_queue(const Compare&amp; compare, Container&amp;&amp; cont, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as 
the first argument and <tt>a</tt> as the second argument,
and initializes <tt>comp</tt> with <tt>compare</tt>.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt;
  priority_queue(priority_queue&amp;&amp; q, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(q.c)</tt> as the
first argument and <tt>a</tt> as the second argument, 
and initializes <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
</p>

</blockquote>

<pre>priority_queue&amp; operator=(priority_queue&amp;&amp; q);
</pre>

<blockquote>

<p>
<i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(q.c)</tt> and
assigns <tt>comp</tt> with <tt>std::move(q.comp)</tt>.
</p>

<p>
<i>Returns:</i> <tt>*this</tt>.
</p>

</blockquote>

</blockquote>




<p>
Change 23.5.3.1 [stack.defn]:
</p>

<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
class stack {
public:
  typedef typename Container::value_type      value_type;
  typedef typename Container::reference       reference;
  typedef typename Container::const_reference const_reference;
  typedef typename Container::size_type       size_type;
  typedef Container                           container_type;
protected:
  Container c;

public:
  explicit stack(const Container&amp;);
  explicit stack(Container&amp;&amp; = Container());
  <ins>stack(stack&amp;&amp; s);</ins>
  template &lt;class Alloc&gt; explicit stack(const Alloc&amp;);
  template &lt;class Alloc&gt; stack(const Container&amp;, const Alloc&amp;);
  template &lt;class Alloc&gt; stack(Container&amp;&amp;, const Alloc&amp;);
  template &lt;class Alloc&gt; stack(stack&amp;&amp;, const Alloc&amp;);
  <ins>stack&amp; operator=(stack&amp;&amp; s);</ins>

  bool empty() const          { return c.empty(); }
  ...
};
</pre></blockquote>

<p>
Add a new section after 23.5.3.1 [stack.defn], [stack.cons]:
</p>

<blockquote>
<p><b><tt>stack</tt> constructors [stack.cons]</b></p>

<pre>stack(stack&amp;&amp; s);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(s.c)</tt>.
</p>

</blockquote>

<p>
For each of the following constructors,
if <tt>uses_allocator&lt;container_type, Alloc&gt;::value</tt> is <tt>false</tt>,
then the constructor shall not participate in overload resolution.
</p>

<pre>template &lt;class Alloc&gt; 
  explicit stack(const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>a</tt>.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt; 
  stack(const container_type&amp; cont, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>cont</tt> as the
first argument and <tt>a</tt> as the second argument.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt; 
  stack(container_type&amp;&amp; cont, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(cont)</tt> as the
first argument and <tt>a</tt> as the second argument.
</p>

</blockquote>

<pre>template &lt;class Alloc&gt; 
  stack(stack&amp;&amp; s, const Alloc&amp; a);
</pre>

<blockquote>

<p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>std::move(s.c)</tt> as the
first argument and <tt>a</tt> as the second argument.
</p>

</blockquote>

<pre>stack&amp; operator=(stack&amp;&amp; s);
</pre>

<blockquote>

<p>
<i>Effects:</i> Assigns <tt>c</tt> with <tt>std::move(s.c)</tt>.
</p>

<p>
<i>Returns:</i> <tt>*this</tt>.
</p>

</blockquote>

</blockquote>






<hr>
<h3><a name="1195"></a>1195. "Diagnostic required" wording is insufficient to  prevent UB</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-08-18 <b>Last modified:</b> 2010-10-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Several parts of the library use the notion of "Diagnostic required"
to indicate that
in the corresponding situation an error diagnostic should occur, e.g.
20.9.9.1.2 [unique.ptr.dltr.dflt]/2
</p>
<blockquote><pre>void operator()(T *ptr) const;
</pre>

<blockquote>
<i>Effects:</i> calls <tt>delete</tt> on <tt>ptr</tt>. A diagnostic is required if <tt>T</tt> is an
incomplete type.
</blockquote>
</blockquote>

<p>
The problem with this approach is that such a requirement is
insufficient to prevent
undefined behavior, if this situation occurs. According to 1.3.6 [defns.diagnostic]
a <i>diagnostic message</i> is defined as
</p>

<blockquote>
a message belonging to an implementation-defined subset of the
implementation's output messages.
</blockquote>

<p>
which doesn't indicate any relation to an ill-formed program. In fact,
"compiler warnings"
are a typical expression of such diagnostics. This means that above
wording can be interpreted
by compiler writers that they satisfy the requirements of the standard
if they just produce
such a "warning", if the compiler happens to compile code like this:
</p>

<blockquote><pre>#include &lt;memory&gt;

struct Ukn; // defined somewhere else
Ukn* create_ukn(); // defined somewhere else

int main() {
 std::default_delete&lt;Ukn&gt;()(create_ukn());
}
</pre></blockquote>

<p>
In this and other examples discussed here it was the authors intent to
guarantee that the
program is ill-formed with a required diagnostic, therefore such
wording should be used instead.
According to the general rules outlined in 1.4 [intro.compliance] it
should be sufficient
to require that these situations produce an ill-formed program and the
"diagnostic
required" part should be implied. The proposed resolution also
suggests to remove
several <i>redundant</i> wording of "Diagnostics required" to ensure that
the absence of
such saying does not cause a misleading interpretation.
</p>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
<p>
Move to NAD.
</p>
<p>
It's not clear that there's any important difference between
"ill-formed" and "diagnostic required". From 1.4 [intro.compliance], 1.3.9 [defns.ill.formed], and 1.3.26 [defns.well.formed] it appears that an ill-formed program is one
that is not correctly constructed according to the syntax rules and
diagnosable semantic rules, which means that... "a conforming
implementation shall issue at least one diagnostic message." The
author's intent seems to be that we should be requiring a fatal error
instead of a mere warning, but the standard just doesn't have language
to express that distinction. The strongest thing we can ever require is
a "diagnostic".
</p>
<p>
The proposed rewording may be a clearer way of expressing the same thing
that the WP already says, but such a rewording is editorial.
</p>
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Considered again.  Group disagrees that the change is technical, but likes
it editorially.  Moved to NAD Editorial.
</blockquote>

<p><i>[
2009-11-19: Moved from NAD Editorial to Open.  Please see the thread starting
with Message c++std-lib-25916.
]</i></p>


<p><i>[
2009-11-20 Daniel updated wording.
]</i></p>


<blockquote>
<p>
The following resolution differs from the previous one by avoiding the unusual
and misleading term "shall be ill-formed", which does also not follow the core
language style. This resolution has the advantage of a minimum impact on the
current wording, but I would like to mention that a more intrusive solution
might be preferrable - at least as a long-term solution: Jens Maurer suggested
the following approach to get rid of the usage of the term "ill-formed" from the
library by introducing a new category to existing elements to the list of 17.5.1.4 [structure.specifications]/3, e.g. "type requirements" or "static
constraints" that define conditions that can be checked during compile-time and
any violation would make the program ill-formed. As an example, the currently
existing phrase 20.4.2.5 [tuple.helper]/1
</p>

<blockquote>
<i>Requires:</i> <tt>I &lt; sizeof...(Types)</tt>. The program is ill-formed if
<tt>I</tt> is out of bounds.
</blockquote>

<p>
could then be written as
</p>

<blockquote>
<i>Static constraints:</i> <tt>I &lt; sizeof...(Types)</tt>.
</blockquote>

</blockquote>

<p><i>[
2009-11-21 Daniel updated wording.
]</i></p>


<p><i>[
2009-11-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change 20.6 [ratio]/2 as indicated:
</p>

<blockquote>
Throughout this subclause, <ins>if</ins> the template argument types <tt>R1</tt>
and <tt>R2</tt> <del>shall be</del> <ins>are not</ins> specializations of the
<tt>ratio</tt> template<ins>, the program is ill-formed</ins>. <del>Diagnostic
required.</del>
</blockquote>
</li>

<li>
<p>
Change 20.6.1 [ratio.ratio]/1 as indicated:
</p>

<p>
<ins>If t</ins><del>T</del>he template argument <tt>D</tt> <del>shall not
be</del> <ins>is</ins> zero<del>, and</del> <ins>or</ins> the absolute values of
the template arguments <tt>N</tt> and <tt>D</tt> <del>shall be</del> <ins>are
not</ins> representable by type <tt>intmax_t</tt><ins>, the program is
ill-formed</ins>. <del>Diagnostic required.</del> [..]
</p>

</li>

<li>
<p>
Change 20.6.2 [ratio.arithmetic]/1 as indicated:
</p>

<blockquote>
Implementations may use other algorithms to compute these values. If overflow
occurs, <ins>the program is ill-formed</ins> <del>a diagnostic shall be
issued</del>.
</blockquote>

</li>

<li>
<p>
Change 20.6.3 [ratio.comparison]/2 as indicated:
</p>

<blockquote>
[...] Implementations may use other algorithms to compute this relationship to
avoid overflow. If overflow occurs, <ins>the program is ill-formed</ins> <del>a
diagnostic is required</del>.
</blockquote>

</li>

<li>
<p>
Change 20.9.9.1.2 [unique.ptr.dltr.dflt]/2 as indicated:
</p>

<blockquote>
<p>
<i>Effects:</i> calls <tt>delete</tt> on <tt>ptr</tt>. <del>A diagnostic is
required if <tt>T</tt> is an incomplete type.</del>
</p>

<p>
<ins><i>Remarks:</i> If <tt>T</tt> is an incomplete type, the program is
ill-formed.</ins>
</p>
</blockquote>

</li>

<li>
<p>
Change 20.9.9.1.3 [unique.ptr.dltr.dflt1]/1 as indicated:
</p>

<blockquote><pre>void operator()(T* ptr) const;
</pre>
<blockquote>
<p>
<ins><i>Effects:</i></ins> <del><tt>operator()</tt></del> calls
<tt>delete[]</tt> on <tt>ptr</tt>. <del>A diagnostic is required if <tt>T</tt>
is an incomplete type.</del>
</p>
<p>
<ins><i>Remarks:</i> If <tt>T</tt> is an incomplete type, the program is
ill-formed.</ins>
</p>
</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor] as indicated: <i>[Note: This
editorially improves the currently suggested wording of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a> by
replacing</i>
</p>
<blockquote>
<i>"shall be ill-formed" by "is ill-formed"]</i>
</blockquote>

<p>
<i>[If
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3025.html">N3025</a>
is accepted this bullet is applied identically in that paper as well.]</i>
</p>

<blockquote>
<p>
-1- <i>Requires:</i> <tt>D</tt> shall be default constructible, and that
construction shall not throw an exception. <del><tt>D</tt> shall not be a
reference type or pointer type (diagnostic required).</del>
</p>

<p>...</p>

<p><ins>
<i>Remarks:</i> If this constructor is instantiated with a pointer type
or reference type for the template argument <tt>D</tt>, the program is
ill-formed.
</ins></p>
</blockquote>

</li>

<li>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]/8 as indicated: <i>[Note: This
editorially improves the currently suggested wording of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#932">932</a> by
replacing</i>
</p>
<blockquote>
<i>"shall be ill-formed" by "is ill-formed"]</i>
</blockquote>

<p>
<i>[If
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3025.html">N3025</a>
is accepted this bullet is applied identically in that paper as well.]</i>
</p>

<blockquote><pre>unique_ptr(pointer p);
</pre>
<blockquote>
<p>...</p>
<p><ins>
<i>Remarks:</i> If this constructor is instantiated with a pointer type
or reference type for the template argument <tt>D</tt>, the program is
ill-formed.
</ins></p>
</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.9.9.2.1 [unique.ptr.single.ctor]/13 as indicated:
</p>

<blockquote>
[..] If <tt>d</tt> is an rvalue, it will bind to the second constructor of this
pair <ins>and the program is ill-formed</ins>. <del>That constructor shall emit
a diagnostic.</del> [<i>Note:</i> The diagnostic could be implemented using a
<tt>static_assert</tt> which assures that <tt>D</tt> is not a reference type.
� <i>end note</i>] Else <tt>d</tt> is an lvalue and will bind to the first
constructor of this pair. [..]
</blockquote>

</li>

<li>
20.9.9.2.1 [unique.ptr.single.ctor]/20: Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#950">950</a>.
</li>

<li>
<p>
Change 20.9.9.3 [unique.ptr.runtime]/1 as indicated:
</p>

<blockquote>
<p>
A specialization for array types is provided with a slightly altered interface.
</p>
<ul>
<li>
Conversions among different types of <tt>unique_ptr&lt;T[], D&gt;</tt> or to or
from the non-array forms of <tt>unique_ptr</tt> <del>are disallowed (diagnostic
required)</del> <ins>produce an ill-formed program</ins>.
</li>
<li>...</li>
</ul>
</blockquote>

</li>

<li>
<p>
Change 20.11.3 [time.duration]/2-4 as indicated:
</p>

<blockquote>
<p>
2 <i>Requires:</i> <tt>Rep</tt> shall be an arithmetic type or a class emulating
an arithmetic type. <del>If a program instantiates <tt>duration</tt> with a
<tt>duration</tt> type for the template argument <tt>Rep</tt> a diagnostic is
required.</del>
</p>
<p>
<ins>3 <i>Remarks:</i> If <tt>duration</tt> is instantiated with a
<tt>duration</tt> type for the template argument <tt>Rep</tt>, the program is
ill-formed.</ins>
</p>

<p>
<del>3</del> <ins>4</ins> <i><del>Requires</del> <ins>Remarks</ins>:</i>
<ins>If</ins> <tt>Period</tt> <del>shall be</del> <ins>is not</ins> a
specialization of <tt>ratio</tt>, <del>diagnostic required</del> <ins>the
program is ill-formed</ins>.
</p>

<p>
<del>4</del> <ins>5</ins> <i><del>Requires</del> <ins>Remarks</ins>:</i>
<ins>If</ins> <tt>Period::num</tt> <del>shall be</del> <ins>is not</ins>
positive, <del>diagnostic required</del> <ins>the program is ill-formed</ins>.
</p>
</blockquote>

</li>

<li>
20.11.3.1 [time.duration.cons]/1+4: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
</li>

<li>
20.11.3.5 [time.duration.nonmember]/4+6+8+11: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
</li>

<li>
20.11.3.7 [time.duration.cast]/1: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
</li>

<li>
<p>
Change 20.11.4 [time.point]/2 as indicated:
</p>
<blockquote>
<ins>If</ins> <tt>Duration</tt> <del>shall be</del> <ins>is not</ins> an
instance of <tt>duration</tt><ins>, the program is ill-formed</ins>.
<del>Diagnostic required.</del>
</blockquote>
</li>

<li>
20.11.4.1 [time.point.cons]/3: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
</li>

<li>
20.11.4.7 [time.point.cast]/1: Apply <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1177">1177</a>
</li>

</ol>






<hr>
<h3><a name="1197"></a>1197. Can unordered containers have <tt>bucket_count() == 0</tt>?</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-08-24 <b>Last modified:</b> 2010-10-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 97 "Unordered associative container requirements" in
23.2.5 [unord.req] says:
</p>

<blockquote>
<table border="1">
<caption>Table 97 � Unordered associative container requirements
(in addition to container)</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td><tt>b.bucket(k)</tt></td>
<td><tt>size_type</tt></td>
<td>Returns the index of the bucket in which elements with keys 
equivalent to <tt>k</tt> would be found, 
if any such element existed. 
Post: the return value shall be 
in the range <tt>[0, 
b.bucket_count())</tt>.</td>
<td>Constant</td>
</tr>

</tbody></table>
</blockquote>

<p>
What should <tt>b.bucket(k)</tt> return if <tt>b.bucket_count() == 0</tt>?
</p>

<p>
I believe allowing <tt>b.bucket_count() == 0</tt> is important.  It is a
very reasonable post-condition of the default constructor, or of a moved-from
container.
</p>

<p>
I can think of several reasonable results from <tt>b.bucket(k)</tt> when
<tt>b.bucket_count() == 0</tt>:
</p>

<ol>
<li>
Return 0.
</li>
<li>
Return <tt>numeric_limits&lt;size_type&gt;::max()</tt>.
</li>
<li>
Throw a <tt>domain_error</tt>.
</li>
<li>
Requires: <tt>b.bucket_count() != 0</tt>.
</li>
</ol>

<p><i>[
2009-08-26 Daniel adds:
]</i></p>


<blockquote>
<p>
A forth choice would be to add the pre-condition "<tt>b.bucket_count() != 0</tt>"
and thus imply undefined behavior if this is violated.
</p>

<p><i>[
Howard:  I like this option too, added to the list.
]</i></p>


<p>
Further on here my own favorite solution (rationale see below):
</p>

<p><b>Suggested resolution:</b></p>

<p>
[Rationale: I suggest to follow choice (1). The main reason is
that all associative container functions which take a key argument,
are basically free of pre-conditions and non-disrupting, therefore
excluding choices (3) and (4). Option (2) seems a bit unexpected
to me. It would be more natural, if several similar functions
would exist which would also justify the existence of a symbolic
constant like npos for this situation. The value 0 is both simple
and consistent, it has exactly the same role as a past-the-end
iterator value. A typical use-case is:
</p>

<blockquote><pre>size_type pos = m.bucket(key);
if (pos != m.bucket_count()) {
 ...
} else {
 ...
}
</pre></blockquote>

<p>� end Rationale]</p>

<p>
- Change Table 97 in 23.2.5 [unord.req] as follows (Row b.bucket(k), Column "Assertion/..."):
</p>

<blockquote>
<table border="1">
<caption>Table 97 � Unordered associative container requirements
(in addition to container)</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td><tt>b.bucket(k)</tt></td>
<td><tt>size_type</tt></td>
<td>Returns the index of the bucket in which elements with keys 
equivalent to <tt>k</tt> would be found, 
if any such element existed. 
Post: <ins>if b.bucket_count() != 0, </ins>the return value shall be 
in the range <tt>[0, 
b.bucket_count())</tt><ins>, otherwise 0</ins>.</td>
<td>Constant</td>
</tr>

</tbody></table>
</blockquote>

</blockquote>

<p><i>[
2010-01-25 Choice 4 put into proposed resolution section.
]</i></p>


<p><i>[
2010-01-31 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change Table 97 in 23.2.5 [unord.req] as follows (Row b.bucket(k), Column
"Assertion/..."):
</p>

<blockquote>
<table border="1">
<caption>Table 97 � Unordered associative container requirements
(in addition to container)</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td><tt>b.bucket(k)</tt></td>
<td><tt>size_type</tt></td>
<td><ins>Pre:  <tt>b.bucket_count() &gt; 0</tt></ins> Returns the index of the
bucket in which elements with keys equivalent to <tt>k</tt> would be found, if
any such element existed. Post: the return value shall be in the range <tt>[0,
b.bucket_count())</tt>.</td>
<td>Constant</td>
</tr>

</tbody></table>
</blockquote>






<hr>
<h3><a name="1198"></a>1198. Container adaptor swap: member or non-member?</h3>
<p><b>Section:</b> 23.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-08-26 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Under 23.5 [container.adaptors] of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
the member function of <tt>swap</tt> of <tt>queue</tt> and <tt>stack</tt> call:
</p>

<blockquote><pre>swap(c, q.c);
</pre></blockquote>

<p>
But under 23.5 [container.adaptors] of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
these members are specified to call:
</p>

<blockquote><pre>c.swap(q.c);
</pre></blockquote>

<p>
Neither draft specifies the semantics of member <tt>swap</tt> for
<tt>priority_queue</tt> though it is declared.
</p>

<p>
Although the distinction between member <tt>swap</tt> and non-member
<tt>swap</tt> is not important when these adaptors are adapting standard
containers, it may be important for user-defined containers.
</p>
<p>
We (Pablo and Howard) feel that
it is more likely for a user-defined container to support a namespace scope
<tt>swap</tt> than a member <tt>swap</tt>, and therefore these adaptors
should use the container's namespace scope <tt>swap</tt>.
</p>

<p><i>[
2009-09-30 Daniel adds:
]</i></p>


<blockquote>
The outcome of this issue should be considered with the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a> both in style and in content (e.g. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#774">774</a> bullet 9
suggests to define the semantic of <tt>void
priority_queue::swap(priority_queue&amp;)</tt> in terms of the member
<tt>swap</tt> of the container).
</blockquote>

<p><i>[
2010-03-28 Daniel update to diff against N3092.
]</i></p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote>
Preference to move the wording into normative text, rather than inline function definitions in the class synopsis.

Move to Tenatively Ready.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Change 23.5.1.1 [queue.defn]:
</p>

<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt; 
class queue {
   ...
   void swap(queue&amp; q) { <ins>using std::swap;</ins>
                          <del>c.</del>swap(<ins>c, </ins>q.c); }
   ...
};
</pre></blockquote>

<p>
Change 23.5.2 [priority.queue]:
</p>

<blockquote><pre>template &lt;class T, class Container = vector&lt;T&gt;, 
          class Compare = less&lt;typename Container::value_type&gt; &gt; 
class priority_queue { 
    ...
    void swap(priority_queue&amp; <ins>q</ins>)<del>;</del> <ins>{ using std::swap;</ins>
                                     <ins>swap(c, q.c);</ins>
                                     <ins>swap(comp, q.comp); }</ins>
    ...
};
</pre></blockquote>

<p>
Change 23.5.3.1 [stack.defn]:
</p>

<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt; 
class stack {
   ...
   void swap(stack&amp; s) { <ins>using std::swap;</ins>
                          <del>c.</del>swap(<ins>c, </ins>s.c); }
   ...
};
</pre></blockquote>






<hr>
<h3><a name="1199"></a>1199. Missing extended copy constructor in container adaptors</h3>
<p><b>Section:</b> 23.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-08-26 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>queue</tt> has a constructor:
</p>

<blockquote><pre>template &lt;class Alloc&gt;
  queue(queue&amp;&amp;, const Alloc&amp;);
</pre></blockquote>

<p>
but it is missing a corresponding constructor:
</p>

<blockquote><pre>template &lt;class Alloc&gt;
  queue(const queue&amp;, const Alloc&amp;);
</pre></blockquote>

<p>
The same is true of <tt>priority_queue</tt>, and <tt>stack</tt>.  This
"extended copy constructor" is needed for consistency and to ensure that the
user of a container adaptor can always specify the allocator for his adaptor.
</p>

<p><i>[
2010-02-01 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>[
This resolution has been harmonized with the proposed resolution to issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>
]</i></p>


<p>Change 23.5.1.1 [queue.defn], p1:</p>

<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
class queue {
public:
  typedef typename Container::value_type      value_type;
  typedef typename Container::reference       reference;
  typedef typename Container::const_reference const_reference;
  typedef typename Container::size_type       size_type;
  typedef Container                           container_type;
protected:
  Container c;

public:
  explicit queue(const Container&amp;);
  explicit queue(Container&amp;&amp; = Container());
  queue(queue&amp;&amp; q);

  template &lt;class Alloc&gt; explicit queue(const Alloc&amp;);
  template &lt;class Alloc&gt; queue(const Container&amp;, const Alloc&amp;);
  template &lt;class Alloc&gt; queue(Container&amp;&amp;, const Alloc&amp;);
  <ins>template &lt;class Alloc&gt; queue(const queue&amp;, const Alloc&amp;);</ins>
  template &lt;class Alloc&gt; queue(queue&amp;&amp;, const Alloc&amp;);
  queue&amp; operator=(queue&amp;&amp; q);

  bool empty() const          { return c.empty(); }
  ...
};
</pre></blockquote>

<p>
To the new section 23.5.1.2 [queue.cons], introduced
in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, add:
</p>

<blockquote>

<pre>template &lt;class Alloc&gt; 
  queue(const queue&amp; q, const Alloc&amp; a);
</pre>

<blockquote><p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>q.c</tt> as the
first argument and <tt>a</tt> as the second argument.
</p></blockquote>

</blockquote>

<p>Change 23.5.2 [priority.queue] as follows (I've an included an editorial change to
  move the poorly-placed move-assignment operator):</p>

<blockquote><pre>template &lt;class T, class Container = vector&lt;T&gt;,
          class Compare = less&lt;typename Container::value_type&gt; &gt;
class priority_queue {
public:
  typedef typename Container::value_type      value_type;
  typedef typename Container::reference       reference;
  typedef typename Container::const_reference const_reference;
  typedef typename Container::size_type       size_type;
  typedef          Container                  container_type;
protected:
  Container c;
  Compare comp;

public:
  priority_queue(const Compare&amp; x, const Container&amp;);
  explicit priority_queue(const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
  template &lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last,
                   const Compare&amp; x, const Container&amp;);
  template &lt;class InputIterator&gt;
    priority_queue(InputIterator first, InputIterator last,
                   const Compare&amp; x = Compare(), Container&amp;&amp; = Container());
  priority_queue(priority_queue&amp;&amp;);
  <del>priority_queue&amp; operator=(priority_queue&amp;&amp;);</del>
  template &lt;class Alloc&gt; explicit priority_queue(const Alloc&amp;);
  template &lt;class Alloc&gt; priority_queue(const Compare&amp;, const Alloc&amp;);
  template &lt;class Alloc&gt; priority_queue(const Compare&amp;,
                                        const Container&amp;, const Alloc&amp;);
  template &lt;class Alloc&gt; priority_queue(const Compare&amp;,
                                        Container&amp;&amp;, const Alloc&amp;);
  <ins>template &lt;class Alloc&gt; priority_queue(const priority_queue&amp;, const Alloc&amp;);</ins>
  template &lt;class Alloc&gt; priority_queue(priority_queue&amp;&amp;, const Alloc&amp;);

  <ins>priority_queue&amp; operator=(priority_queue&amp;&amp;);</ins>
  ...
};
</pre></blockquote>

<p>
Add to 23.5.2.1 [priqueue.cons]:
</p>

<blockquote>

<pre>template &lt;class Alloc&gt;
  priority_queue(const priority_queue&amp; q, const Alloc&amp; a);
</pre>

<blockquote><p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>q.c</tt> as the
first argument and <tt>a</tt> as the second argument, 
and initializes <tt>comp</tt> with <tt>q.comp</tt>.
</p></blockquote>

</blockquote>

<p>
Change 23.5.3.1 [stack.defn]:
</p>

<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
class stack {
public:
  typedef typename Container::value_type      value_type;
  typedef typename Container::reference       reference;
  typedef typename Container::const_reference const_reference;
  typedef typename Container::size_type       size_type;
  typedef Container                           container_type;
protected:
  Container c;

public:
  explicit stack(const Container&amp;);
  explicit stack(Container&amp;&amp; = Container());
  stack(stack&amp;&amp; s);

  template &lt;class Alloc&gt; explicit stack(const Alloc&amp;);
  template &lt;class Alloc&gt; stack(const Container&amp;, const Alloc&amp;);
  template &lt;class Alloc&gt; stack(Container&amp;&amp;, const Alloc&amp;);
  <ins>template &lt;class Alloc&gt; stack(const stack&amp;, const Alloc&amp;);</ins>
  template &lt;class Alloc&gt; stack(stack&amp;&amp;, const Alloc&amp;);
  stack&amp; operator=(stack&amp;&amp; s);

  bool empty() const          { return c.empty(); }
  ...
};
</pre></blockquote>

<p>
To the new section 23.5.3.2 [stack.cons], introduced
in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a>, add:
</p>

<blockquote>

<pre>template &lt;class Alloc&gt; 
  stack(const stack&amp; s, const Alloc&amp; a);
</pre>

<blockquote><p>
<i>Effects:</i> Initializes <tt>c</tt> with <tt>s.c</tt> as the
first argument and <tt>a</tt> as the second argument.
</p></blockquote>
</blockquote>






<hr>
<h3><a name="1204"></a>1204. Global permission to move</h3>
<p><b>Section:</b> 17.6.3.9 [res.on.arguments] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.arguments">issues</a> in [res.on.arguments].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When a library function binds an rvalue reference parameter to an argument, the
library must be able to assume that the bound argument is a temporary, and not
a moved-from lvalue.  The reason for this is that the library function must be
able to modify that argument without concern that such modifications will corrupt
the logic of the calling code.  For example:
</p>

<blockquote><pre>template &lt;class T, class A&gt;
void
vector&lt;T, A&gt;::push_back(value_type&amp;&amp; v)
{
    <font color="#C80000">// This function should move from v, potentially modifying</font>
    <font color="#C80000">//   the object v is bound to.</font>
}
</pre></blockquote>

<p>
If <tt>v</tt> is truly bound to a temporary, then <tt>push_back</tt> has the
<em>only</em> reference to this temporary in the entire program.  Thus any
modifications will be invisible to the rest of the program.
</p>

<p>
If the client supplies <tt>std::move(x)</tt> to <tt>push_back</tt>, the onus is
on the client to ensure that the value of <tt>x</tt> is no longer important to
the logic of his program after this statement.  I.e. the client is making a statement
that <tt>push_back</tt> may treat <tt>x</tt> as a temporary.
</p>

<blockquote><em>
The above statement is the very foundation upon which move semantics is based.
</em></blockquote>

<p>
The standard is currently lacking a global statement to this effect.  I propose
the following addition to 17.6.3.9 [res.on.arguments]:
</p>

<blockquote>
<p>
Each of the following statements applies to all arguments to functions
defined in the C++ standard library, unless explicitly stated otherwise.
</p>
<ul>
<li>
If an argument to a function has an invalid value (such as a value
outside the domain of the function, or a pointer invalid for its
intended use), the behavior is undefined.
</li>
<li>
If a function argument is described as being an array, the pointer
actually passed to the function shall have a value such that all address
computations and accesses to objects (that would be valid if the pointer
did point to the first element of such an array) are in fact valid.
</li>
<li><ins>
If a function argument binds to an rvalue reference parameter, the C++
standard library may assume that this parameter is a unique reference
to this argument.  If the parameter is a generic parameter of the
form <tt>T&amp;&amp;</tt>, and an lvalue of type <tt>A</tt> is bound,
then the binding is considered to be to an lvalue reference
(14.8.2.1 [temp.deduct.call]) and thus not covered by this clause.
[<i>Note:</i>
If a program casts an lvalue to an rvalue while passing that lvalue to
a library function (e.g. <tt>move(x)</tt>), then the program is effectively
asking the library to treat that lvalue as a temporary.  The library is at
liberty to optimize away aliasing checks which might be needed if the argument
were an lvalue.
� <i>end note</i>]
</ins></li>
</ul>

</blockquote>

<p>
Such a global statement will eliminate the need for piecemeal statements such as
23.2.1 [container.requirements.general]/13:
</p>

<blockquote>
An object bound to an rvalue reference parameter of a member function of
a container shall not be an element of that container; no diagnostic
required.
</blockquote>

<p>
Additionally this clarifies that move assignment operators need not perform the
traditional <tt>if (this != &amp;rhs)</tt> test commonly found (and needed) in
copy assignment operators.
</p>

<p><i>[
2009-09-13 Niels adds:
]</i></p>


<blockquote>
Note: This resolution supports the change of 27.9.1.3 [filebuf.assign]/1,
proposed by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#900">900</a>.
</blockquote>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add a bullet to 17.6.3.9 [res.on.arguments]:
</p>

<blockquote>
<p>
Each of the following statements applies to all arguments to functions
defined in the C++ standard library, unless explicitly stated otherwise.
</p>
<ul>
<li>
If an argument to a function has an invalid value (such as a value
outside the domain of the function, or a pointer invalid for its
intended use), the behavior is undefined.
</li>
<li>
If a function argument is described as being an array, the pointer
actually passed to the function shall have a value such that all address
computations and accesses to objects (that would be valid if the pointer
did point to the first element of such an array) are in fact valid.
</li>
<li><ins>
If a function argument binds to an rvalue reference parameter, the C++
standard library may assume that this parameter is a unique reference
to this argument.  If the parameter is a generic parameter of the
form <tt>T&amp;&amp;</tt>, and an lvalue of type <tt>A</tt> is bound,
then the binding is considered to be to an lvalue reference
(14.8.2.1 [temp.deduct.call]) and thus not covered by this clause.
[<i>Note:</i>
If a program casts an lvalue to an rvalue while passing that lvalue to
a library function (e.g. <tt>move(x)</tt>), then the program is effectively
asking the library to treat that lvalue as a temporary.  The library is at
liberty to optimize away aliasing checks which might be needed if the argument
were an lvalue.
� <i>end note</i>]
</ins></li>
</ul>
</blockquote>

<p>
Delete 23.2.1 [container.requirements.general]/13:
</p>

<blockquote><del>
An object bound to an rvalue reference parameter of a member function of
a container shall not be an element of that container; no diagnostic
required.
</del></blockquote>






<hr>
<h3><a name="1205"></a>1205. Some algorithms could more clearly document their handling of empty ranges</h3>
<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-09-13 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are a number of algorithms whose result might depend on the
handling of an empty range.  In some cases the result is not clear,
while in others it would help readers to clearly mention the result
rather than require some subtle intuition of the supplied wording.
</p>

<p>
25.2.1 [alg.all_of]
</p>

<blockquote>
<i>Returns:</i> <tt>true</tt> if <tt>pred(*i)</tt> is <tt>true</tt> for every
iterator <tt>i</tt> in the range <tt>[first,last)</tt>, ...
</blockquote>

<p>
What does this mean if the range is empty?
</p>

<p>
I believe that we intend this to be <tt>true</tt> and suggest a
non-normative note to clarify:
</p>

<p>
Add to p1 25.2.1 [alg.all_of]:
</p>

<blockquote>
[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
� <i>end note</i>]
</blockquote>

<p>
25.2.3 [alg.none_of]
</p>

<blockquote>
<i>Returns:</i> <tt>true</tt> if <tt>pred(*i)</tt> is <tt>false</tt> for every
iterator <tt>i</tt> in the range <tt>[first,last)</tt>, ...
</blockquote>

<p>
What does this mean if the range empty?
</p>

<p>
I believe that we intend this to be <tt>true</tt> and suggest a
non-normative note to clarify:
</p>

<p>
Add to p1 25.2.3 [alg.none_of]:
</p>

<blockquote>
[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
� <i>end note</i>]
</blockquote>

<p>
25.2.2 [alg.any_of]
</p>

<p>
The specification for an empty range is actually fairly clear in this
case, but a note wouldn't hurt and would be consistent with proposals
for <tt>all_of</tt>/<tt>none_of</tt> algorithms.
</p>

<p>
Add to p1 25.2.2 [alg.any_of]:
</p>

<blockquote>
[<i>Note:</i> Returns <tt>false</tt> if <tt>[first,last)</tt> is empty. 
� <i>end note</i>]
</blockquote>

<p>
25.2.6 [alg.find.end]
</p>

<p>
what does this mean if <tt>[first2,last2)</tt> is empty?
</p>

<p>
I believe the wording suggests the algorithm should return
<tt>last1</tt> in this case, but am not 100% sure. Is this in fact the
correct result anyway? Surely an empty range should always match and the
naive expected result would be <tt>first1</tt>?
</p>

<p>
My proposed wording is a note to clarify the current semantic:
</p>

<p>
Add to p2 25.2.6 [alg.find.end]:
</p>

<blockquote>
[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
empty. � <i>end note</i>]
</blockquote>

<p>
I would prefer a normative wording treating empty ranges specially, but
do not believe we can change semantics at this point in the process,
unless existing implementations actually yield this result:
</p>

<p>
Alternative wording: (NOT a note)
</p>
<p>
Add to p2 25.2.6 [alg.find.end]:
</p>
<blockquote>
Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
</blockquote>

<p>
25.2.7 [alg.find.first.of]
</p>

<p>
The phrasing seems precise when <tt>[first2, last2)</tt> is empty, but a small
note to confirm the reader's understanding might still help.
</p>

<p>
Add to p2 25.2.7 [alg.find.first.of]
</p>
<blockquote>
[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
empty. � <i>end note</i>]
</blockquote>

<p>
25.2.13 [alg.search]
</p>

<p>
What is the expected result if <tt>[first2, last2)</tt> is empty?
</p>

<p>
I believe the wording suggests the algorithm should return <tt>last1</tt> in this
case, but am not 100% sure. Is this in fact the correct result anyway? 
Surely an empty range should always match and the naive expected result
would be <tt>first1</tt>?
</p>

<p>
My proposed wording is a note to clarify the current semantic:
</p>

<p>
Add to p2 25.2.13 [alg.search]:
</p>

<blockquote>
[<i>Note:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
empty. � <i>end note</i>]
</blockquote>

<p>
Again, I would prefer a normative wording treating empty ranges
specially, but do not believe we can change semantics at this point in
the process, unless existing implementations actually yield this result:
</p>

<p>
Alternative wording: (NOT a note)
</p>
<p>
Add to p2 25.2.13 [alg.search]:
</p>

<blockquote>
Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
</blockquote>

<p>
25.3.13 [alg.partitions]
</p>

<p>
Is an empty range partitioned or not?
</p>

<p>
Proposed wording:
</p>

<p>
Add to p1 25.3.13 [alg.partitions]:
</p>

<blockquote>
[<i>Note:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
� <i>end note</i>]
</blockquote>

<p>
25.4.5.1 [includes]
</p>

<blockquote>
<i>Returns:</i> <tt>true</tt> if every element in the range
<tt>[first2,last2)</tt> is contained in the range
<tt>[first1,last1)</tt>. ...
</blockquote>

<p>
I really don't know what this means if <tt>[first2,last2)</tt> is empty.
I could loosely guess that this implies empty ranges always match, and
my proposed wording is to clarify exactly that:
</p>

<p>
Add to p1 25.4.5.1 [includes]:
</p>

<blockquote>
[<i>Note:</i> Returns <tt>true</tt> if <tt>[first2,last2)</tt> is empty.
� <i>end note</i>]
</blockquote>

<p>
25.4.6.2 [pop.heap]
</p>

<p>
The effects clause is invalid if the range <tt>[first,last)</tt> is empty, unlike
all the other heap alogorithms.  The should be called out in the
requirements.
</p>

<p>
Proposed wording:
</p>
<p>
Revise p2 25.4.6.2 [pop.heap]
</p>

<blockquote>
<i>Requires:</i> The range <tt>[first,last)</tt> shall be a valid
<ins>non-empty</ins> heap.
</blockquote>

<p>
[Editorial] Reverse order of 25.4.6.2 [pop.heap] p1 and p2.
</p>

<p>
25.4.7 [alg.min.max]
</p>

<p>
<tt>minmax_element</tt> does not clearly specify behaviour for an empty
range in the same way that <tt>min_element</tt> and <tt>max_element</tt> do.
</p>

<p>
Add to p31 25.4.7 [alg.min.max]:
</p>

<blockquote>
Returns <tt>make_pair(first, first)</tt> if <tt>first == last</tt>.
</blockquote>

<p>
25.4.8 [alg.lex.comparison]
</p>

<p>
The wording here seems quite clear, especially with the sample algorithm
implementation.  A note is recommended purely for consistency with the
rest of these issue resolutions:
</p>

<p>
Add to p1 25.4.8 [alg.lex.comparison]:
</p>

<blockquote>
[<i>Note:</i> An empty sequence is lexicographically less than any other
non-empty sequence, but not to another empty sequence. � <i>end note</i>]
</blockquote>

<p><i>[
2009-11-11 Howard changes Notes to Remarks and changed <tt>search</tt> to
return <tt>first1</tt> instead of <tt>last1</tt>.
]</i></p>


<p><i>[
2009-11-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Add to 25.2.1 [alg.all_of]:
</p>
<blockquote><ins>
<i>Remarks:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
</ins></blockquote>

<p>
Add to 25.2.2 [alg.any_of]:
</p>

<blockquote><ins>
<i>Remarks:</i> Returns <tt>false</tt> if <tt>[first,last)</tt> is empty. 
</ins></blockquote>

<p>
Add to 25.2.3 [alg.none_of]:
</p>
<blockquote><ins>
<i>Remarks:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
</ins></blockquote>

<p>
Add to 25.2.6 [alg.find.end]:
</p>
<blockquote><ins>
<i>Remarks:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
empty.
</ins></blockquote>

<p>
Add to 25.2.7 [alg.find.first.of]
</p>
<blockquote><ins>
<i>Remarks:</i> Returns <tt>last1</tt> if <tt>[first2,last2)</tt> is
empty.
</ins></blockquote>

<p>
Add to 25.2.13 [alg.search]:
</p>
<blockquote><ins>
<i>Remarks:</i> Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is
empty.
</ins></blockquote>

<p>
Add to 25.3.13 [alg.partitions]:
</p>
<blockquote><ins>
<i>Remarks:</i> Returns <tt>true</tt> if <tt>[first,last)</tt> is empty. 
</ins></blockquote>

<p>
Add to 25.4.5.1 [includes]:
</p>
<blockquote><ins>
<i>Remarks:</i> Returns <tt>true</tt> if <tt>[first2,last2)</tt> is empty. 
</ins></blockquote>

<p>
Revise p2 25.4.6.2 [pop.heap]
</p>
<blockquote>
<i>Requires:</i> The range <tt>[first,last)</tt> shall be a valid
<ins>non-empty</ins> heap.
</blockquote>

<p>
[Editorial] 
</p>
<blockquote>
Reverse order of 25.4.6.2 [pop.heap] p1 and p2.
</blockquote>

<p>
Add to p35 25.4.7 [alg.min.max]:
</p>
<blockquote><pre>template&lt;class ForwardIterator, class Compare&gt;
  pair&lt;ForwardIterator, ForwardIterator&gt;
    minmax_element(ForwardIterator first, ForwardIterator last, Compare comp);
</pre>
<blockquote>
<i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is the first iterator in
<tt>[first,last)</tt> such that no iterator in the range refers to a smaller
element, and where <tt>M</tt> is the last iterator in <tt>[first,last)</tt> such that no
iterator in the range refers to a larger element. 
<ins>Returns <tt>make_pair(first, first)</tt> if <tt>first == last</tt>.</ins>
</blockquote>
</blockquote>

<p>
Add to 25.4.8 [alg.lex.comparison]:
</p>
<blockquote><ins>
<i>Remarks:</i> An empty sequence is lexicographically less than any other
non-empty sequence, but not less than another empty sequence.
</ins></blockquote>






<hr>
<h3><a name="1206"></a>1206. Incorrect requires for <tt>move_backward</tt> and <tt>copy_backward</tt></h3>
<p><b>Section:</b> 25.3.2 [alg.move] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-13 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
25.3.2 [alg.move], p6 says:
</p>

<blockquote>
<pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
  BidirectionalIterator2
    move_backward(BidirectionalIterator1 first,
                  BidirectionalIterator1 last,
                  BidirectionalIterator2 result);
</pre>
<blockquote>
<p>...</p>
<p>
<i>Requires:</i> <tt>result</tt> shall not be in the range
<tt>[first,last)</tt>.
</p>
</blockquote>
</blockquote>

<p>
This is essentially an "off-by-one" error.
</p>

<p>
When <tt>result == last</tt>, which
<em>is</em> allowed by this specification, then the range <tt>[first, last)</tt>
is being move assigned into the range <tt>[first, last)</tt>.  The <tt>move</tt>
(forward) algorithm doesn't allow self move assignment, and neither should
<tt>move_backward</tt>.  So <tt>last</tt> should be included in the range which
<tt>result</tt> can not be in.
</p>

<p>
Conversely, when <tt>result == first</tt>, which <em>is not</em> allowed by this
specification, then the range <tt>[first, last)</tt>
is being move assigned into the range <tt>[first - (last-first), first)</tt>.
I.e. into a <em>non-overlapping</em> range.  Therefore <tt>first</tt> should
not be included in the range which <tt>result</tt> can not be in.
</p>

<p>
The same argument applies to <tt>copy_backward</tt> though copy assigning elements
to themselves (<tt>result == last</tt>) should be harmless (though is disallowed
by <tt>copy</tt>).
</p>

<p><i>[
2010 Pittsburgh:  Moved to Ready.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 25.3.2 [alg.move], p6:
</p>

<blockquote>
<pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
  BidirectionalIterator2
    move_backward(BidirectionalIterator1 first,
                  BidirectionalIterator1 last,
                  BidirectionalIterator2 result);
</pre>
<blockquote>
<p>...</p>
<p>
<i>Requires:</i> <tt>result</tt> shall not be in the range
<tt><del>[</del><ins>(</ins>first,last<ins>]</ins><del>)</del></tt>.
</p>
</blockquote>
</blockquote>

<p>
Change 25.3.1 [alg.copy], p13:
</p>

<blockquote>
<pre>template&lt;class BidirectionalIterator1, class BidirectionalIterator2&gt;
  BidirectionalIterator2
    copy_backward(BidirectionalIterator1 first,
                  BidirectionalIterator1 last,
                  BidirectionalIterator2 result);
</pre>
<blockquote>
<p>...</p>
<p>
<i>Requires:</i> <tt>result</tt> shall not be in the range
<tt><del>[</del><ins>(</ins>first,last<ins>]</ins><del>)</del></tt>.
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="1207"></a>1207. Underspecified std::list operations?</h3>
<p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Lo�c Joly <b>Opened:</b> 2009-09-13 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It looks to me like some operations of <tt>std::list</tt>
(<tt>sort</tt>, <tt>reverse</tt>, <tt>remove</tt>, <tt>unique</tt> &amp;
<tt>merge</tt>) do not specify the validity of iterators, pointers &amp;
references to elements of the list after those operations. Is it implied
by some other text in the standard?
</p>

<p>
I believe <tt>sort</tt> &amp; <tt>reverse</tt> do not invalidating
anything, <tt>remove</tt> &amp; <tt>unique</tt> only invalidates what
refers to erased elements, <tt>merge</tt> does not invalidate anything
(with the same precision as <tt>splice</tt> for elements who changed of
container). Are those assumptions correct ?
</p>

<p><i>[
2009-12-08 Jonathan Wakely adds:
]</i></p>


<blockquote>
<p>
23.2.1 [container.requirements.general] paragraph 11 says iterators
aren't invalidated unless specified, so I don't think it needs to be repeated on
every function that doesn't invalidate iterators. <tt>list::unique</tt> says it
"eliminates" elements, that should probably be "erases" because IMHO that term
is used elsewhere and so makes it clearer that iterators to the erased elements
are invalidated.
</p>

<p>
<tt>list::merge</tt> coud use the same wording as <tt>list::splice</tt> w.r.t
iterators and references to moved elements.
</p>

<p>
Suggested resolution:
</p>

<p>
In 23.3.4.4 [list.ops] change paragraph 19
</p>

<blockquote><pre>                                 void unique();
template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
</pre>
<blockquote>
<i>Effects:</i> <del>Eliminates</del> <ins>Erases</ins> all but the first
element from every consecutive group ...
</blockquote>
</blockquote>

<p>
Add to the end of paragraph 23
</p>

<blockquote><pre>void                          merge(list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<p>...</p>
<p>
<i>Effects:</i> ... that is, for every iterator <tt>i</tt>, in the range other
than the first, the condition <tt>comp(*i, *(i - 1)</tt> will be false.
<ins>Pointers and references to the moved elements of <tt>x</tt> now refer to
those same elements but as members of <tt>*this</tt>. Iterators referring to the
moved elements will continue to refer to their elements, but they now behave as
iterators into <tt>*this</tt>, not into <tt>x</tt>.</ins>
</p>
</blockquote>
</blockquote>
</blockquote>

<p><i>[
2009-12-12 Lo�c adds wording.
]</i></p>


<p><i>[
2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-02-10 Alisdair opens:
]</i></p>


<blockquote>
<p>
I object to the current resolution of #1207.  I believe it is overly strict with
regard to <tt>list</tt> end iterators, being the only mutating operations to
require such stability.
</p>

<p>
More importantly, the same edits need to be applied to <tt>forward_list</tt>,
which uses slightly different words to describe some of these operations so may
require subtly different edits (not checked.)
</p>

<p>
I am prepared to pick up the <tt>end()</tt> iterator as a separate (new) issue,
as part of the FCD ballot review (BSI might tell me 'no' first ;~) but I do want
to see <tt>forward_list</tt> adjusted at the same time.
</p>
</blockquote>

<p><i>[
2010-03-28 Daniel adds the first 5 bullets in an attempt to address Alisdair's
concerns.
]</i></p>



<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote>
The wording looks good.

Move to Tentatively Ready.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/12 as indicated:
</p>

<blockquote><pre>void remove(const T&amp; value);
template &lt;class Predicate&gt; void remove_if(Predicate pred);
</pre>

<blockquote>
12 <i>Effects:</i> Erases all the elements in the list referred by a list
iterator <tt>i</tt> for which the following conditions hold: <tt>*i == value
(for remove()), pred(*i)</tt> is true (<tt>for remove_if()</tt>). This operation
shall be stable: the relative order of the elements that are not removed is the
same as their relative order in the original list. <ins>Invalidates only the
iterators and references to the erased elements.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/15 as indicated:
</p>

<blockquote><pre>template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate pred);
</pre>

<blockquote>
15 <i>Effects:</i>: <del>Eliminates</del><ins>Erases</ins> all but the first
element from every consecutive group of equal elements referred to by the
iterator <tt>i</tt> in the range <tt>[first + 1,last)</tt> for which <tt>*i ==
*(i-1)</tt> (for the version with no arguments) or <tt>pred(*i, *(i - 1))</tt>
(for the version with a predicate argument) holds. <ins>Invalidates only the
iterators and references to the erased elements.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/19 as indicated:
</p>

<blockquote><pre>void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(forward_list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp)
</pre>

<blockquote>
<p>
[..]
</p>

<p>
19 <i>Effects:</i>: Merges <tt>x</tt> into <tt>*this</tt>. This operation shall
be stable: for equivalent elements in the two lists, the elements from
<tt>*this</tt> shall always precede the elements from <tt>x</tt>. <tt>x</tt> is
empty after the merge. If an exception is thrown other than by a comparison
there are no effects. <ins>Pointers and references to the moved elements of
<tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>.
Iterators referring to the moved elements will continue to refer to their
elements, but they now behave as iterators into <tt>*this</tt>, not into
<tt>x</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/22 as indicated:
</p>

<blockquote><pre>void sort();
template &lt;class Compare&gt; void sort(Compare comp);
</pre>

<blockquote>
<p>
[..]
</p>

<p>
22 <i>Effects:</i>: Sorts the list according to the <tt>operator&lt;</tt> or the
<tt>comp</tt> function object. This operation shall be stable: the relative
order of the equivalent elements is preserved. If an exception is thrown the
order of the elements in <tt>*this</tt> is unspecified. <ins>Does not affect the
validity of iterators and references.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.3.5 [forwardlist.ops]/24 as indicated:
</p>

<blockquote><pre>void reverse();
</pre>

<blockquote>
24 <i>Effects:</i>: Reverses the order of the elements in the list. <ins>Does
not affect the validity of iterators and references.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p15:
</p>

<blockquote><pre>                           void remove(const T&amp; value);
template &lt;class Predicate&gt; void remove_if(Predicate pred);
</pre>
<blockquote>
<i>Effects:</i> Erases all the elements in the list referred by a list iterator
<tt>i</tt> for which the following conditions hold: <tt>*i == value, pred(*i) !=
false</tt>.  <ins>Invalidates only the iterators and references to the erased
elements.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p19:
</p>

<blockquote><pre>                                 void unique();
template &lt;class BinaryPredicate&gt; void unique(BinaryPredicate binary_pred);
</pre>
<blockquote>
<i>Effects:</i> <del>Eliminates</del> <ins>Erases</ins> all but the first
element from every consecutive group of equal elements referred to by the
iterator <tt>i</tt> in the range <tt>[first + 1,last)</tt> for which <tt>*i ==
*(i-1)</tt> (for the version of <tt>unique</tt> with no arguments) or
<tt>pred(*i, *(i - 1))</tt> (for the version of <tt>unique</tt> with a predicate
argument) holds. <ins>Invalidates only the iterators and references to the
erased elements.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p23:
</p>

<blockquote><pre>void                          merge(list&lt;T,Allocator&gt;&amp;&amp; x);
template &lt;class Compare&gt; void merge(list&lt;T,Allocator&gt;&amp;&amp; x, Compare comp);
</pre>
<blockquote>
<i>Effects:</i> If <tt>(&amp;x == this)</tt> does nothing; otherwise, merges the
two sorted ranges <tt>[begin(), end())</tt> and <tt>[x.begin(), x.end())</tt>.
The result is a range in which the elements will be sorted in non-decreasing
order according to the ordering defined by <tt>comp</tt>; that is, for every
iterator <tt>i</tt>, in the range other than the first, the condition
<tt>comp(*i, *(i - 1)</tt> will be false.
<ins>Pointers and references to the moved elements of <tt>x</tt> now refer to
those same elements but as members of <tt>*this</tt>. Iterators referring to the
moved elements will continue to refer to their elements, but they now behave as
iterators into <tt>*this</tt>, not into <tt>x</tt>.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p26:
</p>

<blockquote><pre>void reverse();
</pre>
<blockquote>
<i>Effects:</i> Reverses the order of the elements in the list.
<ins>Does not affect the validity of iterators and references.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 23.3.4.4 [list.ops], p30:
</p>

<blockquote><pre>                         void sort();
template &lt;class Compare&gt; void sort(Compare comp);
</pre>
<blockquote>
<i>Effects:</i> Sorts the list according to the <tt>operator&lt;</tt> or a
<tt>Compare</tt> function object.
<ins>Does not affect the validity of iterators and references.</ins>
</blockquote>
</blockquote>
</li>

</ol>






<hr>
<h3><a name="1208"></a>1208. valarray initializer_list constructor has incorrect effects</h3>
<p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-23 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
26.6.2.1 [valarray.cons] says:
</p>

<blockquote>
<pre>valarray(initializer_list&lt;T&gt; il);
</pre>
<blockquote>
<i>Effects:</i> Same as <tt>valarray(il.begin(), il.end())</tt>.
</blockquote>
</blockquote>

<p>
But there is no <tt>valarray</tt> constructor taking two <tt>const T*</tt>.
</p>

<p><i>[
2009-10-29 Howard:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 6 positive votes on c++std-lib.
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Change 26.6.2.1 [valarray.cons]:
</p>

<blockquote>
<pre>valarray(initializer_list&lt;T&gt; il);
</pre>
<blockquote>
<i>Effects:</i> Same as <tt>valarray(il.begin(), il.<del>end</del><ins>size</ins>())</tt>.
</blockquote>
</blockquote>





<hr>
<h3><a name="1209"></a>1209. match_results should be moveable</h3>
<p><b>Section:</b> 28.10.1 [re.results.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-09-15 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Working Draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
<tt>match_results</tt> lacks a move constructor and move
assignment operator. Because it owns dynamically allocated memory, it
should be moveable.
</p>

<p>
As far as I can tell, this isn't tracked by an active issue yet; Library
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a> doesn't talk about <tt>match_results</tt>.
</p>

<p><i>[
2009-09-21 Daniel provided wording.
]</i></p>


<p><i>[
2009-11-18: Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Add the following member declarations to 28.10 [re.results]/3:
</p>

<blockquote><pre>// 28.10.1, construct/copy/destroy:
explicit match_results(const Allocator&amp; a = Allocator());
match_results(const match_results&amp; m);
<ins>match_results(match_results&amp;&amp; m);</ins>
match_results&amp; operator=(const match_results&amp; m);
<ins>match_results&amp; operator=(match_results&amp;&amp; m);</ins>
~match_results();
</pre></blockquote>
</li>

<li>
<p>
Add the following new prototype descriptions to 28.10.1 [re.results.const]
using the table numbering of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
(referring to the table titled "<tt>match_results</tt> assignment operator effects"):
</p>

<blockquote>
<pre>match_results(const match_results&amp; m);
</pre>

<blockquote>
4 <i>Effects:</i> Constructs an object of class <tt>match_results</tt>, as a
copy of <tt>m</tt>.
</blockquote>

<pre><ins>match_results(match_results&amp;&amp; m);</ins>
</pre>

<blockquote>
<p>
<ins>5 <i>Effects:</i> Move-constructs an object of class <tt>match_results</tt>
from <tt>m</tt> satisfying the same postconditions as Table 131. Additionally
the stored <tt>Allocator</tt> value is move constructed from <tt>m.get_allocator()</tt>.
After the initialization of <tt>*this</tt> sets <tt>m</tt> to an unspecified but valid
state.</ins>
</p>

<p>
<ins>6 <i>Throws:</i> Nothing if the allocator's move constructor throws nothing.</ins>
</p>
</blockquote>

<pre>match_results&amp; operator=(const match_results&amp; m);
</pre>

<blockquote>
7 <i>Effects:</i> Assigns <tt>m</tt> to <tt>*this</tt>. The postconditions of this function are
indicated in Table 131.
</blockquote>

<pre><ins>match_results&amp; operator=(match_results&amp;&amp; m);</ins>
</pre>

<blockquote>
<p>
<ins>8 <i>Effects:</i> Move-assigns <tt>m</tt> to <tt>*this</tt>. The postconditions of this
function are indicated in Table 131. After the assignment, <tt>m</tt> is in
a valid but unspecified state.</ins>
</p>

<p>
<ins>9 <i>Throws:</i> Nothing.</ins>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="1216"></a>1216. LWG 1066 Incomplete?</h3>
<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-09-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a> adds <tt>[[noreturn]]</tt> to a bunch of things.
It doesn't add it to <tt>rethrow_nested()</tt>, which seems like an obvious
candidate. I've made the changes indicated in the issue, and haven't
changed <tt>rethrow_nested()</tt>.
</p>

<p><i>[
2009 Santa Cruz:
]</i></p>


<blockquote>
Move to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Add <tt>[[noreturn]]</tt> to <tt>rethrow_nested()</tt> in 18.8.6 [except.nested].
</p>





<hr>
<h3><a name="1218"></a>1218. mutex destructor synchronization</h3>
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
If an object <tt>*o</tt> contains a mutex <tt>mu</tt> and a
correctly-maintained reference count <tt>c</tt>, is the following code
safe?
</p>

<blockquote><pre>o-&gt;mu.lock();
bool del = (--(o-&gt;c) == 0);
o-&gt;mu.unlock();
if (del) { delete o; }
</pre></blockquote>

<p>
If the implementation of <tt>mutex::unlock()</tt> can touch the mutex's
memory after the moment it becomes free, this wouldn't be safe, and
"Construction and destruction of an object of a Mutex type need not be
thread-safe" 30.4.1 [thread.mutex.requirements] may imply that
it's not safe. Still, it's useful to allow mutexes to guard reference
counts, and if it's not allowed, users are likely to write bugs.
</p>

<p><i>[
2009-11-18: Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<ul>
<li>
<p>
Add a new paragraph after 30.4.1.2.1 [thread.mutex.class] p1:
</p>
<blockquote>
<p>
1 The class <tt>mutex</tt> provides a non-recursive mutex ...
</p>
<p><ins>
[<i>Note:</i> After a thread <tt>A</tt> has called <tt>unlock()</tt>, releasing
the mutex, it is possible for another thread <tt>B</tt> to lock the same mutex,
observe that it is no longer in use, unlock and destroy it, before thread
<tt>A</tt> appears to have returned from its unlock call. Implementations are
required to handle such scenarios correctly, as long as thread <tt>A</tt>
doesn't access the mutex after the unlock call returns. These cases typically
occur when a reference-counted object contains a mutex that is used to protect
the reference count. � <i>end note</i>]
</ins></p>
</blockquote>
</li>

</ul>





<hr>
<h3><a name="1220"></a>1220. What does condition_variable wait on?</h3>
<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
"Class <tt>condition_variable</tt> provides a condition variable that can only
wait on an object of type <tt>unique_lock</tt>" should say "...object of type
<tt>unique_lock&lt;mutex&gt;</tt>"
</p>

<p><i>[
2009-11-06 Howard adds:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 30.5 [thread.condition], p1:
</p>

<blockquote>
Condition variables provide synchronization primitives used to block a
thread until notified by some other thread that some condition is met or
until a system time is reached. Class <tt>condition_variable</tt>
provides a condition variable that can only wait on an object of type
<tt>unique_lock<ins>&lt;mutex&gt;</ins></tt>, allowing maximum
efficiency on some platforms. Class <tt>condition_variable_any</tt>
provides a general condition variable that can wait on objects of
user-supplied lock types.
</blockquote>





<hr>
<h3><a name="1221"></a>1221. condition_variable wording</h3>
<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.5.1 [thread.condition.condvar] says:
</p>

<blockquote>
<pre>~condition_variable();
</pre>
<blockquote>
<i>Precondition:</i> There shall be no thread blocked on <tt>*this</tt>.
[<i>Note:</i> That is, all threads shall have been notified; they may
subsequently block on the lock specified in the wait. Beware that
destroying a <tt>condition_variable</tt> object while the corresponding
predicate is <tt>false</tt> is likely to lead to undefined behavior.
� <i>end note</i>]
</blockquote>
</blockquote>

<p>
The text hasn't introduced the notion of a "corresponding predicate"
yet.
</p>

<p><i>[
2010-02-11 Anthony provided wording.
]</i></p>


<p><i>[
2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Modify 30.5.1 [thread.condition.condvar]p4 as follows:
</p>

<blockquote>
<pre>~condition_variable();</pre>
<blockquote>
4 <i>Precondition:</i> There shall be no thread blocked on <tt>*this</tt>.
[<i>Note:</i> That is, all threads shall have been notified; they may
subsequently block on the lock specified in the wait. <del>Beware that
destroying a <tt>condition_variable</tt> object while the corresponding
predicate is false is likely to lead to undefined behavior.</del> <ins>The user
must take care to ensure that no threads wait on <tt>*this</tt> once the
destructor has been started, especially when the waiting threads are calling the
wait functions in a loop or using the overloads of <tt>wait</tt>,
<tt>wait_for</tt> or <tt>wait_until</tt> that take a predicate.</ins> �
<i>end note</i>]
</blockquote>
</blockquote>





<hr>
<h3><a name="1222"></a>1222. condition_variable incorrect effects for exception safety</h3>
<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-09-30 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.5.1 [thread.condition.condvar] says:
</p>

<blockquote>
<pre>void wait(unique_lock&lt;mutex&gt;&amp; lock);
</pre>
<blockquote>
<p>...</p>
<p>
<i>Effects:</i>
</p>
<ul>
<li>...</li>
<li>
If the function exits via an exception, <tt>lock.unlock()</tt> shall be
called prior to exiting the function scope.
</li>
</ul>
</blockquote>
</blockquote>

<p>
Should that be <tt>lock.lock()</tt>?
</p>

<p><i>[
2009-11-17 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>

<p>
Change 30.5.1 [thread.condition.condvar] p10:
</p>

<blockquote>
<pre>void wait(unique_lock&lt;mutex&gt;&amp; lock);
</pre>
<blockquote>
<p>...</p>
<p>
<i>Effects:</i>
</p>
<ul>
<li>...</li>
<li>
If the function exits via an exception, <tt>lock.<del>un</del>lock()</tt> shall be
called prior to exiting the function scope.
</li>
</ul>
</blockquote>
</blockquote>

<p>
And make a similar change in p16, and in 30.5.2 [thread.condition.condvarany],
p8 and p13.
</p>






<hr>
<h3><a name="1227"></a>1227. <tt>&lt;bitset&gt;</tt> synopsis overspecified</h3>
<p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2009-10-05 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The resolutions to some library defect reports, like <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>
requires that <tt>#includes</tt> in each synopsis should be taken
literally. This means that the <tt>&lt;bitset&gt;</tt> header now
<em>must</em> include <tt>&lt;stdexcept&gt;</tt>, even though none of the
exceptions are mentioned in the <tt>&lt;bitset&gt;</tt> header.
</p>
<p>
Many other classes are required to throw exceptions like
<tt>invalid_argument</tt> and <tt>out_of_range</tt>, without explicitly
including <tt>&lt;stdexcept&gt;</tt> in their synopsis. It is totally
possible for implementations to throw the needed exceptions from utility
functions, whose implementations are not visible in the headers.
</p>
<p>
I propose that <tt>&lt;stdexcept&gt;</tt> is removed from the
<tt>&lt;bitset&gt;</tt> header.
</p>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.5 [template.bitset]:
</p>

<blockquote><pre>#include &lt;cstddef&gt;        // for size_t
#include &lt;string&gt;
<del>#include &lt;stdexcept&gt;      // for invalid_argument,</del>
                          <del>// out_of_range, overflow_error</del>
#include &lt;iosfwd&gt;         // for istream, ostream
namespace std {
...
</pre></blockquote>





<hr>
<h3><a name="1231"></a>1231. <tt>weak_ptr</tt> comparisons incompletely resolved</h3>
<p><b>Section:</b> 20.9.10.3.5 [util.smartptr.weak.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-10-10 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a>
paper suggested several updates of the ordering semantics of
<tt>shared_ptr</tt>
and <tt>weak_ptr</tt>, among those the explicit comparison operators of <tt>weak_ptr</tt> were
removed/deleted, instead a corresponding functor <tt>owner_less</tt> was added.
The problem
is that
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a>
did not clearly enough specify, how the previous wording
parts describing
the comparison semantics of <tt>weak_ptr</tt> should be removed.
</p>

<p><i>[
2009-11-06 Howard adds:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>



<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Change 20.9.10.3 [util.smartptr.weak]/2 as described, the intention is to fix
the now no longer valid
requirement that <tt>weak_ptr</tt> is <tt>LessComparable</tt> [Note the deleted comma]:
</p>

<blockquote>
Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt><del>,</del>
<ins>and</ins> <tt>CopyAssignable</tt>,
<del>and <tt>LessThanComparable</tt>,</del> allowing their use in standard containers.
</blockquote>
</li>

<li>
<p>
In 20.9.10.3.5 [util.smartptr.weak.obs] remove the paragraphs 9-11 including prototype:
</p>

<blockquote>
<del>template&lt;class T, class U&gt; bool operator&lt;(const weak_ptr&lt;T&gt;&amp; a, const weak_ptr&lt;U&gt;&amp; b);</del>

<p>
<del><i>Returns:</i> an unspecified value such that</del>
</p>
<ul>
<li>
<del><tt>operator&lt;</tt> is a strict weak ordering as described in 25.4;</del>
</li>
<li>
<del>under the equivalence relation defined by <tt>operator&lt;</tt>, <tt>!(a
&lt; b) &amp;&amp; !(b &lt; a)</tt>, two <tt>weak_ptr</tt> instances are
equivalent if and only if they share ownership or are both empty.</del>
</li>
</ul>

<p>
<del><i>Throws:</i> nothing.</del>
</p>

<p>
<del>[<i>Note:</i> Allows <tt>weak_ptr</tt> objects to be used as keys in associative
containers. � <i>end note</i>]</del>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="1234"></a>1234. "Do the right thing" and NULL</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2009-10-09 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
On g++ 4.2.4 (x86_64-linux-gnu), the following file gives a compile
error:
</p>

<blockquote><pre>#include &lt;vector&gt;
void foo() { std::vector&lt;int*&gt; v(500l, NULL); }
</pre></blockquote>

<p>
Is this supposed to work? 
</p>

<p>
The issue: if <tt>NULL</tt> happens to be defined as <tt>0l</tt>, this is an invocation of
the constructor with two arguments of the same integral type.
23.2.3 [sequence.reqmts]/14
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf">N3035</a>)
says that this will behave as if the the
overloaded constructor
</p>

<blockquote><pre>X(size_type, const value_type&amp; = value_type(),
  const allocator_type&amp; = allocator_type())
</pre></blockquote>

<p>
were called instead, with the arguments
<tt>static_cast&lt;size_type&gt;(first)</tt>, <tt>last</tt> and
<tt>alloc</tt>, respectively. However, it does not say whether this
actually means invoking that constructor with the exact textual form of
the arguments as supplied by the user, or whether the standard permits
an implementation to invoke that constructor with variables of the same
type and value as what the user passed in. In most cases this is a
distinction without a difference. In this particular case it does make a
difference, since one of those things is a null pointer constant and the
other is not.
</p>

<p>
Note that an implementation based on forwarding functions will use the
latter interpretation.
</p>

<p><i>[
2010 Pittsburgh:  Moved to Open.
]</i></p>


<p><i>[
2010-03-19 Daniel provides wording.
]</i></p>


<blockquote>
<ul>
<li>
Adapts the numbering used in the discussion to the recent working paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf">N3035</a>.
</li>

<li>
Proposes a resolution that requires implementations to use sfinae-like means to
possibly filter away the too generic template c'tor. In fact this resolution is
equivalent to that used for the <tt>pair-NULL</tt> problem (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>),
the only difference is, that issue 1234 was already a C++03 problem.
</li>
</ul>

<p>
This issue can be considered as a refinement of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>.
</p>

</blockquote>

<p><i>[
Post-Rapperswil
]</i></p>


<p>
Wording was verified to match with the most recent WP. Jonathan Wakely and Alberto Barbati observed that the current 
WP has a defect that should be fixed here as well: The functions signatures <tt>fx1</tt> and <tt>fx3</tt> are 
incorrectly referring to <tt>iterator</tt> instead of <tt>const_iterator</tt>.
</p>

<blockquote>
Moved to Tentatively Ready with revised wording after 7 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

 
<p>
Change 23.2.3 [sequence.reqmts]/14+15 as indicated:
</p>

<blockquote>
<p>
14 For every sequence container defined in this Clause and in Clause 21:
</p>

<ul>
<li>
<p>
If the constructor
</p>

<blockquote><pre>template &lt;class InputIterator&gt;
X(InputIterator first, InputIterator last,
  const allocator_type&amp; alloc = allocator_type())

</pre></blockquote>

<p>
is called with a type <tt>InputIterator</tt> that does not qualify as an input
iterator, then the constructor <ins>shall not participate in overload
resolution.</ins><del>will
behave as if the overloaded constructor:</del>
</p>

<blockquote><pre><del>
X(size_type, const value_type&amp; = value_type(),
  const allocator_type&amp; = allocator_type())
</del></pre></blockquote>

<p>
<del>were called instead, with the arguments
<tt>static_cast&lt;size_type&gt;(first)</tt>, <tt>last</tt> and <tt>alloc</tt>,
respectively</del>.
</p>
</li>

<li>

<p>
If the member functions of the forms:
</p>

<blockquote><pre>template &lt;class InputIterator&gt; <i>// such as insert()</i>
rt fx1(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);

template &lt;class InputIterator&gt; <i>// such as append(), assign()</i>
rt fx2(InputIterator first, InputIterator last);

template &lt;class InputIterator&gt; <i>// such as replace()</i>
rt fx3(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, InputIterator first, InputIterator last);
</pre></blockquote>

<p>
are called with a type <tt>InputIterator</tt> that does not qualify as an input
iterator, then these functions <ins>shall not participate in overload
resolution.</ins><del>will behave as if the overloaded member functions:</del>
</p>

<blockquote><pre><del>rt fx1(iterator, size_type, const value_type&amp;);</del>

<del>rt fx2(size_type, const value_type&amp;);</del>

<del>rt fx3(iterator, iterator, size_type, const value_type&amp;);</del>
</pre></blockquote>

<p>
<del>were called instead, with the same arguments.</del>
</p>
</li>

</ul>

<p><del>
15 In the previous paragraph the alternative binding will fail if <tt>first</tt>
is not implicitly convertible to <tt>X::size_type</tt> or if <tt>last</tt> is
not implicitly convertible to <tt>X::value_type</tt>.
</del></p>
</blockquote>






<hr>
<h3><a name="1237"></a>1237. Constrained error_code/error_condition members</h3>
<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-10-14 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm just reflecting on the now SFINAE-constrained constructors
and assignment operators of <tt>error_code</tt> and <tt>error_condition</tt>:
</p>
<p>
These are the <em>only</em> library components that are pro-actively
announcing that they are using <tt>std::enable_if</tt> as constraining tool,
which has IMO several disadvantages:
</p>

<ol>
<li>
<p>
With the availability of template default arguments and
decltype, using <tt>enable_if</tt> in C++0x standard library, seems
unnecessary restricting implementation freedom. E.g. there
should be not need for a useless specification of a dummy
default function argument, which only confuses the reader.
A more reasonable implementation could e.g. be
</p>

<blockquote><pre>template &lt;class ErrorCodeEnum
 class = typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type&gt;
error_code(ErrorCodeEnum e);
</pre></blockquote>

<p>
As currently specified, the function signatures are so unreadable,
that errors quite easily happen, see e.g. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a>.
</p>
</li>

<li>
<p>
We have a <em>lot</em> of constrained functions in other places, that
now have a standard phrase that is easily understandable:
</p>

<blockquote>
<i>Remarks:</i> This constructor/function shall participate in overload
resolution if and only if X.
</blockquote>

<p>
where X describes the condition. Why should these components deviate?
</p>
</li>

<li>
<p>
If <tt>enable_if</tt> would <em>not</em> be explicitly specified, the standard library
is much better prepared for the future. It would also be possible, that
libraries with partial support for not-yet-standard-concepts could provide
a much better diagnostic as is possible with <tt>enable_if</tt>. This again
would allow for experimental concept implementations in the wild,
which as a result would make concept standardization a much more
natural thing, similar to the way as templates were standardized
in C++.
</p>

<p>
In summary: I consider it as a library defect that <tt>error_code</tt> and
<tt>error_condition</tt> explicitly require a dependency to <tt>enable_if</tt> and
do limit implementation freedom and I volunteer to prepare a
corresponding resolution.
</p>
</li>
</ol>

<p><i>[
2009-10-18 Beman adds:
]</i></p>


<blockquote>
I support this proposed resolution, and thank Daniel for writing it up.
</blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote>
Moved to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p><i>[
Should this resolution be accepted, I recommend to resolve <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a> as NAD
]</i></p>


<ol>
<li>
<p>
In 19.5.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt>,
change as indicated:
</p>

<blockquote><pre>// 19.5.2.2 constructors:
error_code();
error_code(int val, const error_category&amp; cat);
template &lt;class ErrorCodeEnum&gt;
  error_code(ErrorCodeEnum e<del>,
    typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type * = 0</del>);

// 19.5.2.3 modifiers:
void assign(int val, const error_category&amp; cat);
template &lt;class ErrorCodeEnum&gt;
  <del>typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type</del><ins>error_code</ins>&amp;
    operator=(ErrorCodeEnum e);
void clear();
</pre></blockquote>
</li>

<li>
<p>
Change 19.5.2.2 [syserr.errcode.constructors] around the prototype before p. 7:
</p>

<blockquote><pre>template &lt;class ErrorCodeEnum&gt;
error_code(ErrorCodeEnum e<del>,
  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type * = 0</del>);
</pre>
<blockquote>
<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution, unless
<tt>is_error_code_enum&lt;ErrorCodeEnum&gt;::value == true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 19.5.2.3 [syserr.errcode.modifiers] around the prototype before p. 3:
</p>

<blockquote><pre>template &lt;class ErrorCodeEnum&gt;
  <del>typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type</del><ins>error_code</ins>&amp;
    operator=(ErrorCodeEnum e);
</pre>

<blockquote>
<ins><i>Remarks:</i> This operator shall not participate in overload resolution, unless
<tt>is_error_code_enum&lt;ErrorCodeEnum&gt;::value == true</tt>.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
In 19.5.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt>, change
as indicated:
</p>

<blockquote><pre>// 19.5.3.2 constructors:
error_condition();
error_condition(int val, const error_category&amp; cat);
template &lt;class ErrorConditionEnum&gt;
  error_condition(ErrorConditionEnum e<del>,
    typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::type* = 0</del>);

// 19.5.3.3 modifiers:
void assign(int val, const error_category&amp; cat);
template&lt;<del>typename</del><ins>class</ins> ErrorConditionEnum&gt;
  <del>typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;, error_code&gt;::type</del><ins>error_condition</ins> &amp;
    operator=( ErrorConditionEnum e );
void clear();
</pre></blockquote>
</li>

<li>
<p>
Change 19.5.3.2 [syserr.errcondition.constructors] around the
prototype before p. 7:
</p>

<blockquote><pre>template &lt;class ErrorConditionEnum&gt;
  error_condition(ErrorConditionEnum e<del>,
    typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value&gt;::type* = 0</del>);
</pre>
<blockquote>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution, unless
<tt>is_error_condition_enum&lt;ErrorConditionEnum&gt;::value == true</tt>.</ins>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 19.5.3.3 [syserr.errcondition.modifiers] around the
prototype before p. 3:
</p>

<blockquote><pre>template &lt;class ErrorConditionEnum&gt;
  <del>typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value&gt;::type</del><ins>error_condition</ins>&amp;
    operator=(ErrorConditionEnum e);
</pre>

<blockquote>
<p>
<ins><i>Remarks:</i> This operator shall not participate in overload resolution, unless
<tt>is_error_condition_enum&lt;ErrorConditionEnum&gt;::value == true</tt>.</ins>
</p>

<p>
<i>Postcondition:</i> <tt>*this == make_error_condition(e)</tt>.
</p>

<p>
<ins><i>Returns:</i> <tt>*this</tt></ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="1240"></a>1240. Deleted comparison functions of std::function not  needed</h3>
<p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-10-18 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The class template <tt>std::function</tt> contains the following member
declarations:
</p>

<blockquote><pre>// deleted overloads close possible hole in the type system
template&lt;class R2, class... ArgTypes2&gt;
  bool operator==(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;
template&lt;class R2, class... ArgTypes2&gt;
  bool operator!=(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;
</pre></blockquote>

<p>
The leading comment here is part of the history of <tt>std::function</tt>, which
was introduced with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1402.html#undefined_operators">N1402</a>.
During that time no explicit conversion functions existed, and the
"safe-bool" idiom (based on pointers-to-member) was a popular
technique. The only disadvantage of this idiom was that given two
objects <tt>f1</tt> and <tt>f2</tt> of type <tt>std::function</tt> the expression
</p>

<blockquote><pre>f1 == f2;
</pre></blockquote>

<p>
was well-formed, just because the built-in <tt>operator==</tt> for pointer to member
was considered after a single user-defined conversion. To fix this, an
overload set of <em>undefined</em> comparison functions was added,
such that overload resolution would prefer those ending up in a linkage error.
The new language facility of deleted functions provided a much better
diagnostic mechanism to fix this issue.
</p>

<p>
The central point of this issue is, that with the replacement of the
safe-bool idiom by explicit conversion to bool the original "hole in the
type system" does no longer exist and therefore the comment is wrong and
the superfluous function definitions should be removed as well. An
explicit conversion function is considered in direct-initialization
situations only, which indirectly contain the so-called "contextual
conversion to bool" (4 [conv]/3). These conversions are not considered for
<tt>==</tt> or <tt>!=</tt> as defined by the core language.
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
In 20.8.14.2 [func.wrap.func]/1, class function change as indicated:
</p>

<blockquote><pre>// 20.7.15.2.3, function capacity:
explicit operator bool() const;

<del>// deleted overloads close possible hole in the type system</del>
<del>template&lt;class R2, class... ArgTypes2&gt;</del>
  <del>bool operator==(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;</del>
<del>template&lt;class R2, class... ArgTypes2&gt;</del>
  <del>bool operator!=(const function&lt;R2(ArgTypes2...)&gt;&amp;) = delete;</del>
</pre></blockquote>





<hr>
<h3><a name="1241"></a>1241. unique_copy needs to require EquivalenceRelation</h3>
<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-10-17 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A lot of fixes were silently applied during concept-time and we should
not lose them again. The Requires clause of 25.3.9 [alg.unique]/5
doesn't mention that <tt>==</tt> and the predicate need to satisfy an
<tt>EquivalenceRelation</tt>, as it is correctly said for
<tt>unique</tt>. This was intentionally fixed during conceptification,
were we had:
</p>

<blockquote><pre>template&lt;InputIterator InIter, class OutIter&gt;
  requires OutputIterator&lt;OutIter, RvalueOf&lt;InIter::value_type&gt;::type&gt;
        &amp;&amp; EqualityComparable&lt;InIter::value_type&gt;
        &amp;&amp; HasAssign&lt;InIter::value_type, InIter::reference&gt;
        &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
  OutIter unique_copy(InIter first, InIter last, OutIter result);

template&lt;InputIterator InIter, class OutIter,
         EquivalenceRelation&lt;auto, InIter::value_type&gt; Pred&gt;
  requires OutputIterator&lt;OutIter, RvalueOf&lt;InIter::value_type&gt;::type&gt;
        &amp;&amp; HasAssign&lt;InIter::value_type, InIter::reference&gt;
        &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
        &amp;&amp; CopyConstructible&lt;Pred&gt;
  OutIter unique_copy(InIter first, InIter last, OutIter result, Pred pred);
</pre></blockquote>

<p>
Note that EqualityComparable implied an equivalence relation.
</p>

<p><i>[
N.B. <tt>adjacent_find</tt> was also specified to require
<tt>EquivalenceRelation</tt>, but that was considered as a defect in
concepts, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>
]</i></p>


<p><i>[
2009-10-31 Howard adds:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 25.3.9 [alg.unique]/5 as indicated:
</p>

<blockquote><pre>template&lt;class InputIterator, class OutputIterator&gt;
  OutputIterator
    unique_copy(InputIterator first, InputIterator last, OutputIterator result);

template&lt;class InputIterator, class OutputIterator, class BinaryPredicate&gt;
  OutputIterator
    unique_copy(InputIterator first, InputIterator last,
                OutputIterator result, BinaryPredicate pred);
</pre>
<blockquote>
<i>Requires:</i> <ins>The comparison function shall be an equivalence
relation.</ins> The ranges <tt>[first,last)</tt> and
<tt>[result,result+(last-first))</tt> shall not overlap. The expression
<tt>*result = *first</tt> shall be valid. If neither
<tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
requirements of forward iterator then the value type of
<tt>InputIterator</tt> shall be <tt>CopyConstructible</tt> (34) and
<tt>CopyAssignable</tt> (table 36). Otherwise <tt>CopyConstructible</tt>
is not required.
</blockquote>
</blockquote>





<hr>
<h3><a name="1245"></a>1245. <tt>std::hash&lt;string&gt;</tt> &amp; co</h3>
<p><b>Section:</b> 20.8.15 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2009-10-22 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 20.8.15 [unord.hash], <tt>operator()</tt> is specified as
taking the argument by value. Moreover, it is said that <tt>operator()</tt> shall
not throw exceptions.
</p>

<p>
However, for the specializations for class types, like <tt>string</tt>, <tt>wstring</tt>,
etc, the former requirement seems suboptimal from the performance point
of view (a specific PR has been filed about this in the GCC Bugzilla)
and, together with the latter requirement, hard if not impossible to
fulfill. It looks like pass by const reference should be allowed in such
cases.
</p>

<p><i>[
2009-11-18: Ganesh updates wording.
]</i></p>


<blockquote>
I've removed the list of types for which <tt>hash</tt> shall be instantiated
because it's already explicit in the synopsis of header
<tt>&lt;functional&gt;</tt> in 20.8 [function.objects]/2.
</blockquote>

<p><i>[
2009-11-18: Original wording here:
]</i></p>


<blockquote class="note">
<p>
Add to 20.8.15 [unord.hash]/2:
</p>

<blockquote>
<pre>namespace std {
  template &lt;class T&gt;
  struct hash : public std::unary_function&lt;T, std::size_t&gt; {
    std::size_t operator()(T val) const;
  };
}
</pre>

<p>
The return value of <tt>operator()</tt> is unspecified, except that
equal arguments shall yield the same result. <tt>operator()</tt> shall
not throw exceptions. <ins>It is also unspecified whether
<tt>operator()</tt> of <tt>std::hash</tt> specializations for class
types takes its argument by value or const reference.</ins>
</p>
</blockquote>
</blockquote>

<p><i>[
2009-11-19 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2009-11-24 Ville Opens:
]</i></p>


<blockquote>
I have received community requests to ask for this issue to be reopened.
Some users feel that mandating the inheritance is overly constraining.
</blockquote>

<p><i>[
2010-01-31 Alisdair: related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#978">978</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1182">1182</a>.
]</i></p>


<p><i>[
2010-02-07 Proposed resolution updated by Beman, Daniel and Ganesh.
]</i></p>


<p><i>[
2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
  <p><i>Insert a new subclause either before or after the current 20.2.5 [allocator.requirements]:</i></p>
<blockquote>

  <h3><tt>Hash</tt> Requirements [hash.requirements]</h3>

  <p align="left">This subclause defines the named requirement <tt>Hash</tt>, 
  used in several clauses of the C++ standard library. A type <tt>H</tt> meets the <tt>Hash</tt> requirement if</p>

  <ul>
    <li>

  <p align="left">it is a function object type (20.8 [function.objects]).</p>

    </li>
    <li>

  <p align="left">it satisfies the requirements of <tt>CopyConstructible</tt>, and 
  <tt>Destructible</tt> (20.2.1 [utility.arg.requirements]),</p>

    </li>
    <li>

  <p align="left">the expressions shown in the following table are valid and have the 
  indicated semantics, and</p>

    </li>
    <li>

  <p align="left">it satisfies all other requirements of this subclause.</p>

    </li>
  </ul>

  <p align="left">Given <tt>Key</tt> is an argument type for function objects of 
  type <tt>H</tt>, in the table below <tt>h</tt> is a value of type (possibly <tt>const</tt>)
  <tt>H</tt>, <tt>u</tt> is an lvalue of type <tt>Key</tt>,&nbsp; and <tt>
  k</tt> 
  is a value of a type convertible to (possibly <tt>const</tt>) <tt>Key</tt>:</p>

  <p align="center">Table ? - <tt>Hash</tt> requirements</p>
<table border="1" cellpadding="5" cellspacing="1" style="border-collapse: collapse" bordercolor="#111111">
  <tbody><tr>
    <td>Expression</td>
    <td>Return type</td>
    <td>Requirement</td>
  </tr>
  <tr>
    <td valign="top"><tt>h(k)</tt></td>
    <td valign="top"><tt>size_t</tt></td>
    <td valign="top">Shall not throw exceptions. The value returned shall depend only on
the argument <tt>k</tt>. [<i>Note:</i> Thus all evaluations of the expression <tt>
    h(k)</tt> with the 
    same value for <tt>k</tt> yield the same result. <i>� end note</i>] [<i>Note:
    </i>For <tt>t1</tt> and <tt>t2</tt> of different values, the probability that 
    <tt>h(t1)</tt> 
    and <tt>h(t2)</tt> compare equal should be very small, approaching <tt>(1.0/numeric_limits&lt;size_t&gt;::max())</tt>.
    <i>� end note</i>] <i><span style="background-color: #C0C0C0">Comment 
    (not to go in WP): The wording for the second note is based on a similar 
    note in 22.4.4.1.2 [locale.collate.virtuals]/3</span></i></td>
  </tr>
  <tr>
    <td valign="top"><tt>h(u)</tt></td>
    <td valign="top"><tt>size_t</tt></td>
    <td valign="top">Shall not modify <tt>u</tt>.</td>
  </tr>
  </tbody></table>

</blockquote>

<p><i>Change 20.8.15 [unord.hash] as indicated: </i>
</p>
<blockquote>
  <p>1 The unordered associative containers defined in Clause 23.7 [unord] use 
  specializations of <ins>the class template</ins> <tt>hash</tt> as the default 
  hash function. <ins>For all object types <tt>T</tt> for which there exists a 
  specialization <tt>hash&lt;T&gt;</tt>, the instantiation <tt>hash&lt;T&gt;</tt> shall:</ins></p>
  <ul>
    <li> <ins>satisfy the <tt>Hash</tt> requirements([hash.requirements]), with <tt>T</tt> as the 
  function call argument type, the <tt>
  DefaultConstructible</tt> requirements ([defaultconstructible]), the <tt>CopyAssignable</tt> 
  requirements ([copyassignable]), and the <tt>
  Swappable</tt> requirements ([swappable]),</ins>
  </li>
    <li> <ins>provide two nested types <tt>result_type</tt> and <tt>argument_type</tt> which shall 
    be synonyms for <tt>size_t</tt> and <tt>T</tt>, respectively,</ins></li>
    <li> <ins>satisfy the 
  requirement that if <tt>k1 == k2</tt> is <tt>true</tt>, <tt>h(k1) == h(k2)</tt> 
  is <tt>true</tt>, where <tt>h</tt> is an object of type <tt>hash&lt;T&gt;</tt>, and
  <tt>k1</tt>, <tt>k2</tt> are objects of type <tt>T</tt>.</ins></li>
  </ul>
  <p> <del>This class template is only required to be instantiable 
  for integer types (3.9.1 [basic.fundamental]), floating-point types (3.9.1 [basic.fundamental]), 
  pointer types (8.3.1 [dcl.ptr]), and <tt>std::string</tt>, <tt>std::u16string</tt>,
  <tt>std::u32string</tt>, <tt>std::wstring</tt>, <tt>std::error_code</tt>, <tt>
  std::thread::id</tt>, <tt>std::bitset</tt>, and <tt>std::vector&lt;bool&gt;</tt>.</del> </p>
  <blockquote>
    <pre><del>namespace std {
  template &lt;class T&gt;
  struct hash : public std::unary_function&lt;T, std::size_t&gt; {
    std::size_t operator()(T val) const;
  };
}</del></pre>
  </blockquote>
  <p><del>2 The return value of <tt>operator()</tt> is unspecified, except that 
  equal arguments shall yield the same result. <tt>operator()</tt> shall not 
  throw exceptions. </del></p>

</blockquote>

  <p><i>Change Unordered associative containers 23.2.5 [unord.req] as indicated:</i></p>
<blockquote>
  <p>Each unordered associative container is parameterized by <tt>Key</tt>, by a 
  function object <ins>type</ins> <tt>Hash</tt><ins>([hash.requirements])</ins> that acts as a hash 
  function for <ins>argument</ins> values of type <tt>Key</tt>, 
  and by a binary predicate <tt>Pred</tt> that induces an equivalence relation 
  on values of type <tt>Key</tt>. Additionally, <tt>unordered_map</tt> and <tt>
  unordered_multimap</tt> associate an arbitrary mapped type <tt>T</tt> with the
  <tt>Key</tt>.</p>
  <p>A hash function is a function object that takes a single argument of type
  <tt>Key</tt> and returns a value of type <tt>std::size_t</tt>.</p>
<p>Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered 
equal if the container's equality function object returns <tt>true</tt> when passed those 
values. If <tt>k1</tt> and <tt>k2</tt> are equal, the hash function shall return 
the same value for both. <ins>[<i>Note:</i> Thus supplying a non-default <tt>Pred</tt> 
parameter usually implies the need to supply a non-default <tt>Hash</tt> 
parameter. <i>� end note</i>]</ins></p>

</blockquote>






<hr>
<h3><a name="1247"></a>1247. <tt>auto_ptr</tt> is overspecified</h3>
<p><b>Section:</b> D.12.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-24 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This issue is extracted as the ongoing point-of-interest from earlier
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>.
</p>

<p>
<tt>auto_ptr</tt> is overspecified as the <tt>auto_ptr_ref</tt>
implementation detail is formally specified, and the technique is
observable so workarounds for compiler defects can  cause a working
implementation of the primary <tt>auto_ptr</tt> template become
non-conforming.
</p>

<p>
<tt>auto_ptr_ref</tt> is a documentation aid to describe a possible
mechanism to implement the class.  It should be marked exposition only,
as per similar classes, e.g., <tt>istreambuf_iterator::proxy</tt>
</p>

<p><i>[
2009-10-25 Daniel adds:
]</i></p>


<blockquote>
<p>
I wonder, whether the revised wording shouldn't be as straight as
for <tt>istream_buf</tt> by adding one further sentence:
</p>

<blockquote>
An implementation is permitted to provide equivalent functionality without
providing a class with this name.
</blockquote>
</blockquote>

<p><i>[
2009-11-06 Alisdair adds Daniel's suggestion to the proposed wording.
]</i></p>


<p><i>[
2009-11-06 Howard moves issue to Review.
]</i></p>


<p><i>[
2009-11-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Add the term "exposition only" in the following two places:
</p>

<p>
Ammend D.12.1 [auto.ptr]p2:
</p>

<blockquote>
<p>
<ins>The exposition only class </ins> <del>T</del><ins>t</ins>emplate <tt>auto_ptr_ref</tt>
holds a reference to an <tt>auto_ptr</tt>. It is used by the
<tt>auto_ptr</tt> conversions to allow <tt>auto_ptr</tt> objects to be
passed to and returned from functions.
<ins>An implementation is permitted to provide equivalent functionality
without providing a class with this name.</ins>
</p>

<blockquote><pre>namespace std {
 template &lt;class Y&gt; struct auto_ptr_ref { }; <ins>// exposition only</ins>
</pre></blockquote>
</blockquote>





<hr>
<h3><a name="1249"></a>1249. basic_ios default ctor</h3>
<p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2009-10-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The basic_ios default ctor is required to leave the objects members
uninitialized (see below). The paragraph says the object must be
initialized by calling basic_ios::init() before it's destroyed by
I can't find a requirement that it be initialized before calling
any of the class other member functions. Am I not looking in the
right place or that an issue?
</p>

<p><i>[
2009-10-25 Daniel adds:
]</i></p>


<blockquote>
<p>
I agree, that your wording makes that clearer, but suggest to write
</p>

<blockquote>
... calling <tt>basic_ios::init<del>()</del></tt> before ...
</blockquote>

<p>
Doing so, I recommend to adapt that of <tt>ios_base();</tt> as well, where
we have:
</p>

<blockquote>
<i>Effects:</i> Each <tt>ios_base</tt> member has an indeterminate value
after construction. These members shall be initialized by calling
<tt>basic_ios::init</tt>. If an <tt>ios_base</tt> object is destroyed
before these initializations have taken place, the behavior is
undefined.
</blockquote>
</blockquote>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 27.5.2.7 [ios.base.cons] p1:
</p>

<blockquote><pre>ios_base();
</pre>
<blockquote>
<i>Effects:</i> Each <tt>ios_base</tt> member has an indeterminate value
after construction. <del>These</del> <ins>The object's</ins> members shall be initialized by calling
<tt>basic_ios::init</tt> <ins>before the object's first use or before
 it is destroyed, whichever comes first; otherwise the behavior
 is undefined.</ins>. <del>If an <tt>ios_base</tt> object is destroyed
before these initializations have taken place, the behavior is
undefined.</del>
</blockquote>
</blockquote>

<p>
Change 27.5.4.1 [basic.ios.cons] p2:
</p>

<blockquote><pre>basic_ios();
</pre>
<blockquote>
<i>Effects:</i> Constructs an object of class <tt>basic_ios</tt>
(27.5.2.7) leaving its member objects uninitialized. The object shall be
initialized by calling <del>its</del>
<tt><ins>basic_ios::</ins>init</tt> <ins>before its first
use or before it is destroyed, whichever comes first; otherwise the
behavior is undefined.</ins> <del>member function. If it is destroyed
before it has been initialized the behavior is undefined.</del>
</blockquote>
</blockquote>





<hr>
<h3><a name="1250"></a>1250. <tt>&lt;bitset&gt;</tt> still overspecified</h3>
<p><b>Section:</b> 20.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2009-10-29 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1227">1227</a> � <tt>&lt;bitset&gt;</tt> synopsis overspecified makes the observation
that <tt>std::bitset</tt>, and in fact the whole library, may be implemented
without needing to <tt>#include &lt;stdexcept&gt;</tt> in any library header. The
proposed resolution removes the <tt>#include &lt;stdexcept&gt;</tt> directive from
the header.
</p>

<p>
I'd like to add that the <tt>&lt;bitset&gt;</tt> header (as well as the rest of
the library) has also been implemented without #including the
<tt>&lt;cstddef&gt;</tt> header in any library header. In the case of <tt>std::bitset</tt>,
the template is fully usable (i.e., it may be instantiated and all
its member functions may be used) without ever mentioning <tt>size_t</tt>.
In addition, just like no library header except for <tt>&lt;bitset&gt;</tt>
<tt>#includes &lt;stdexcept&gt;</tt> in its synopsis, no header but <tt>&lt;bitset&gt;</tt>
<tt>#includes &lt;cstddef&gt;</tt> either.
</p>

<p>
Thus I suggest that the <tt>#include &lt;cstddef&gt;</tt> directive be similarly
removed from the synopsis of <tt>&lt;bitset&gt;</tt>.
</p>

<p><i>[
2010-02-08 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.5 [template.bitset]:
</p>

<blockquote><pre><del>#include &lt;cstddef&gt;        // for size_t</del>
#include &lt;string&gt;
#include &lt;iosfwd&gt;         // for istream, ostream
namespace std {
...
</pre></blockquote>





<hr>
<h3><a name="1254"></a>1254. Misleading sentence in <tt>vector&lt;bool&gt;::flip</tt></h3>
<p><b>Section:</b> 23.4.2 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2009-11-01 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The effects of <tt>vector&lt;bool&gt;::flip</tt> has the line:
</p>

<blockquote>
It is unspecified whether the function has any effect on allocated but
unused bits.
</blockquote>

<p>
While this is technically true, it is misleading, as any member function
in any standard container may change unused but allocated memory. Users
can never observe such changes as it would also be undefined behaviour
to read such memory.
</p>

<p><i>[
2009-11-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Strike second sentence from the definition of <tt>vector&lt;bool&gt;::flip()</tt>,
23.4.2 [vector.bool], paragraph 5.
</p>

<blockquote>
<i>Effects:</i> Replaces each element in the container with its complement.
<del>It is unspecified whether the function has any effect on allocated
but unused bits.</del>
</blockquote>





<hr>
<h3><a name="1255"></a>1255. <tt>declval</tt> should be added to the library</h3>
<p><b>Section:</b> 20.3 [utility] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-11-03 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility">issues</a> in [utility].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
During the Santa Cruz meeting it was decided to split off the provision
of the library utility <tt>value()</tt> proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2979.html">N2979</a>
from the concrete request of the
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2939.html#uk300">UK 300</a>
comment.
The provision of a new library component that allows the production of
values in unevaluated expressions is considered as important
to realize constrained templates in C++0x where concepts are not
available.
</p>

<p>
The following proposed resolution is an improvement over that suggested in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2958.html">N2958</a>,
because the proposed component can now be defined without loss of
general usefulness and any <i>use</i> by user-code will make the program ill-formed.
A possible prototype implementation that satisfies the core language
requirements
can be written as:
</p>

<blockquote><pre>template&lt;class T&gt;
  struct declval_protector {
    static const bool stop = false;
    static typename std::add_rvalue_reference&lt;T&gt;::type delegate(); <font color="#C80000">// undefined</font>
  };

template&lt;class T&gt;
typename std::add_rvalue_reference&lt;T&gt;::type declval() {
  static_assert(declval_protector&lt;T&gt;::stop, "declval() must not be used!");
  return declval_protector&lt;T&gt;::delegate();
}
</pre></blockquote>

<p>
Further-on the earlier suggested name <tt>value()</tt> has been changed to <tt>declval()</tt>
after discussions with committee members.
</p>

<p>
Finally the suggestion shown below demonstrates that it can simplify
existing standard wording by directly using it in the library
specification, and that it also improves an overlooked corner case for
<tt>common_type</tt> by adding support for <tt>cv void</tt>.
</p>

<p><i>[
2009-11-19 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p><i>[
The proposed resolution has been updated to
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
numbering and wording
]</i></p>


<ol>
<li>
<p>
Change 20.3 [utility], header <tt>&lt;utility&gt;</tt> synopsis
as indicated:
</p>

<blockquote><pre>// 20.3.3, forward/move:
template &lt;class T&gt; struct identity;
template &lt;class T, class U&gt; T&amp;&amp; forward(U&amp;&amp;);
template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp;);

<ins>// 20.3.4, declval:</ins>
<ins>template &lt;class T&gt; typename add_rvalue_reference&lt;T&gt;::type declval(); // as unevaluated operand</ins>
</pre></blockquote>
</li>

<li>
<p>
Immediately after the current section 20.3.3 [forward] insert a
new section:
</p>
<p>
<ins>20.3.4 Function template declval [declval]</ins>
</p>
<p>
<ins>The library provides the function template <tt>declval</tt> to simplify
the definition of expressions which occur as
unevaluated operands (5 [expr]). The
template parameter <tt>T</tt> of <tt>declval</tt> may
be an incomplete type.</ins>
</p>

<pre><ins>template &lt;class T&gt; typename add_rvalue_reference&lt;T&gt;::type declval(); // as unevaluated operand</ins>
</pre>

<blockquote>
<p>
<ins><i>Remarks:</i> If this function is used according to 3.2 [basic.def.odr],
the program is ill-formed.</ins>
</p>

<p>
<ins>[<i>Example:</i></ins>
</p>

<blockquote><pre><ins>
template&lt;class To, class From&gt;
decltype(static_cast&lt;To&gt;(declval&lt;From&gt;())) convert(From&amp;&amp;);
</ins></pre></blockquote>

<p>
<ins>
declares a function template <tt>convert</tt>, which only participates in
overloading if the type <tt>From</tt> can be explicitly cast to type <tt>To</tt>.
For another example see class template <tt>common_type</tt>
(20.7.7.6 [meta.trans.other]).
� <i>end example</i>]</ins>
</p>
</blockquote>

</li>

<li>
<p>
This bullet just makes clear that after applying <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>, the changes in 20.7.4.3 [meta.unary.prop], before
table Type property queries should <em>not</em> use <tt>declval</tt>,
because the well-formedness requirement of the specification of
<tt>is_constructible</tt> would become more complicated, because we
would need to make sure that the expression <i>CE</i> is checked in an
unevaluated context.
</p>
</li>

<li>
<p>
Also 20.7.6 [meta.rel]/4 is not modified similar to the previous bullet,
because with
the stricter requirements of not using <tt>declval()</tt> the well-formedness condition
would be harder to specify. The following changes are only editorial ones (e.g.
the removal of the duplicate declaration of <tt>create()</tt>):
</p>

<blockquote>
<p>
Given the following function prototype:
</p>

<blockquote><pre>template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type create();
</pre></blockquote>

<p>
the predicate condition for a template specialization
<tt>is_convertible&lt;From, To&gt;</tt> shall be satisfied if and only
if the return expression in the following code would be well-formed,
including any
implicit conversions to the return type of the function:
</p>

<blockquote><pre><del>template &lt;class T&gt;
typename add_rvalue_reference&lt;T&gt;::type create();</del>
To test() {
  return create&lt;From&gt;();
}
</pre></blockquote>
</blockquote>
</li>

<li>
<p>
Change the entry in column "Comments" for <tt>common_type</tt> in Table 51 �
Other transformations (20.7.7.6 [meta.trans.other]):
</p>

<p><i>[
NB: This wording change extends the type domain of <tt>common_type</tt> for <tt>cv
void =&gt; cv void</tt> transformations and thus makes <tt>common_type</tt> usable for
all binary type combinations that are supported by <tt>is_convertible</tt>
]</i></p>


<blockquote>
The member typedef <tt>type</tt> shall be defined as set out below. All
types in the parameter pack <tt>T</tt> shall be complete <ins>or
(possibly cv-qualified) <tt>void</tt></ins>. A program may specialize
this trait if at least one template parameter in the specialization is a
user-defined type. [<i>Note:</i> Such specializations are needed when
only explicit conversions are desired among the template arguments.
� <i>end note</i>]
</blockquote>
</li>

<li>
<p>
Change 20.7.7.6 [meta.trans.other]/3 as indicated:
</p>

<p><i>[
NB: This wording change is more than an editorial simplification of
the definition of <tt>common_type</tt>: It also extends its usefulness for <tt>cv
void</tt> types as outlined above
]</i></p>


<blockquote>
<p>
The nested typedef <tt>common_type::type</tt> shall be defined as follows:
</p>

<blockquote>
<p>
[..]
</p>
<pre>template &lt;class T, class U&gt;
struct common_type&lt;T, U&gt; {
<del>private:
  static T&amp;&amp; __t();
  static U&amp;&amp; __u();
public:</del>
  typedef decltype(true ? <del>__t</del><ins>declval&lt;T&gt;</ins>() : <del>__u</del><ins>declval&lt;U&gt;</ins>()) type;
};
</pre>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change X [func.ret]/1 as indicated
[<i>This part solves some main aspects of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1225">1225</a></i>]:
</p>

<blockquote><pre>namespace std {
  template &lt;class&gt; class result_of; // undefined

  template &lt;class Fn, class... ArgTypes&gt;
  class result_of&lt;Fn(ArgTypes...)&gt; {
  public :
    <del>// types</del>
    typedef <del>see below</del><ins>decltype(declval&lt;Fn&gt;() ( declval&lt;ArgTypes&gt;()... ))</ins> type;
  };
}
</pre>
<p>
<del>1 Given an rvalue <tt>fn</tt> of type <tt>Fn</tt> and values <tt>t1, t2, ..., tN</tt> of
types <tt>T1, T2, ..., TN</tt> in <tt>ArgTypes</tt>,
respectively, the <tt>type</tt> member is the result type of the expression
<tt>fn(t1, t2, ...,tN)</tt>. The values <tt>ti</tt>
are lvalues when the corresponding type <tt>Ti</tt> is an lvalue-reference
type, and rvalues otherwise.</del>
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="1256"></a>1256. <tt>weak_ptr</tt> comparison functions should be removed</h3>
<p><b>Section:</b> 20.9.10.3 [util.smartptr.weak] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-11-04 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Additional to the necessary cleanup of the description of the the
<tt>weak_ptr</tt> component from 20.9.10.3 [util.smartptr.weak]
described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1231">1231</a> it turns out that the currently deleted
comparison functions of <tt>weak_ptr</tt> are not needed at all: There
is no safe-bool conversion from <tt>weak_ptr</tt>, and it won't silently
chose a conversion to <tt>shared_ptr</tt>.
</p>

<p><i>[
2009-11-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.10.3 [util.smartptr.weak]/1 as indicated:
</p>

<blockquote><pre>namespace std {
template&lt;class T&gt; class weak_ptr {
public:
...
  <del>// comparisons</del>
  <del>template&lt;class Y&gt; bool operator&lt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
  <del>template&lt;class Y&gt; bool operator&lt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
  <del>template&lt;class Y&gt; bool operator&gt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
  <del>template&lt;class Y&gt; bool operator&gt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;</del>
};
...
</pre></blockquote>





<hr>
<h3><a name="1257"></a>1257. Header &lt;ios&gt; still contains a <code>concept_map</code></h3>
<p><b>Section:</b> 27.5 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-11-04 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostreams.base">issues</a> in [iostreams.base].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current WP still contains a <tt>concept_map</tt>.
</p>

<p><i>[
2009-11-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change Iostreams base classes 27.5 [iostreams.base], Header &lt;ios&gt; synopsis, 
as indicated:
</p>

<blockquote><pre><del>concept_map ErrorCodeEnum&lt;io_errc&gt; { };</del>
<ins>template &lt;&gt; struct is_error_code_enum&lt;io_errc&gt; : true_type { }</ins>
error_code make_error_code(io_errc e);
error_condition make_error_condition(io_errc e);
const error_category&amp; iostream_category();
</pre></blockquote>






<hr>
<h3><a name="1258"></a>1258. std::function Effects clause impossible to satisfy</h3>
<p><b>Section:</b> 20.8.14.2.2 [func.wrap.func.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-11-05 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As of 20.8.14.2.2 [func.wrap.func.mod]/2+ we have the following
prototype description:
</p>

<blockquote><pre>template&lt;class F, Allocator Alloc&gt;
  void assign(F, const Alloc&amp;);
</pre>
<blockquote>
<i>Effects:</i> <tt>function(f, a).swap(*this)</tt>
</blockquote>
</blockquote>

<p>
Two things: First the concept debris needs to be removed, second and
much more importantly, the effects clause is now impossible to satisfy,
because there is no constructor that would match the parameter sequence
(<tt>FunctionObject</tt>, <tt>Allocator</tt>) [plus the fact that no
<tt>f</tt> and no <tt>a</tt> is part of the signature]. The most
probable candidate is
</p>

<blockquote><pre>template&lt;class F, class A&gt; function(allocator_arg_t, const A&amp;, F);
</pre></blockquote>

<p>
and the effects clause needs to be adapted to use this signature.
</p>

<p><i>[
2009-11-13 Daniel brought wording up to date.
]</i></p>


<p><i>[
2009-11-15 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-02-11 Moved to Tentatively NAD Editorial after 5 positive votes on
c++std-lib.  It was noted that this issue was in partial conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>, and the two issues were merged in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>.
]</i></p>


<p><b>Rationale:</b></p>
<p>
Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1288">1288</a>.
</p>




<p><b>Proposed resolution:</b></p>
<p>
Change in 20.8.14.2.2 [func.wrap.func.mod] the complete prototype description as
indicated
</p>
<p><i>[
Question to
the editor: Shouldn't there a paragraph number in front of the Effects clause?
]</i></p>


<blockquote><pre>template&lt;class F, <del>Allocator Alloc</del><ins>class A</ins>&gt;
  void assign(F <ins>f</ins>, const A<del>lloc</del>&amp; <ins>a</ins>);
</pre>
<blockquote>
<ins>3</ins> <i>Effects:</i> <tt>function(<del>f, a</del><ins>allocator_arg, a,
f</ins>).swap(*this)</tt>
</blockquote>
</blockquote>





<hr>
<h3><a name="1260"></a>1260. <tt>is_constructible&lt;int*,void*&gt;</tt> reports true</h3>
<p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-11-07 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specification of <tt>is_constructible&lt;T,Args...&gt;</tt> in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
uses
</p>

<blockquote><pre>static_cast&lt;T&gt;(create&lt;Args&gt;()...)
</pre></blockquote>

<p>
for the one-argument case, but <tt>static_cast</tt> also permits
unwanted conversions such as <tt>void*</tt> to <tt>T*</tt> and
<tt>Base*</tt> to <tt>Derived*</tt>.
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to <del>NAD Editorial</del><ins>Resolved</ins>, this issue is addressed by paper 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3047.html">n3047</a>
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.7.4.3 [meta.unary.prop], p6:
</p>

<blockquote>
<p>
the predicate condition for a template specialization
<tt>is_constructible&lt;T, Args&gt;</tt> shall be satisfied, if and only
if the following <del>expression <i>CE</i></del> <ins>variable
definition</ins> would be well-formed:
</p>

<ul>
<li>
<p>
if <tt>sizeof...(Args) == <ins>0</ins> <del>1</del></tt><del>, the expression</del>:
</p>
<blockquote><pre><del>static_cast&lt;T&gt;(create&lt;Args&gt;()...)</del>
<ins>T t;</ins>
</pre></blockquote>
</li>
<li>
<p>
otherwise <del>the expression</del>:
</p>
<blockquote><pre>T<ins> t</ins>(create&lt;Args&gt;()...);
</pre></blockquote>
</li>
</ul>
</blockquote>





<hr>
<h3><a name="1261"></a>1261. Insufficent overloads for <tt>to_string</tt> / <tt>to_wstring</tt></h3>
<p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2009-11-10 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Reported on the gcc mailing list.
</p>

<blockquote>
The code "<tt>int i; to_string(i);</tt>" fails to compile, as
'<tt>int</tt>' is ambiguous between '<tt>long long</tt>' and '<tt>long
long unsigned</tt>'. It seems unreasonable to expect users to cast
numbers up to a larger type just to use <tt>to_string</tt>.
</blockquote>

<p><i>[
2009-11-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
21.3 [string.classes], change <tt>to_string</tt> and
<tt>to_wstring</tt> to:
</p>

<blockquote><pre><ins>string to_string(int val);</ins>
<ins>string to_string(unsigned val);</ins>
<ins>string to_string(long val);</ins>
<ins>string to_string(unsigned long val);</ins>
string to_string(long long val); 
string to_string(unsigned long long val); 
<ins>string to_string(float val);</ins>
<ins>string to_string(double val);</ins>
string to_string(long double val);

<ins>wstring to_wstring(int val);</ins>
<ins>wstring to_wstring(unsigned val);</ins>
<ins>wstring to_wstring(long val);</ins>
<ins>wstring to_wstring(unsigned long val);</ins>
wstring to_wstring(long long val); 
wstring to_wstring(unsigned long long val); 
<ins>wstring to_wstring(float val);</ins>
<ins>wstring to_wstring(double val);</ins>
wstring to_wstring(long double val);
</pre></blockquote>

<p>
In 21.5 [string.conversions], paragraph 7, change to:
</p>

<blockquote><pre><ins>string to_string(int val);</ins>
<ins>string to_string(unsigned val);</ins>
<ins>string to_string(long val);</ins>
<ins>string to_string(unsigned long val);</ins>
string to_string(long long val); 
string to_string(unsigned long long val); 
<ins>string to_string(float val);</ins>
<ins>string to_string(double val);</ins>
string to_string(long double val);
</pre>

<blockquote>
7 <i>Returns:</i> each function returns a <tt>string</tt> object holding
the character representation of the value of its argument that would be
generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format
specifier of <ins> <tt>"%d"</tt>, <tt>"%u"</tt>, <tt>"%ld"</tt>,
<tt>"%lu"</tt>, </ins> <tt>"%lld"</tt>, <tt>"%llu"</tt>,
<ins><tt>"%f"</tt>, <tt>"%f"</tt>,</ins> or <tt>"%Lf"</tt>, respectively,
where <tt>buf</tt> designates an internal character buffer of sufficient
size.
</blockquote>
</blockquote>

<p>
In 21.5 [string.conversions], paragraph 14, change to:
</p>

<blockquote><pre><ins>wstring to_wstring(int val);</ins>
<ins>wstring to_wstring(unsigned val);</ins>
<ins>wstring to_wstring(long val);</ins>
<ins>wstring to_wstring(unsigned long val);</ins>
wstring to_wstring(long long val); 
wstring to_wstring(unsigned long long val); 
<ins>wstring to_wstring(float val);</ins>
<ins>wstring to_wstring(double val);</ins>
wstring to_wstring(long double val);
</pre>

<blockquote>
14	<i>Returns:</i> Each function returns a <tt>wstring</tt> object
holding the character representation of the value of its argument that
would be generated by calling <tt>swprintf(buf, buffsz, fmt, val)</tt>
with a format specifier of <ins> <tt>L"%d"</tt>, <tt>L"%u"</tt>,
<tt>L"%ld"</tt>, <tt>L"%lu"</tt>, </ins><tt>L"%lld"</tt>,
<tt>L"%llu"</tt>, <ins><tt>L"%f"</tt>, <tt>L"%f"</tt>,</ins> or
<tt>L"%Lf"</tt>, respectively, where <tt>buf</tt> designates an internal
character buffer of sufficient size <tt>buffsz</tt>.
</blockquote>
</blockquote>





<hr>
<h3><a name="1262"></a>1262. <tt>std::less&lt;std::shared_ptr&lt;T&gt;&gt;</tt> is underspecified</h3>
<p><b>Section:</b> 20.9.10.2.7 [util.smartptr.shared.cmp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-11-10 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.9.10.2.7 [util.smartptr.shared.cmp]/5 says:
</p>

<blockquote>
For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the
partial specializations for <tt>shared_ptr</tt> shall yield a total order, even if
the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>,
<tt>&lt;=</tt>, and <tt>&gt;=</tt> do not. Moreover,
<tt>less&lt;shared_ptr&lt;T&gt; &gt;::operator()(a, b)</tt> shall return
<tt>std::less&lt;T*&gt;::operator()(a.get(), b.get())</tt>.
</blockquote>

<p>
This is necessary in order to use <tt>shared_ptr</tt> as the key in associate
containers because
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf">n2637</a>
changed <tt>operator&lt;</tt> on <tt>shared_ptr</tt>s to be
defined in terms of <tt>operator&lt;</tt> on the stored pointers (a mistake IMHO
but too late now.)  By 5.9 [expr.rel]/2 the result of comparing builtin
pointers is unspecified except in special cases which generally do not
apply to <tt>shared_ptr</tt>.
</p>

<p>
Earlier versions of the WP
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">n2798</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">n2857</a>)
had the following note on
that paragraph:
</p>

<blockquote>
[Editor's
note: It's not clear to me whether the first sentence is a requirement
or a note. The second
sentence seems to be a requirement, but it doesn't really belong here,
under <tt>operator&lt;</tt>.]
</blockquote>

<p>
I agree completely - if partial specializations are needed they should
be properly specified.
</p>

<p>
20.9.10.2.7 [util.smartptr.shared.cmp]/6 has a note saying the comparison operator
allows <tt>shared_ptr</tt> objects to be used as keys in associative
containers, which is misleading because something else like a
<tt>std::less</tt> partial specialization is needed.  If it is not correct that
note should be removed.
</p>

<p>
20.9.10.2.7 [util.smartptr.shared.cmp]/3 refers to '<tt>x</tt>' and
'<tt>y</tt>' but the prototype has parameters '<tt>a</tt>' and
'<tt>b</tt>' - that needs to be fixed even if the rest of the issue is
NAD.
</p>

<p>
I see two ways to fix this, I prefer the first because it removes the
need for any partial specializations and also fixes <tt>operator&gt;</tt> and
other comparisons when defined in terms of <tt>operator&lt;</tt>.
</p>

<ol>
<li>
<p>
Replace 20.9.10.2.7 [util.smartptr.shared.cmp]/3 with the following and
remove p5:
</p>

<blockquote><pre>template&lt;class T, class U&gt; bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b);
</pre>
<blockquote>
<p>
3  <i>Returns:</i> <del><tt>x.get() &lt; y.get()</tt>.</del>
<ins><tt>std::less&lt;V&gt;()(a.get(), b.get())</tt>, where <tt>V</tt> is the
composite pointer type (5.9 [expr.rel]).</ins>
</p>

<p>
4 <i>Throws:</i> nothing.
</p>

<p><del>
5 For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the
partial specializations for <tt>shared_ptr</tt> shall yield a total order, even if
the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>,
<tt>&lt;=</tt>, and <tt>&gt;=</tt> do not. Moreover,
<tt>less&lt;shared_ptr&lt;T&gt; &gt;::operator()(a, b)</tt> shall return
<tt>std::less&lt;T*&gt;::operator()(a.get(), b.get())</tt>.
</del></p>
<p>
6 [<i>Note:</i> Defining a comparison operator allows
<tt>shared_ptr</tt> objects to be used as keys in associative
containers. � <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>


<li>
<p>
Add to 20.9.10.2 [util.smartptr.shared]/1 (after the <tt>shared_ptr</tt> comparisons)
</p>

<blockquote><pre>template&lt;class T&gt; struct greater&lt;shared_ptr&lt;T&gt;&gt;;
template&lt;class T&gt; struct less&lt;shared_ptr&lt;T&gt;&gt;;
template&lt;class T&gt; struct greater_equal&lt;shared_ptr&lt;T&gt;&gt;;
template&lt;class T&gt; struct less_equal&lt;shared_ptr&lt;T&gt;&gt;;
</pre></blockquote>

<p>
Remove 20.9.10.2.7 [util.smartptr.shared.cmp]/5 and /6 and replace with:
</p>

<blockquote><pre>template&lt;class T, class U&gt; bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b);
</pre>
<blockquote>
<p>
3  <i>Returns:</i> <tt><del>x</del><ins>a</ins>.get() &lt; <del>y</del><ins>b</ins>.get()</tt>.
</p>

<p>
4 <i>Throws:</i> nothing.
</p>

<p><del>
5 For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the
partial specializations for <tt>shared_ptr</tt> shall yield a total order, even if
the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>,
<tt>&lt;=</tt>, and <tt>&gt;=</tt> do not. Moreover,
<tt>less&lt;shared_ptr&lt;T&gt; &gt;::operator()(a, b)</tt> shall return
<tt>std::less&lt;T*&gt;::operator()(a.get(), b.get())</tt>.
</del></p>
<p><del>
6 [<i>Note:</i> Defining a comparison operator allows
<tt>shared_ptr</tt> objects to be used as keys in associative
containers. � <i>end note</i>]
</del></p>
</blockquote>

<pre><ins>
template&lt;class T&gt; struct greater&lt;shared_ptr&lt;T&gt;&gt; :
binary_function&lt;shared_ptr&lt;T&gt;, shared_ptr&lt;T&gt;, bool&gt; {
  bool operator()(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;T&gt;&amp; b) const;
};
</ins></pre>

<blockquote><ins>
<tt>operator()</tt> returns <tt>greater&lt;T*&gt;()(a.get(), b.get())</tt>.
</ins></blockquote>

<pre><ins>
template&lt;class T&gt; struct less&lt;shared_ptr&lt;T&gt;&gt; :
binary_function&lt;shared_ptr&lt;T&gt;, shared_ptr&lt;T&gt;, bool&gt; {
  bool operator()(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;T&gt;&amp; b) const;
};
</ins></pre>

<blockquote><ins>
<tt>operator()</tt> returns <tt>less&lt;T*&gt;()(a.get(), b.get())</tt>.
</ins></blockquote>

<pre><ins>
template&lt;class T&gt; struct greater_equal&lt;shared_ptr&lt;T&gt;&gt; :
binary_function&lt;shared_ptr&lt;T&gt;, shared_ptr&lt;T&gt;, bool&gt; {
  bool operator()(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;T&gt;&amp; b) const;
};
</ins></pre>

<blockquote><ins>
<tt>operator()</tt> returns <tt>greater_equal&lt;T*&gt;()(a.get(), b.get())</tt>.
</ins></blockquote>

<pre><ins>
template&lt;class T&gt; struct less_equal&lt;shared_ptr&lt;T&gt;&gt; :
binary_function&lt;shared_ptr&lt;T&gt;, shared_ptr&lt;T&gt;, bool&gt; {
  bool operator()(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;T&gt;&amp; b) const;
};
</ins></pre>

<blockquote><ins>
<tt>operator()</tt> returns <tt>less_equal&lt;T*&gt;()(a.get(), b.get())</tt>.
</ins></blockquote>

</blockquote>
</li>
</ol>

<p><i>[
2009-11-18: Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Replace 20.9.10.2.7 [util.smartptr.shared.cmp]/3 with the following and
remove p5:
</p>

<blockquote><pre>template&lt;class T, class U&gt; bool operator&lt;(const shared_ptr&lt;T&gt;&amp; a, const shared_ptr&lt;U&gt;&amp; b);
</pre>
<blockquote>
<p>
3  <i>Returns:</i> <del><tt>x.get() &lt; y.get()</tt>.</del>
<ins><tt>less&lt;V&gt;()(a.get(), b.get())</tt>, where <tt>V</tt> is the
composite pointer type (5.9 [expr.rel]) of <tt>T*</tt> and <tt>U*</tt>.</ins>
</p>

<p>
4 <i>Throws:</i> nothing.
</p>

<p><del>
5 For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the
partial specializations for <tt>shared_ptr</tt> shall yield a total order, even if
the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>,
<tt>&lt;=</tt>, and <tt>&gt;=</tt> do not. Moreover,
<tt>less&lt;shared_ptr&lt;T&gt; &gt;::operator()(a, b)</tt> shall return
<tt>std::less&lt;T*&gt;::operator()(a.get(), b.get())</tt>.
</del></p>
<p>
6 [<i>Note:</i> Defining a comparison operator allows
<tt>shared_ptr</tt> objects to be used as keys in associative
containers. � <i>end note</i>]
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="1264"></a>1264. <tt>quick_exit</tt> support for freestanding implementations</h3>
<p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-11-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 172</b></p>

<p>
This issue is a response to NB comment UK-172
</p>

<p>
The functions <tt>quick_exit</tt> and <tt>at_quick_exit</tt> should be
added to the required features of <tt>&lt;cstdlib&gt;</tt> in a
freestanding implementation.
</p>

<p>
This comment was rejected in Summit saying neither <tt>at_exit</tt> nor
<tt>at_quick_exit</tt> should be required.  This suggests the comment was
misread, as <tt>atexit</tt> is already required to be supported.  If the LWG
really did wish to not require the registration functions be supported,
then a separate issue should be opened to change the current standard.
</p>

<p>
Given both <tt>exit</tt> and <tt>atexit</tt> are required, the UK panel feels it is
appropriate to require the new <tt>quick_exit</tt> facility is similarly
supported.
</p>

<p><i>[
2009-12-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Ammend p3 Freestanding implementations 17.6.1.3 [compliance]
</p>

<blockquote>
3 The supplied version of the header <tt>&lt;cstdlib&gt;</tt> shall
declare at least the functions <tt>abort<del>()</del></tt>, <tt>atexit<del>()</del></tt>,
<ins><tt>at_quick_exit</tt>,</ins> <del>and</del> <tt>exit<del>()</del></tt><ins>, and
<tt>quick_exit</tt></ins>(18.5 [support.start.term]). The other
headers listed in this table shall meet the same requirements as for a
hosted implementation.
</blockquote>






<hr>
<h3><a name="1267"></a>1267. Incorrect wording for <tt>condition_variable_any::wait_for</tt></h3>
<p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-17 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvarany">issues</a> in [thread.condition.condvarany].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.5.2 [thread.condition.condvarany]p18 and 30.5.2 [thread.condition.condvarany]p27 specify incorrect preconditions for
<tt>condition_variable_any::wait_for</tt>. The stated preconditions require that
<tt>lock</tt> has a <tt>mutex()</tt> member function, and that this produces the
same result for all concurrent calls to <tt>wait_for()</tt>. This is
inconsistent with <tt>wait()</tt> and <tt>wait_until()</tt> which do not impose
such a requirement.
</p>

<p><i>[
2009-12-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Remove 30.5.2 [thread.condition.condvarany]p18 and 30.5.2 [thread.condition.condvarany]p27.
</p>
<blockquote>
<pre>template &lt;class Lock, class Rep, class Period&gt;
  cv_status wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote>
<p><del>
18 <i>Precondition:</i> lock is locked by the calling thread, and either
</del></p>
<ul>
<li><del>
no other thread is waiting on this <tt>condition_variable</tt> object or
</del></li>
<li><del>
<tt>lock.mutex()</tt> returns the same value for each of the lock arguments
supplied by all concurrently waiting (via <tt>wait</tt>, <tt>wait_for</tt>, or
<tt>wait_until</tt>) threads.
</del></li>
</ul>
</blockquote>

<p>...</p>

<pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt;
  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
</pre>

<blockquote>

<p><del>
27 Precondition: lock is locked by the calling thread, and either
</del></p>
<ul>
<li><del>
no other thread is waiting on this <tt>condition_variable</tt> object or
</del></li>
<li><del>
<tt>lock.mutex()</tt> returns the same value for each of the lock arguments
supplied by all concurrently waiting (via <tt>wait</tt>, <tt>wait_for</tt>, or
<tt>wait_until</tt>) threads.
</del></li>
</ul>

</blockquote>

</blockquote>






<hr>
<h3><a name="1268"></a>1268. The Mutex requirements in 30.4.1 and 30.4.2 are wrong</h3>
<p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-17 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex">issues</a> in [thread.mutex].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>Mutex</tt> requirements in 30.4.1 [thread.mutex.requirements] and
30.4.1.3 [thread.timedmutex.requirements] confuse the requirements on the
behaviour of <tt>std::mutex</tt> et al with the requirements on
<tt>Lockable</tt> types for use with <tt>std::unique_lock</tt>,
<tt>std::lock_guard</tt> and <tt>std::condition_variable_any</tt>.
</p>

<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
<p>
Concepts of threads chapter and issue presentation are: Lockable &lt; Mutex &lt;
TimedMutex and Lockable &lt; TimedLockable &lt; TimedMutex.
</p>
<p>
Typo in failed deletion of Mutex in 30.4.4 p4 edits.
</p>
<p>
Lockable requirements are too weak for condition_variable_any, but the Mutex
requirements are too strong.
</p>
<p>
Need subset of Lockable requirements for condition_variable_any that does not
include try_lock. E.g. CvLockable &lt; Lockable.
</p>
<p>
Text needs updating to recent draft changes.
</p>
<p>
Needs to specify exception behavior in Lockable.
</p>
<p>
The current standard is fine for what it says, but it places requirements that
are too strong on authors of mutexes and locks.
</p>
<p>
Move to open status. Suggest Anthony look at condition_variable_any
requirements. Suggest Anthony refine requirements/concepts categories.
</p>
<p>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>
</p>
</blockquote>

<p><i>[
2010-03-28 Daniel synced with N3092.
]</i></p>


<p><i>[
2010-10-25 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3130.html">n3130</a> would solve this issue.
</blockquote>

<p><i>[
2010-11 Batavia:
]</i></p>


<blockquote>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3197.html">n3197</a>.
</blockquote>




<p><b>Proposed resolution:</b></p>
<p>
Add a new section to 30.2 [thread.req] after 30.2.4 [thread.req.timing] as follows:
</p>

<blockquote>
<p>
30.2.5 Requirements for Lockable types
</p>

<p>
The standard library templates <tt>unique_lock</tt> (30.4.2.2 [thread.lock.unique]), <tt>lock_guard</tt> (30.4.2.1 [thread.lock.guard]), <tt>lock</tt>, <tt>try_lock</tt> (30.4.3 [thread.lock.algorithm]) and <tt>condition_variable_any</tt> (30.5.2 [thread.condition.condvarany]) all operate on user-supplied
<tt>Lockable</tt> objects. Such an object must support the member functions
specified for either the <tt>Lockable</tt> Requirements or the
<tt>TimedLockable</tt> requirements as appropriate to acquire or release
ownership of a <tt>lock</tt> by a given <tt>thread</tt>. [<i>Note:</i> the
nature of any lock ownership and any synchronization it may entail are not part
of these requirements. � <i>end note</i>]
</p>

<p>
30.2.5.1  Lockable Requirements
</p>

<p>
In order to qualify as a <tt>Lockable</tt> type, the following expressions must
be supported, with the specified semantics, where <tt>m</tt> denotes a value of
type <tt>L</tt> that supports the <tt>Lockable</tt>:
</p>

<p>
The expression <tt>m.lock()</tt> shall be well-formed and have the following
semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Block until a lock can be acquired for the current thread.</dd>
  <dt>Return type:</dt><dd><tt>void</tt></dd>
</dl>

<p>
The expression <tt>m.try_lock()</tt> shall be well-formed and have the
following semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Attempt to acquire a lock for the current thread without blocking.</dd>
  <dt>Return type:</dt><dd><tt>bool</tt></dd>
  <dt>Returns:</dt><dd><tt>true</tt> if the lock was
  acquired, <tt>false</tt> otherwise.</dd>
</dl>

<p>
The expression <tt>m.unlock()</tt> shall be well-formed and have the
following semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Release a lock on <tt>m</tt> held by the current thread.</dd>
  <dt>Return type:</dt><dd><tt> void</tt></dd>
  <dt>Throws:</dt><dd> Nothing if the current thread holds a lock on <tt>m</tt>.</dd>
</dl>

<p>
30.2.5.2 <tt>TimedLockable</tt> Requirements
</p>

<p>
For a type to qualify as <tt>TimedLockable</tt> it must meet the
<tt>Lockable</tt> requirements, and additionally the following
expressions must be well-formed, with the specified semantics,
where <tt>m</tt> is an instance of a type <tt>TL</tt> that supports
the <tt>TimedLockable</tt> requirements, <tt>rel_time</tt> denotes
instantiation of <tt>duration</tt> (20.11.3 [time.duration]) and <tt>abs_time</tt>
denotes an instantiation of <tt>time_point</tt> (20.11.4 [time.point])

</p>

<p>
The expression <tt>m.try_lock_for(rel_time)</tt> shall be well-formed and have the
following semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Attempt to acquire a lock for the current
  thread within the specified time period.</dd>
  <dt>Return type:</dt><dd><tt>bool</tt></dd>
  <dt>Returns:</dt><dd><tt>true</tt> if the lock was
  acquired, <tt>false</tt> otherwise.</dd>
</dl>

<p>
The expression <tt>m.try_lock_until(abs_time)</tt> shall be well-formed and have the
following semantics:
</p>

<dl>
  <dt>Effects:</dt><dd>Attempt to acquire a lock for the current
  thread before the specified point in time.</dd>
  <dt>Return type:</dt><dd><tt>bool</tt></dd>
  <dt>Returns:</dt><dd><tt>true</tt> if the lock was
  acquired, <tt>false</tt> otherwise.</dd>
</dl>
</blockquote>

<p>
Replace 30.4.1 [thread.mutex.requirements] paragraph 2 with the
following:
</p>

<blockquote>
2 This section describes requirements on <del>template argument types
used to instantiate templates defined in</del> <ins>the mutex types
supplied by</ins> the C++ standard library. <del>The template
definitions in the C++ standard library refer</del> These types shall
conform to the named <tt>Mutex</tt> requirements whose details are set
out below.  In this description, <tt>m</tt> is an object
of <del>a <tt>Mutex</tt> type</del>
<ins>one of the standard library mutex types <tt>std::mutex</tt>,
<tt>std::recursive_mutex</tt>, <tt>std::timed_mutex</tt> or
<tt>std::recursive_timed_mutex</tt>.</ins>.
</blockquote>

<p>
Add the following paragraph after 30.4.1 [thread.mutex.requirements]
paragraph 2:
</p>

<blockquote><ins>
A <tt>Mutex</tt> type shall conform to the <tt>Lockable</tt>
requirements (30.2.5.1).
</ins></blockquote>

<p>
Replace 30.4.1.3 [thread.timedmutex.requirements] paragraph 1 with the
following:
</p>

<blockquote>
<ins>The C++ standard library <tt>TimedMutex</tt> types <tt>std::timed_mutex</tt>
  and <tt>std::recursive_timed_mutex</tt> </ins>
<del>A <tt>TimedMutex</tt> type</del> shall meet the requirements for
a <tt>Mutex</tt> type. In addition, <del>it</del><ins>they</ins> shall
meet the requirements set out <del>in this Clause 30.4.2</del><ins>below</ins>,
where <tt>rel_time</tt> denotes an instantiation of <tt>duration</tt>
(20.11.3 [time.duration]) and <tt>abs_time</tt> denotes an instantiation
of <tt>time_point</tt> (20.11.4 [time.point]).
</blockquote>

<p>
Add the following paragraph after 30.4.1.3 [thread.timedmutex.requirements] paragraph 1:
</p>

<blockquote><ins>
A <tt>TimedMutex</tt> type shall conform to the <tt>TimedLockable</tt>
requirements (30.2.5.1).
</ins></blockquote>


<p>
Add the following paragraph following 30.4.2.1 [thread.lock.guard]
paragraph 1:
</p>

<blockquote><ins>
The supplied <tt>Mutex</tt> type shall meet the <tt>Lockable</tt> 
requirements
(30.2.5.1).
</ins></blockquote>

<p>
Add the following paragraph following 30.4.2.2 [thread.lock.unique]
paragraph 1:
</p>

<blockquote><ins>
The supplied <tt>Mutex</tt> type shall meet the <tt>Lockable</tt> 
requirements
(30.2.5.1). <tt>unique_lock&lt;Mutex&gt;</tt> meets the <tt>Lockable</tt>
requirements. If <tt>Mutex</tt> meets the <tt>TimedLockable</tt> 
requirements
(30.2.5.2) then <tt>unique_lock&lt;Mutex&gt;</tt> also meets the
<tt>TimedLockable</tt> requirements.
</ins></blockquote>

<p>
Replace the use of "mutex" or "mutex object" with "lockable object"
throughout clause 30.4.2 [thread.lock] paragraph 1:
</p>

<blockquote>
1 A lock is an object that holds a reference to
a <del>mutex</del><ins>lockable object</ins> and may unlock
the <del>mutex</del><ins>lockable object</ins> during the lock's
destruction (such as when leaving block scope). A thread of execution
may use a lock to aid in managing <del>mutex</del> ownership <ins>of a
lockable object</ins> in an exception safe manner. A lock is said to
own a <del>mutex</del><ins>lockable object</ins> if it is currently
managing the ownership of that <del>mutex</del><ins>lockable
object</ins> for a thread of execution. A lock does not manage the
lifetime of the <del>mutex</del><ins>lockable object</ins> it
references.  [ Note: Locks are intended to ease the burden of
unlocking the <del>mutex</del><ins>lockable object</ins> under both
normal and exceptional circumstances. � end note ]
</blockquote>

<p>30.4.2 [thread.lock] paragaph 2:</p>

<blockquote>
2 Some lock constructors take tag types which describe what should be
done with the <del>mutex</del><ins>lockable</ins> object during the
lock's constuction.
</blockquote>

<p>30.4.2.1 [thread.lock.guard] paragaph 1:</p>

<blockquote>
1 An object of type <tt>lock_guard</tt> controls the ownership of a
  <del>mutex</del><ins>lockable</ins> object within a scope. A
<tt>lock_guard</tt> object maintains ownership of
a <del>mutex</del><ins>lockable</ins> object throughout
the <tt>lock_guard</tt> object's lifetime. The behavior of a program
is undefined if the <del>mutex</del><ins>lockable object</ins>
referenced by <tt>pm</tt> does not exist for the entire lifetime (3.8)
of the <tt>lock_guard</tt> object. <ins><tt>Mutex</tt> shall meet
  the <tt>Lockable</tt> requirements (30.2.5.1).</ins>
</blockquote>

<p>30.4.2.2 [thread.lock.unique] paragaph 1:</p>

<blockquote>
1 An object of type <tt>unique_lock</tt> controls the ownership of
a <del>mutex</del><ins>lockable object</ins> within a
scope. <del>Mutex</del> <del>o</del><ins>O</ins>wnership <ins>of the
lockable object</ins> may be acquired at construction or after
construction, and may be transferred, after acquisition, to
another <tt>unique_lock</tt> object. Objects of
type <tt>unique_lock</tt> are not copyable but are movable. The
behavior of a program is undefined if the contained
pointer <tt>pm</tt> is not null and the mutex pointed to
by <tt>pm</tt> does not exist for the entire remaining lifetime (3.8)
of the <tt>unique_lock</tt> object. <ins><tt>Mutex</tt> shall meet
the <tt>Lockable</tt> requirements (30.2.5.1).</ins>
</blockquote>


<p>
Add the following to the precondition of <tt>unique_lock(mutex_type&amp;
 m,
const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)</tt> in 
30.4.2.2.1 [thread.lock.unique.cons] paragraph 18:
</p>

<blockquote><pre>template &lt;class Clock, class Duration&gt;
  unique_lock(mutex_type&amp; m, const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre>

<blockquote>
18 <i>Requires:</i> If <tt>mutex_type</tt> is not a recursive mutex 
the
calling thread does not own the mutex. <ins>The supplied <tt>mutex_type</tt>
type shall meet the <tt>TimedLockable</tt> requirements (30.2.5.2).</ins>
</blockquote>
</blockquote>

<p>
Add the following to the precondition of <tt>unique_lock(mutex_type&amp;
 m,
const chrono::duration&lt;Rep, Period&gt;&amp; rel_time)</tt> in 
30.4.2.2.1 [thread.lock.unique.cons]
paragraph 22
</p>

<blockquote>
22  <i>Requires:</i> If <tt>mutex_type</tt> is not a recursive mutex
 the
calling thread does not own the mutex. <ins>The supplied <tt>mutex_type</tt>
type shall meet the <tt>TimedLockable</tt> requirements (30.2.5.2).</ins>
</blockquote>

<p>
Add the following as a precondition of <tt>bool try_lock_until(const
chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)</tt> before
30.4.2.2.2 [thread.lock.unique.locking] paragraph 8
</p>

<blockquote><pre>template &lt;class Clock, class Duration&gt;
  bool try_lock_until(const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
</pre>
<blockquote><ins>
<i>Requires:</i> The supplied <tt>mutex_type</tt> type shall meet the
<tt>TimedLockable</tt> requirements (30.2.5.2).
</ins></blockquote>
</blockquote>

<p>
Add the following as a precondition of <tt>bool try_lock_for(const
chrono::duration&lt;Rep, Period&gt;&amp; rel_time)</tt> before 
30.4.2.2.2 [thread.lock.unique.locking] paragraph 12
</p>

<blockquote><pre>template &lt;class Rep, class Period&gt;
  bool try_lock_for(const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre>
<blockquote><ins>
<i>Requires:</i> The supplied <tt>mutex_type</tt> type shall meet the
<tt>TimedLockable</tt> requirements (30.2.5.2).
</ins></blockquote>
</blockquote>

<p>
Replace 30.4.3 [thread.lock.algorithm] p1 with the following:
</p>

<blockquote><pre>template &lt;class L1, class L2, class... L3&gt; int try_lock(L1&amp;, L2&amp;, L3&amp;...);
</pre>
<blockquote>
1 <i>Requires:</i> Each template parameter type shall meet the
<tt><del>Mutex</del> <ins>Lockable</ins></tt> requirements
<ins>(30.2.5.1).</ins><del>, except that a call to <tt>try_lock()</tt> 
may throw
an exception.</del> [<i>Note:</i> The <tt>unique_lock</tt> class 
template meets
these requirements when suitably instantiated. � <i>end note</i>]
</blockquote>
</blockquote>

<p>
Replace 30.4.3 [thread.lock.algorithm] p4 with the following:
</p>

<blockquote><pre>template &lt;class L1, class L2, class... L3&gt; void lock(L1&amp;, L2&amp;, L3&amp;...);
</pre>
<blockquote>
4 <i>Requires:</i> Each template parameter type shall meet the
<tt>Mutex<del>Mutex</del> <ins>Lockable</ins></tt>
requirements <ins>(30.2.5.1).</ins><del>, except that a call to
<tt>try_lock()</tt> may throw an exception.</del> [<i>Note:</i> The
<tt>unique_lock</tt> class template meets these requirements when 
suitably
instantiated. � <i>end note</i>]
</blockquote>
</blockquote>

<p>
Replace 30.5.2 [thread.condition.condvarany] paragraph 1 with:
</p>

<blockquote>
1 A <tt>Lock</tt> type shall meet the <del>requirements for a <tt>Mutex</tt>
type</del> <ins><tt>Lockable</tt> requirements (30.2.5.1)</ins>, except 
that
<tt>try_lock</tt> is not required. [<i>Note:</i> All of the standard 
mutex types
meet this requirement. � <i>end note</i>]
</blockquote>






<hr>
<h3><a name="1270"></a>1270. <tt>result_of</tt> should be moved to <tt>&lt;type_traits&gt;</tt></h3>
<p><b>Section:</b> X [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-11-19 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.ret">issues</a> in [func.ret].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 198</b></p>

<p>
NB Comment: UK-198 makes this request among others.  It refers to a more
detailed issue that BSI did not manage to submit by the CD1 ballot deadline
though.
</p>

<p>
<tt>result_of</tt> is essentially a metafunction to return the type of an
expression, and belongs with the other library metafunctions in
<tt>&lt;type_traits&gt;</tt> rather than lurking in <tt>&lt;functional&gt;</tt>.
 The current definition in <tt>&lt;functional&gt;</tt> made sense when
<tt>result_of</tt> was nothing more than a protocol to enable several components
in <tt>&lt;functional&gt;</tt> to provide their own result types, but it has
become a more general tool.  For instance, <tt>result_of</tt> is now used in the
threading and futures components.
</p>

<p>
Now that <tt>&lt;type_traits&gt;</tt> is a required header for free-standing
implementations it will be much more noticeable (in such environments) that a
particularly useful trait is missing, unless that implementation also chooses to
offer <tt>&lt;functional&gt;</tt> as an extension.
</p>

<p>
The simplest proposal is to simply move the wording (editorial direction below)
although a more consistent form for type_traits would reformat this as a table.
</p>

<p>
Following the acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>, <tt>result_of</tt> now
depends on the <tt>declval</tt> function template, tentatively provided
in <tt>&lt;utility&gt;</tt> which is <em>not</em> (yet) required of a
free-standing implementation.
</p>

<p>
This dependency is less of an issue when <tt>result_of</tt> continues to
live in <tt>&lt;functional&gt;</tt>.
</p>

<p>
Personally, I would prefer to clean up the dependencies so both
<tt>result_of</tt> and <tt>declval</tt> are available in a free-standing
implementation, but that would require slightly more work than suggested
here.  A minimal tweak would be to require <tt>&lt;utility&gt;</tt> in a
free-standing implementation, although there are a couple of subtle
issues with <tt>make_pair</tt>, which uses <tt>reference_wrapper</tt> in
its protocol and that is much harder to separate cleanly from
<tt>&lt;functional&gt;</tt>.
</p>

<p>
An alternative would be to enact the other half of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2979.html">N2979</a>
and create a new minimal header for the new C++0x library facilities to
be added to the freestanding requirements (plus <tt>swap</tt>.)
</p>

<p>
I have a mild preference for the latter, although there are clearly
reasons to consider better library support for free-standing in general,
and adding the whole of <tt>&lt;utility&gt;</tt> could be considered a step in that
direction.  See NB comment
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3009.html#JP23">JP-23</a>
for other suggestions (<tt>array</tt>, <tt>ratio</tt>)
</p>

<p><i>[
2010-01-27 Beman updated wording.
]</i></p>


<blockquote>
<p>
The original wording is preserved here:
</p>
<blockquote>

<p>
Move X [func.ret] to a heading below 20.7 [meta].  Note
that in principle we should not change the tag, although this is a new tag for
0x.  If it has been stable since TR1 it is clearly immutable though.
</p>

<p>
This wording should obviously adopt any other changes currently in (Tentatively)
Ready status that touch this wording, such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1255">1255</a>.
</p>

</blockquote>
</blockquote>

<p><i>[
2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>From Function objects 20.8 [function.objects], Header &lt;functional&gt; 
synopsis, remove:</i></p>
<blockquote>
  <pre>// 20.7.4 result_of:
template &lt;class&gt; class result_of; <i>// undefined</i>
template &lt;class F, class... Args&gt; class result_of&lt;F(ArgTypes...)&gt;;</pre>
</blockquote>

<p><i>Remove Function object return types X [func.ret] in its entirety. 
This sub-section reads:</i></p>
<blockquote>
  <pre>namespace std {
  template &lt;class&gt; class result_of; <i>// undefined</i>

  template &lt;class Fn, class... ArgTypes&gt;
  class result_of&lt;Fn(ArgTypes...)&gt; {
  public :
    // types
    typedef see below type;
  };
}</pre>
  <p>Given an rvalue <code>fn</code> of type <code>Fn</code> and values <code>
  t1, t2, ..., tN</code> of types T1, T2, ..., TN in <code>ArgTypes</code>, 
  respectively, the type member is the result type of the expression <code>
  fn(t1, t2, ...,tN)</code>. The values <code>ti</code> are lvalues when the 
  corresponding type <code>Ti</code> is an lvalue-reference type, and rvalues 
  otherwise.</p>
</blockquote>
<p><i>To Header &lt;type_traits&gt; synopsis 20.7.2 [meta.type.synop], add at 
the indicated location:</i></p>
<blockquote>
  <pre>template &lt;class T&gt; struct underlying_type;
<ins>template &lt;class T&gt; struct result_of; <i>// not defined
</i>template &lt;class Fn, class... ArgTypes&gt; struct result_of&lt;Fn(ArgTypes...)&gt;;</ins></pre>
</blockquote>
<p><i>To Other transformations 20.7.7.6 [meta.trans.other], Table 51 � 
Other transformations, add:</i></p>
<blockquote>
  <table style="border-collapse: collapse;" border="1" bordercolor="#111111" cellpadding="3" cellspacing="0">
    <tbody><tr>
      <td><b>Template</b></td>
      <td><b>Condition</b></td>
      <td><b>Comments</b></td>
    </tr>
    <tr>
      <td valign="top"><code>template &lt;class T&gt;<br>
      struct underlying_type;</code></td>
      <td valign="top"><code>T</code> shall be an enumeration type 
      (7.2)</td>
      <td valign="top">The member typedef <code>type</code> shall 
      name the underlying type of <code>T</code>.</td>
    </tr>
    <tr>
      <td valign="top"><ins><code>template &lt;class Fn, class... ArgTypes&gt;
      struct result_of&lt;Fn(ArgTypes...)&gt;;</code></ins></td>
      <td valign="top"><ins><code>Fn</code> shall be a function object type
      20.8 [function.objects], reference to function, or reference to
      function object type.
      <tt>decltype(declval&lt;Fn&gt;()(declval&lt;ArgTypes&gt;()...))</tt> shall
      be well formed.</ins></td>
      <td valign="top"><ins>The member typedef <code>type</code> 
      shall name the type <code>decltype(declval&lt;Fn&gt;()(declval&lt;ArgTypes&gt;()...))</code>.</ins></td>
    </tr>
  </tbody></table>
</blockquote>
<p>At the end of Other transformations 20.7.7.6 [meta.trans.other] add:</p>

<blockquote>
<p>[<i>Example:</i> Given these definitions:</p>

  <pre>typedef bool(&amp;PF1)();
typedef short(*PF2)(long);

struct S {
&nbsp; operator PF2() const;
&nbsp; double operator()(char, int&amp;);
 };</pre>
<p>the following assertions will hold:</p>
  <pre>static_assert(std::is_same&lt;<wbr>std::result_of&lt;S(int)&gt;::type, short&gt;::value, "Error!");
static_assert(std::is_same&lt;<wbr>std::result_of&lt;S&amp;(unsigned char, int&amp;)&gt;::type, double&gt;::value, "Error!");
static_assert(std::is_same&lt;<wbr>std::result_of&lt;PF1()&gt;::type, bool&gt;::value, "Error!");</pre>
  <p><i>&nbsp;� end example</i>]</p>
</blockquote>





<hr>
<h3><a name="1271"></a>1271. CR undefined in duration operators</h3>
<p><b>Section:</b> 20.11.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-11-21 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
IMO <tt>CR</tt> alone is not really defined (it should be <tt>CR(Rep1,
Rep2)</tt>).
</p>

<p><i>[
2009-12-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.11.3.5 [time.duration.nonmember] paragraphs 9 and 12:
</p>

<blockquote><pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
9 <i>Returns:</i> <tt>duration&lt;CR<ins>(Rep1, Rep2)</ins>, Period&gt;(d) /= s</tt>.
</blockquote>

<pre>template &lt;class Rep1, class Period, class Rep2&gt;
  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
12 <i>Returns:</i> <tt>duration&lt;CR<ins>(Rep1, Rep2)</ins>, Period&gt;(d) %= s</tt>.
</blockquote>

</blockquote>





<hr>
<h3><a name="1276"></a>1276. <tt>forwardlist</tt> missing allocator constructors</h3>
<p><b>Section:</b> 23.3.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-12-12 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist">issues</a> in [forwardlist].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I found that forward_list has only
</p>

<blockquote><pre>forward_list(const forward_list&lt;T,Allocator&gt;&amp; x);
forward_list(forward_list&lt;T,Allocator&gt;&amp;&amp; x);
</pre></blockquote>

<p>
but misses
</p>

<blockquote><pre>forward_list(const forward_list&amp; x, const Allocator&amp;);
forward_list(forward_list&amp;&amp; x, const Allocator&amp;);
</pre></blockquote>

<p>
Note to other reviewers: I also checked the container adaptors for similar
inconsistencies, but as far as I can see these are already handled by the
current active issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1194">1194</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1199">1199</a>.
</p>

<p><i>[
2010-01-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
In 23.3.3 [forwardlist]/3, class template forward_list synopsis change as
indicated:
</p>

<blockquote><pre>forward_list(const forward_list<del>&lt;T,Allocator&gt;</del>&amp; x);
forward_list(forward_list<del>&lt;T,Allocator&gt;</del>&amp;&amp; x);
<ins>forward_list(const forward_list&amp;, const Allocator&amp;);</ins>
<ins>forward_list(forward_list&amp;&amp;, const Allocator&amp;);</ins>
</pre></blockquote>






<hr>
<h3><a name="1277"></a>1277. <tt>std::thread::id</tt> should be trivially copyable</h3>
<p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2009-11-24 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The class definition of <tt>std::thread::id</tt> in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
is:
</p>

<blockquote><pre>class thread::id {
public:
  id();
};
</pre></blockquote>

<p>
Typically, I expect that the internal data members will either be
pointers or integers, so that in practice the class will be trivially
copyable. However, I don't think the current wording guarantees it, and
I think it would be useful. In particular, I can see a use for
<tt>std::atomic&lt;std::thread::id&gt;</tt> to allow a <tt>thread</tt>
to claim ownership of a data structure atomicly, and
<tt>std::atomic&lt;T&gt;</tt> requires that <tt>T</tt> is trivially
copyable.
</p>

<p><i>[
2010-02-12 Moved to Tentatively Ready after 7 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add a new sentence to 30.3.1.1 [thread.thread.id] p1:
</p>

<blockquote>
1 An object of type <tt>thread::id</tt> provides a unique identifier for
each thread of execution and a single distinct value for all
<tt>thread</tt> objects that do not represent a thread of execution
(30.3.1 [thread.thread.class]). Each thread of execution has an
associated <tt>thread::id</tt> object that is not equal to the
<tt>thread::id</tt> object of any other thread of execution and that is
not equal to the <tt>thread::id</tt> object of any <tt>std::thread</tt>
object that does not represent threads of execution. The library may
reuse the value of a <tt>thread::id</tt> of a terminated thread that can
no longer be joined. <ins><tt>thread::id</tt> shall be a trivially
copyable class (9 [class]).</ins>
</blockquote>






<hr>
<h3><a name="1278"></a>1278. inconsistent return values for <tt>forward_list::insert_after</tt></h3>
<p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2009-11-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.modifiers">issues</a> in [forwardlist.modifiers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
After applying LDR<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <tt>forward_list</tt> now has 5
overloads of <tt>insert_after</tt>, all returning an iterator.
</p>

<p>
However, two of those - inserting a single object - return "An iterator
pointing to a copy of <tt>x</tt> [the inserted object]" while the other
three - inserting zero or more objects - return an iterator equivalent
to the position parameter, pointing before any possibly inserted
objects.
</p>

<p>
Is this the intended change? 
</p>

<p>
I don't really know what <tt>insert_after(position, empty_range)</tt>
should really return, but always returning <tt>position</tt> seems less
than useful.
</p>

<p><i>[
2010-02-04 Howard adds:
]</i></p>


<blockquote>
<p>
I agree this inconsistency will be error prone and needs to be fixed. 
Additionally <tt>emplace_after</tt>'s return value is unspecified.
</p>
</blockquote>

<p><i>[
2010-02-04 Nico provides wording.
]</i></p>


<p><i>[
2010 Pittsburgh:
]</i></p>


<blockquote>
We prefer to return an iterator to the last inserted element.  Modify the
proposed wording and then set to Ready.
</blockquote>

<p><i>[
2010-03-15 Howard adds:
]</i></p>


<blockquote>
Wording updated and set to Ready.
</blockquote>



<p><b>Proposed resolution:</b></p>
<p>
In <tt>forward_list</tt> modifiers 23.3.3.4 [forwardlist.modifiers]
make the following modifications:
</p>

<blockquote>
<pre>iterator insert_after(const_iterator position, size_type n, const T&amp; x);
</pre>
<blockquote>
<p>...</p>
<p>
10 <i>Returns:</i> <del>position.</del> <ins>An iterator pointing to the last
inserted copy of <tt>x</tt> or <tt>position</tt> if <tt>n == 0</tt>.</ins>
</p>
</blockquote>

<pre>template &lt;class InputIterator&gt;
  iterator insert_after(const_iterator position, InputIterator first, InputIterator last);
</pre>
<blockquote>
<p>...</p>

<p>
13 <i>Returns:</i> <del>position.</del> <ins>An iterator pointing to the last
inserted element or <tt>position</tt> if <tt>first == last</tt>.</ins>
</p>
</blockquote>

<pre>iterator insert_after(const_iterator position, initializer_list&lt;T&gt; il);
</pre>
<blockquote>
<p>...</p>

<p>
15 <i>Returns:</i> <del>position.</del> <ins>An iterator pointing to the last
inserted element or <tt>position</tt> if <tt>il</tt> is empty.</ins>
</p>
</blockquote>

<pre>template &lt;class... Args&gt;
  iterator emplace_after(const_iterator position, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>...</p>
<p>17 ...</p>

<p><ins>
<i>Returns:</i> An iterator pointing to the new constructed element from
args.
</ins></p>
</blockquote>

</blockquote>






<hr>
<h3><a name="1280"></a>1280. initialization of stream iterators</h3>
<p><b>Section:</b> 24.6.1.1 [istream.iterator.cons], 24.6.2.1 [ostream.iterator.cons.des] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-12-04 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.cons">issues</a> in [istream.iterator.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
24.6.1.1 [istream.iterator.cons] describes the effects in terms of:
</p>

<blockquote><pre>basic_istream&lt;charT,traits&gt;* in_stream; // exposition only
</pre>

<p>
3 <i>Effects:</i> Initializes <i>in_stream</i> with <tt>s</tt>.
</p>
</blockquote>

<p>
That should be <tt>&amp;s</tt> and similarly for 24.6.2.1 [ostream.iterator.cons.des].
</p>

<p><i>[
2009-12-23 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change 24.6.1.1 [istream.iterator.cons] like so:
</p>

<blockquote><pre>istream_iterator(istream_type&amp; s);
</pre>
<blockquote>
3 <i>Effects:</i> Initializes <i>in_stream</i> with <tt><ins>&amp;</ins>s</tt>.
<i>value</i> ...
</blockquote>
</blockquote>

<p>
And 24.6.2.1 [ostream.iterator.cons.des] like so:
</p>

<blockquote><pre>ostream_iterator(ostream_type&amp; s);
</pre>
<blockquote>
1 <i>Effects:</i> Initializes <i>out_stream</i> with <tt><ins>&amp;</ins>s</tt>
and <i>delim</i> with null.
</blockquote>

<pre>ostream_iterator(ostream_type&amp; s, const charT* delimiter);
</pre>
<blockquote>
2 <i>Effects:</i> Initializes <i>out_stream</i> with <tt><ins>&amp;</ins>s</tt>
and <i>delim</i> with <tt>delimiter</tt>.
</blockquote>
</blockquote>






<hr>
<h3><a name="1283"></a>1283. <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> need clarification
of moved-from state</h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-12-12 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 150</b></p>

<p>
There is on going confusion over what one can and can not do with a moved-from
object (e.g.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3009.html#UK150">UK 150</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#910">910</a>).
This issue attempts to clarify that moved-from objects are valid objects with an
unknown state.
</p>

<p><i>[
2010-01-22 Wording tweaked by Beman.
]</i></p>


<p><i>[
2010-01-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-01-23 Alisdair opens:
]</i></p>


<blockquote>
<p>
I'm afraid I must register an objection.
</p>

<p>
My primary objection is that I have always been opposed to this kind of a
resolution as over-constraining.  My preferred example is a call implementing
the pImpl idiom via <tt>unique_ptr</tt>.  Once the pImpl has been moved from, it
is no longer safe to call the vast majority of the object's methods, yet I see
no reason to make such a type unusable in the standard library.  I would prefer
a resolution along the lines suggested in the UK comment, which only requires
that the object can be safely destroyed, and serve as the target of an
assignment operator (if supported.)
</p>

<p>
However, I will not hold the issue up if I am a lone dissenting voice on this
(yes, that is a call to hear more support, or I will drop that objection in
Pittsburgh)
</p>

<p>
With the proposed wording, I'm not clear what the term 'valid object' means.  In
my example above, is a pImpl holding a null pointer 'valid'?  What about a float
holding a signalling NaN?  What determines if an object is valid?  Without a
definition of a valid/invalid object, I don't think this wording adds anything,
and this is an objection that I do want resolved.
</p>

<p><i>[
2010-01-24 Alisdair removes his objection.
]</i></p>


<p><i>[
2010-01-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


</blockquote>

<p><i>[
2010-02-10 Reopened.  The wording here has been merged into <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a>.
]</i></p>


<p><i>[
2010-02-10 Moved to Tentatively <del>NAD Editorial</del><ins>Resolved</ins> after 5 postive votes on
c++std-lib.  Rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
This issue is now addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the follwing tables in 20.2.1 [utility.arg.requirements] as shown:
</p>

<blockquote>

<table border="1">
<caption>Table 33 � <tt>MoveConstructible</tt> requirements <b>[moveconstructible]</b></caption>
<tbody><tr>
<th>Expression</th>
<th>Post-condition</th>
</tr>
<tr>
<td>
<tt>T t(rv)</tt>
</td>
<td>
<tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction.
</td>
</tr>
<tr>
<td colspan="2">
[<i>Note:</i>
<del>There is no requirement on the value of <tt>rv</tt> after the
construction.</del>
<ins><tt>rv</tt> remains a valid object.  Its state is unspecified.</ins>
� <i>end note</i>]
</td>
</tr>
</tbody></table>

</blockquote>
<blockquote>

<table border="1">
<caption>Table 35 � <tt>MoveAssignable</tt> requirements <b>[moveassignable]</b></caption>
<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Return value</th>
<th>Post-condition</th>
</tr>
<tr>
<td>
<tt>t = rv</tt>
</td>
<td>
<tt>T&amp;</tt>
</td>
<td>
<tt>t</tt>
</td>
<td>
<tt>t</tt> is equivalent to the value of <tt>rv</tt> before the assigment.
</td>
</tr>
<tr>
<td colspan="4">
[<i>Note:</i>
<del>There is no requirement on the value of <tt>rv</tt> after the
assignment.</del>
<ins><tt>rv</tt> remains a valid object.  Its state is unspecified.</ins>
� <i>end note</i>]
</td>
</tr>
</tbody></table>

</blockquote>





<hr>
<h3><a name="1284"></a>1284. <tt>vector&lt;bool&gt; initializer_list</tt> constructor missing an allocator argument</h3>
<p><b>Section:</b> 23.4.2 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2009-12-09 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specialization for <tt>vector&lt;bool&gt;</tt> (23.4.2 [vector.bool])
has a constructor
</p>

<blockquote><pre>vector(initializer_list&lt;bool&gt;);
</pre></blockquote>

<p>
which differs from the base template's constructor (and other containers) in
that it has no <tt>allocator</tt> parameter.
</p>

<p><i>[
2009-12-16 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change the signature in the synopsis of 23.4.2 [vector.bool] to 
</p>

<blockquote><pre>vector(initializer_list&lt;bool&gt;<ins>, const Allocator&amp; = Allocator()</ins>);
</pre></blockquote>





<hr>
<h3><a name="1285"></a>1285. <tt>allocator_traits</tt> call to <tt>new</tt></h3>
<p><b>Section:</b> 20.9.4.2 [allocator.traits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-12-10 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.traits.members">issues</a> in [allocator.traits.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> added "<tt>::</tt>" to the call to <tt>new</tt>
within <tt>allocator::construct</tt>.  I suspect we want to retain that fix.
</p>

<p><i>[
2009-12-13 Moved to Tentatively Ready after 7 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change 20.2.5 [allocator.requirements], table 40 "Allocator requirements":
</p>

<blockquote>
<table border="1">
<caption>Table 40 � Allocator requirements</caption>
<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion/note<br>pre-/post-condition</th>
<th>Default</th>
</tr>
<tr>
<td>
<tt>a.construct(c,args)</tt>
</td>
<td>
(not used)
</td>
<td>
Effect: Constructs an object of type <tt>C</tt> at <tt>c</tt>
</td>
<td>
<tt><ins>::</ins>new ((void*)c) C(forward&lt;Args&gt;(args)...)</tt>
</td>
</tr>
</tbody></table>
</blockquote>

<p>
Change 20.9.4.2 [allocator.traits.members], p4:
</p>

<blockquote><pre>template &lt;class T, class... Args&gt;
  static void construct(Alloc&amp; a, T* p, Args&amp;&amp;... args);
</pre>
<blockquote>
4 <i>Effects:</i> calls <tt>a.construct(p,
std::forward&lt;Args&gt;(args)...)</tt> if that call is well-formed; otherwise,
invokes <tt><ins>::</ins>new (static_cast&lt;void*&gt;(p))
T(std::forward&lt;Args&gt;(args)...)</tt>.
</blockquote>
</blockquote>





<hr>
<h3><a name="1286"></a>1286. <tt>allocator_traits::select_on_container_copy_construction</tt> type-o</h3>
<p><b>Section:</b> 20.9.4.2 [allocator.traits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-12-10 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.traits.members">issues</a> in [allocator.traits.members].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>allocator_traits::select_on_container_copy_construction</tt> refers to an
unknown "<tt>a</tt>":
</p>

<blockquote><pre>static Alloc select_on_container_copy_construction(const Alloc&amp; rhs);
</pre>

<blockquote>
7 <i>Returns:</i> <tt>rhs.select_on_container_copy_construction(a)</tt> if that
expression is well-formed; otherwise, <tt>rhs</tt>.
</blockquote>
</blockquote>

<p><i>[
2009-12-13 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.9.4.2 [allocator.traits.members], p7:
</p>

<blockquote><pre>static Alloc select_on_container_copy_construction(const Alloc&amp; rhs);
</pre>

<blockquote>
7 <i>Returns:</i>
<tt>rhs.select_on_container_copy_construction(<del>a</del>)</tt> if that
expression is well-formed; otherwise, <tt>rhs</tt>.
</blockquote>
</blockquote>





<hr>
<h3><a name="1287"></a>1287. <tt>std::function</tt> requires <tt>CopyConstructible</tt> target object</h3>
<p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-12-13 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I think <tt>std::function</tt> should require <tt>CopyConstructible</tt> for the
target object.
</p>

<p>
I initially thought that <tt>MoveConstructible</tt> was enough, but it's not. If
<tt>F</tt> is move-only then function's copy constructor cannot be called, but
because function uses type erasure, <tt>F</tt> is not known and so the copy
constructor cannot be disabled via <tt>enable_if</tt>.  One option would be to
throw an exception if you try to copy a function with a non-copyable target
type, but I think that would be a terrible idea.
</p>

<p>
So although the constructors require that the target be initialised by
<tt>std::move(f)</tt>, that's only an optimisation, and a copy constructor is
required.
</p>

<p><i>[
2009-12-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add to 20.8.14.2.1 [func.wrap.func.con] paragraph 9:
</p>

<blockquote><pre>template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>

<blockquote>
9  <i>Requires:</i> <ins><tt>F</tt> shall be <tt>CopyConstructible</tt>.</ins>
<tt>f</tt> shall be callable for argument types <tt>ArgTypes</tt> and return
type <tt>R</tt>. The copy constructor and destructor of <tt>A</tt> shall not
throw exceptions.
</blockquote>
</blockquote>






<hr>
<h3><a name="1288"></a>1288. <tt>std::function</tt> assignment from rvalues</h3>
<p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2009-12-13 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 20.8.14.2.1 [func.wrap.func.con]
</p>

<blockquote><pre>template&lt;class F&gt; function&amp; operator=(F f);
</pre>
<blockquote>
<p>
20        <i>Effects:</i> <tt>function(f).swap(*this);</tt>
</p>
<p>
21        <i>Returns:</i> <tt>*this</tt>
</p>
</blockquote>
</blockquote>

<p>
This assignment operator can be called such that <tt>F</tt> is an rvalue-reference e.g.
</p>

<blockquote><pre>func.operator=&lt;F&amp;&amp;&gt;(f);
</pre></blockquote>

<p>
There are two issues with this.
</p>

<ol>
<li>
the effects mean that <tt>f</tt> is passed as an lvalue and so there will be an
unnecessary copy. The argument should be forwarded, so that the copy can be
avoided.
</li>
<li>
It should not be necessary to use that syntax to pass an rvalue. As <tt>F</tt>
is a deduced context it can be made to work with either lvalues or rvalues.
</li>
</ol>

<p>
The same issues apply to <tt>function::assign</tt>.
</p>

<p>
N.B. this issue is not related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1287">1287</a> and applies whether that
issue is resolved or not. The wording below assumes the resolution of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a> has been applied.
</p>

<p><i>[
2009-12-16 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
201002-11 Opened by Alisdair for the purpose of merging <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1258">1258</a> into
this issue as there is a minor conflict.
]</i></p>


<p><i>[
2010-02-11 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
In 20.8.14.2.1 [func.wrap.func.con]
</p>

<blockquote><pre>template&lt;class F&gt; function&amp; operator=(F<ins>&amp;&amp;</ins> f);
</pre>
<blockquote>
<p>
20 <i>Effects:</i>
<tt>function(<ins>std::forward&lt;F&gt;(</ins>f<ins>)</ins>).swap(*this);</tt>
</p>
<p>
21        <i>Returns:</i> <tt>*this</tt>
</p>
</blockquote>
</blockquote>

<p>
In 20.8.14.2.2 [func.wrap.func.mod]
</p>

<blockquote><pre>template&lt;class F, <del>Allocator Alloc</del><ins>class A</ins>&gt;
  void assign(F<ins>&amp;&amp; f</ins>, const A<del>lloc</del>&amp; a);
</pre>
<blockquote>
<p>
<ins>3</ins> <i>Effects:</i> <tt>function(<del>f, a</del><ins>allocator_arg, a,
std::forward&lt;F&gt;(f)</ins>).swap(*this);</tt>
</p>
</blockquote>
</blockquote>

<p>
Update member function signature for class template in 20.8.14.2 [func.wrap.func]
</p>

<blockquote><pre>template&lt;class F&gt; function&amp; operator=(F<ins>&amp;&amp;</ins>);

template&lt;class F, class A&gt; void assign(F<ins>&amp;&amp;</ins>, const A&amp;);
</pre></blockquote>







<hr>
<h3><a name="1290"></a>1290. Don't require <tt>[u|bi]nary_function</tt> inheritance</h3>
<p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-12-14 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This issue is a follow-up of the discussion on issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a> during
the 2009 Santa Cruz meeting.
</p>

<p>
The class templates <tt>unary_function</tt> and <tt>binary_function</tt> are
actually very simple typedef providers,
</p>

<blockquote><pre>namespace std {

template &lt;class Arg, class Result&gt;
struct unary_function {
 typedef Arg argument_type;
 typedef Result result_type;
};

template &lt;class Arg1, class Arg2, class Result&gt;
struct binary_function {
 typedef Arg1 first_argument_type;
 typedef Arg2 second_argument_type;
 typedef Result result_type;
};

}
</pre></blockquote>

<p>
which <i>may</i> be used as base classes (similarly to the iterator template),
but were originally <i>not</i> intended as a customization point. The SGI
documentation introduced the concept <a href="http://www.sgi.com/tech/stl/AdaptableUnaryFunction.html">Adaptable Unary
Function</a> as function objects "with nested typedefs that define its argument
type and result type" and a similar definition for <a href="http://www.sgi.com/tech/stl/AdaptableBinaryFunction.html">Adaptable Binary
Function</a> related to <tt>binary_function</tt>. But as of TR1 a protocol was
introduced that relies on inheritance relations based on these types. 20.8.4 [refwrap]/3 b. 3 requires that a specialization of
<tt>reference_wrapper&lt;T&gt;</tt> shall derive from <tt>unary_function</tt>,
if type <tt>T</tt> is "a class type that is derived from
<tt>std::unary_function&lt;T1, R&gt;</tt>" and a similar inheritance-based rule
for <tt>binary_function</tt> exists as well.
</p>

<p>
As another disadvantage it has been pointed out in the TR1 issue list, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1837.pdf">N1837</a>
(see section 10.39), that the requirements of <tt>mem_fn</tt> 20.8.13 [func.memfn]/2+3 to <em>derive</em> from
<tt>std::unary_function/std::binary_function</tt> under circumstances, where the
provision of corresponding typedefs would be sufficient, unnecessarily prevent
implementations that take advantage of empty-base-class- optimizations.
</p>

<p>
Both requirements should be relaxed in the sense that the
<tt>reference_wrapper</tt> should provide typedef's <tt>argument_type</tt>,
<tt>first_argument_type</tt>, and <tt>second_argument_type</tt> based on similar
rules as the <i>weak result type</i> rule (20.8.2 [func.require]/3) does
specify the presence of <tt>result_type</tt> member types.
</p>

<p>
For a related issue see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1279">1279</a>.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3145.html">n3145</a> would resolve this issue as NAD editorial.
</blockquote>



<p><i>[
2010-11 Batavia: Solved by N3198
]</i></p>

<p>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3198.html">n3198</a>.
</p>

<p>
Previous proposed resolution:

</p><p><i>[
The here proposed resolution is an attempt to realize the common denominator of
the reflector threads c++std-lib-26011, c++std-lib-26095, and c++std-lib-26124.
]</i></p>


<ol>
<li>
<p>
Change X [base]/1 as indicated: <i>[The intend is to provide an
alternative fix for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1279">1279</a> and some editorial harmonization
with existing wording in the library, like 24.4.2 [iterator.basic]/1]</i>
</p>

<blockquote>
<p>
1 The following class<ins> templat</ins>es are provided to simplify the
<ins>definition of</ins> typedefs of the argument and result types <ins>for
function objects. The behavior of a program that adds specializations for any of
these templates is undefined.</ins><del>:</del>
</p>

<blockquote><pre>namespace std {
 template &lt;class Arg, class Result&gt;
 struct unary_function {
   typedef Arg argument_type;
   typedef Result result_type;
 };
}

namespace std {
 template &lt;class Arg1, class Arg2, class Result&gt;
 struct binary_function {
   typedef Arg1 first_argument_type;
   typedef Arg2 second_argument_type;
   typedef Result result_type;
 };
}
</pre></blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.8.4 [refwrap], class template <tt>reference_wrapper</tt>
synopsis as indicated: <i>[The intent is to remove the requirement that
<tt>reference_wrapper</tt> derives from <tt>unary_function</tt> or
<tt>binary_function</tt> if the situation requires the definition of the
typedefs <tt>argument_type</tt>, <tt>first_argument_type</tt>, or
<tt>second_argument_type</tt>. This change is suggested, because the new way of
definition uses the same strategy as the <em>weak result type</em> specification
applied to argument types, which provides the following advantages: It creates
less potential conflicts between <tt>[u|bi]nary_function</tt> bases and typedefs
in a function object and it ensures that user-defined function objects which
provide typedefs but no such bases are handled as first class citizens.]</i>
</p>

<blockquote><pre>namespace std {
 template &lt;class T&gt; class reference_wrapper
   <del>: public unary_function&lt;T1, R&gt; // <i>see below</i></del>
   <del>: public binary_function&lt;T1, T2, R&gt; // <i>see below</i></del>
 {
 public :
   // types
   typedef T type;
   typedef <i>see below</i> result_type; // not always defined
   <ins>typedef <i>see below</i> argument_type; // not always defined</ins>
   <ins>typedef <i>see below</i> first_argument_type; // not always defined</ins>
   <ins>typedef <i>see below</i> second_argument_type; // not always defined</ins>

   // construct/copy/destroy
   ...
 };
</pre></blockquote>
</li>

<li>
<p>
Change 20.8.4 [refwrap]/3 as indicated: <i>[The intent is to remove the
requirement that <tt>reference_wrapper</tt> derives from <tt>unary_function</tt>
if the situation requires the definition of the typedef <tt>argument_type</tt>
and <tt>result_type</tt>. Note that this clause does concentrate on
<tt>argument_type</tt> alone, because the <tt>result_type</tt> is already ruled
by p. 2 via the <em>weak result type</em> specification. The new way of
specifying <tt>argument_type</tt> is equivalent to the <em>weak result type</em>
specification]</i>
</p>

<blockquote>
<p>
3 The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall <del>be
derived from <tt>std::unary_function&lt;T1, R&gt;</tt></del><ins>define a nested
type named <tt>argument_type</tt> as a synonym for <tt>T1</tt></ins> only if the
type <tt>T</tt> is any of the following:
</p>
<ul>
<li>a function type or a pointer to function type taking one argument
of type <tt>T1</tt><del> and returning <tt>R</tt></del>
</li>
<li>a pointer to member function <tt>R T0::f</tt> <em>cv</em> (where
<em>cv</em> represents the member function's cv-qualifiers);
the type <tt>T1</tt> is <em>cv</em> <tt>T0*</tt>
</li>
<li>a class type <del>that is derived from
<tt>std::unary_function&lt;T1, R&gt;</tt></del><ins>with a member type
<tt>argument_type</tt>;
	the type <tt>T1</tt> is <tt>T::argument_type</tt></ins>
</li>
</ul>
</blockquote>
</li>

<li>
<p>
Change 20.8.4 [refwrap]/4 as indicated: <i>[The intent is to remove the
requirement that <tt>reference_wrapper</tt> derives from
<tt>binary_function</tt> if the situation requires the definition of the typedef
<tt>first_argument_type</tt>, <tt>second_argument_type</tt>, and
<tt>result_type</tt>. Note that this clause does concentrate on
<tt>first_argument_type</tt> and <tt>second_argument_type</tt> alone, because
the <tt>result_type</tt> is already ruled by p. 2 via the <em>weak result
type</em> specification. The new way of specifying <tt>first_argument_type</tt>
and <tt>second_argument_type</tt> is equivalent to the <em>weak result type</em>
specification]</i>
</p>

<blockquote>
<p>
The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall <del>be
derived from <tt>std::binary_function&lt;T1, T2, R&gt;</tt></del><ins>define two
nested types named <tt>first_argument_type</tt> and
<tt>second_argument_type</tt> as a synonym for <tt>T1</tt> and <tt>T2</tt>,
respectively,</ins> only if the type <tt>T</tt> is any of the following:
</p>
<ul>
<li>a function type or a pointer to function type taking two arguments
of types <tt>T1</tt> and <tt>T2</tt><del> and returning
<tt>R</tt></del>
</li>
<li>a pointer to member function <tt>R T0::f(T2)</tt> <em>cv</em>
(where <em>cv</em> represents the member function's cv-qualifiers);
	the type <tt>T1</tt> is <em>cv</em> <tt>T0*</tt>
</li>
<li>a class type <del>that is derived from
<tt>std::binary_function&lt;T1, T2, R&gt;</tt></del><ins>with member
types <tt>first_argument_type</tt>
	and <tt>second_argument_type</tt>; the type <tt>T1</tt> is
<tt>T::first_argument_type</tt> and the type <tt>T2</tt> is
	<tt>T::second_argument_type</tt></ins>
</li>
</ul>
</blockquote>
</li>

<li>
<p>
Change 20.8.13 [func.memfn]/2+3 as indicated: <i>[The intent is to remove
the requirement that mem_fn's return type has to derive
from <tt>[u|bi]nary_function</tt>. The reason for suggesting the
change here is to better support empty-base-class optimization
choices as has been pointed out in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1837.pdf">N1837</a>]</i>
</p>

<blockquote>
<p>
2 The simple call wrapper shall <del>be derived from
<tt>std::unary_function&lt;<em>cv</em> T*, <i>Ret</i>&gt;</tt></del><ins>define
two nested types named <tt>argument_type</tt> and <tt>result_type</tt> as a
synonym for <tt><em>cv</em> T*</tt> and <tt><i>Ret</i></tt>, respectively,</ins>
when <tt>pm</tt> is a pointer to member function with cv-qualifier <em>cv</em>
and taking no arguments, where <tt><i>Ret</i></tt> is <tt>pm</tt>'s return type.
</p>
<p>
3 The simple call wrapper shall <del>be derived from
<tt>std::binary_function&lt;<em>cv</em> T*, T1,
<i>Ret</i>&gt;</tt></del><ins>define three nested types named
<tt>first_argument_type</tt>, <tt>second_argument_type</tt>, and
<tt>result_type</tt> as a synonym for <tt><em>cv</em> T*</tt>, <tt>T1</tt>, and
<tt><i>Ret</i></tt>, respectively,</ins> when <tt>pm</tt> is a pointer to member
function with cv-qualifier <em>cv</em> and taking one argument of type
<tt>T1</tt>, where <tt><i>Ret</i></tt> is <tt>pm</tt>'s return type.
</p>
</blockquote>
</li>

</ol>
<p></p>

<p><b>Proposed resolution:</b></p>
Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3198.html">n3198</a>.




<hr>
<h3><a name="1292"></a>1292. <tt>std::function</tt> should support all callable types</h3>
<p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-12-19 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Some parts of the specification of <tt>std::function</tt> is unnecessarily
restricted to a subset of all callable types (as defined in 20.8.1 [func.def]/3), even though the intent clearly is to be usable for
<em>all</em> of them as described in 20.8.14.2 [func.wrap.func]/1. This
argument becomes strengthened by the fact that current C++0x-compatible
compilers work fine with them:
</p>

<blockquote><pre>#include &lt;functional&gt;
#include &lt;iostream&gt;

struct A
{
  int foo(int i) const {return i+1;}
};

struct B
{
  int mem;
};

int main()
{
  std::function&lt;int(const A&amp;, int)&gt; f(&amp;A::foo);
  A a;
  std::cout &lt;&lt; f(a, 1) &lt;&lt; '\n';
  std::cout &lt;&lt; f.target_type().name() &lt;&lt; '\n';
  typedef int (A::* target_t)(int) const;
  target_t* p = f.target&lt;target_t&gt;();
  std::cout &lt;&lt; (p != 0) &lt;&lt; '\n';
  std::function&lt;int(B&amp;)&gt; f2(&amp;B::mem);
  B b = { 42 };
  std::cout &lt;&lt; f2(b) &lt;&lt; '\n';
  std::cout &lt;&lt; f2.target_type().name() &lt;&lt; '\n';
  typedef int (B::* target2_t);
  target2_t* p2 = f2.target&lt;target2_t&gt;();
  std::cout &lt;&lt; (p2 != 0) &lt;&lt; '\n';
}
</pre></blockquote>

<p>
The problematics passages are 20.8.14.2.1 [func.wrap.func.con]/10:
</p>

<blockquote><pre>template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>...</p>
<p>
10 <i>Postconditions:</i> <tt>!*this</tt> if any of the following hold:
</p>
<ul>
<li>
<tt>f</tt> is a NULL function pointer.
</li>
<li>
<tt>f</tt> is a NULL member function pointer.
</li>
<li>
<tt>F</tt> is an instance of the function class template, and <tt>!f</tt>
</li>
</ul>
</blockquote>
</blockquote>

<p>
because it does not consider pointer to data member and all constraints based on
<em>function objects</em> which like 20.8.14.2 [func.wrap.func]/2 or 20.8.14.2.5 [func.wrap.func.targ]/3. The latter two will be resolved by the proposed
resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#870">870</a> and are therefore not handled here.
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.14.2.1 [func.wrap.func.con]/10+11 as indicated:
</p>

<blockquote><pre>template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>...</p>
<p>
10 <i>Postconditions:</i> <tt>!*this</tt> if any of the following hold:
</p>
<ul>
<li>
<tt>f</tt> is a NULL function pointer.
</li>
<li>
<tt>f</tt> is a NULL <ins>pointer to</ins> member <del>function pointer</del>.
</li>
<li>
<tt>F</tt> is an instance of the function class template, and <tt>!f</tt>
</li>
</ul>

<p>
11 Otherwise, <tt>*this</tt> targets a copy of <tt>f</tt> <del>or</del><ins>,
initialized with</ins> <tt>std::move(f)</tt> <del>if <tt>f</tt> is not a pointer
to member function, and targets a copy of <tt>mem_fn(f)</tt> if <tt>f</tt> is a
pointer to member function</del>. [<i>Note:</i> implementations are encouraged
to avoid the use of dynamically allocated memory for small function objects, for
example, where <tt>f</tt>'s target is an object holding only a pointer or
reference to an object and a member function pointer. � <i>end note</i>]
</p>

</blockquote>
</blockquote>





<hr>
<h3><a name="1293"></a>1293. <tt>unique_ptr&lt;T[], D&gt;</tt> needs to get rid of <i>unspecified-pointer-type</i></h3>
<p><b>Section:</b> 20.9.9.3 [unique.ptr.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-12-20 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses UK 211</b></p>

<p>
As a response to UK 211 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a> has replaced the
<i>unspecified-pointer-type</i> by <tt>nullptr_t</tt> to allow assignment of
type-safe null-pointer literals in the non-array form of
<tt>unique_ptr::operator=</tt>, but did not the same for the specialization for
arrays of runtime length. But without this parallel change of the signature we
have a status quo, where <tt>unique_ptr&lt;T[], D&gt;</tt> declares a member
function which is completely unspecified.
</p>

<p><i>[
2009-12-21 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-03-14 Howard adds:
]</i></p>


<blockquote>
We moved
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>
to the formal motions page in Pittsburgh which should obsolete this issue.  I've
moved this issue to NAD Editorial, solved by N3073.
</blockquote>



<p><b>Rationale:</b></p>
<p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 20.9.9.3 [unique.ptr.runtime], class template <tt>unique_ptr&lt;T[],
D&gt;</tt> synopsis, change as indicated:
</p>

<blockquote><pre>// assignment
unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
unique_ptr&amp; operator=(<del><i>unspecified-pointer-type</i></del><ins>nullptr_t</ins>);
</pre></blockquote>






<hr>
<h3><a name="1294"></a>1294. Difference between callable wrapper and forwarding  call wrapper unclear</h3>
<p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-12-21 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current wording in the standard makes it hard to discriminate the difference
between a "call wrapper" as defined in 20.8.1 [func.def]/5+6:
</p>

<blockquote>
<p>
5 A <i>call wrapper type</i> is a type that holds a callable object and supports
a call operation that forwards to that object.
</p>
<p>
6 A <i>call wrapper</i> is an object of a call wrapper type.
</p>
</blockquote>

<p>
and a "forwarding call wrapper" as defined in 20.8.2 [func.require]/4:
</p>

<blockquote>
<p>
4 [..] A <i>forwarding call wrapper</i> is a call wrapper that can be called
with an argument list. [<i>Note:</i> in a typical implementation forwarding call
wrappers have an overloaded function call operator of the form
</p>

<blockquote><pre>template&lt;class... ArgTypes&gt;
R operator()(ArgTypes&amp;&amp;... args) <i>cv-qual</i>;
</pre></blockquote>

<p>
� <i>end note</i>]
</p>
</blockquote>

<p>
Reason for this lack of clear difference seems to be that the wording adaption
to variadics and rvalues that were applied after it's original proposal in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1673.html#call%20wrapper">N1673</a>:
</p>

<blockquote>
<p>
[..] A <b>forwarding call wrapper</b> is a call wrapper that can be called
with an argument list <tt>t1, t2, ..., tN</tt> where each <tt>ti</tt> is an lvalue.
The effect of calling a forwarding call wrapper with one or more
arguments that are rvalues is implementation defined. [<i>Note:</i> in
a typical implementation forwarding call wrappers have overloaded
function call operators of the form
</p>

<blockquote><pre>template&lt;class T1, class T2, ..., class TN&gt;
R operator()(T1&amp; t1, T2&amp; t2, ..., TN&amp; tN) <i>cv-qual</i>;
</pre></blockquote>

<p>
� <i>end note</i>]
</p>
</blockquote>

<p>
combined with the fact that the word "forward" has two different meanings in
this context. This issue attempts to clarify the difference better.
</p>

<p><i>[
2010-09-14 Daniel provides improved wording and verified that it is correct against N3126. Previous resolution is shown here:
]</i></p>


<blockquote>
<p>
4 [..] A <i>forwarding call wrapper</i> is a call wrapper that can be called
with an <ins>arbitrary</ins> argument list<ins> and uses perfect forwarding to
deliver the arguments to the wrapped callable object</ins>. [<i>Note:</i> in a
typical implementation forwarding call wrappers have an overloaded function call
operator of the form
</p>

<blockquote><pre>template&lt;class... ArgTypes&gt;
R operator()(ArgTypes&amp;&amp;... args) <i>cv-qual</i>;
</pre></blockquote>

<p>
� <i>end note</i>]
</p>
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.2 [func.require]/4 as indicated:
</p>

<blockquote><p>
[..] A <em>forwarding call wrapper</em> is a call wrapper that can be called with an <ins>arbitrary</ins> argument 
list <ins>and delivers the arguments as references to the wrapped callable object. This forwarding step shall ensure
that rvalue arguments are delivered as rvalue-references and lvalue arguments are delivered as lvalue-references</ins>. 
[<em>Note</em>: in a typical implementation forwarding call wrappers have an overloaded function call operator of the 
form
</p>

<blockquote><pre>template&lt;class... UnBoundArgs&gt;
R operator()(UnBoundArgs&amp;&amp;... unbound_args) <em>cv-qual</em>;
</pre></blockquote>
<p>
� <em>end note</em> ]
</p>
</blockquote>






<hr>
<h3><a name="1295"></a>1295. Contradictory call wrapper requirements</h3>
<p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-12-22 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.8.2 [func.require]/3 b 1 says
</p>

<blockquote>
<p>
3 If a call wrapper (20.8.1 [func.def]) has a <i>weak result type</i> the
type of its member type <tt>result_type</tt> is based on the type <tt>T</tt> of
the wrapper's target object (20.8.1 [func.def]):
</p>

<ul>
<li>
if <tt>T</tt> is a function, reference to function, or pointer to function type,
<tt>result_type</tt> shall be a synonym for the return type of <tt>T</tt>;
</li>
<li>
[..]
</li>
</ul>
</blockquote>

<p>
The first two enumerated types (function and reference to function)
can never be valid types for <tt>T</tt>, because
</p>

<p>
20.8.1 [func.def]/7
</p>

<blockquote>
7 A <i>target object</i> is the callable object held by a call wrapper.
</blockquote>

<p>
and 20.8.1 [func.def]/3
</p>

<blockquote>
3 A <i>callable type</i> is a pointer to function, a pointer to member function,
a pointer to member data, or a class type whose objects can appear immediately
to the left of a function call operator.
</blockquote>

<p>
exclude functions and references to function as "target objects".
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.2 [func.require]/3 b 1 as indicated:
</p>

<blockquote>
<p>
3 If a call wrapper (20.8.1 [func.def]) has a <i>weak result type</i> the
type of its member type <tt>result_type</tt> is based on the type <tt>T</tt> of
the wrapper's target object (20.8.1 [func.def]):
</p>

<ul>
<li>
if <tt>T</tt> is a <del>function, reference to function, or</del> pointer to
function type, <tt>result_type</tt> shall be a synonym for the return type of
<tt>T</tt>;
</li>
<li>
[..]
</li>
</ul>
</blockquote>






<hr>
<h3><a name="1298"></a>1298. Missing specialization of <tt>ctype_byname&lt;char&gt;</tt></h3>
<p><b>Section:</b> 22.2 [locale.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-12-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>&lt;locale&gt;</tt> synopsis in 22.2 [locale.syn] calls out an
explicit specialization for <tt>ctype_byname&lt;char&gt;</tt>, however no such
specialization is defined in the standard.  The only reference I can find to
<tt>ctype_byname&lt;char&gt;</tt> is 22.3.1.1.2 [locale.facet]:Table 77
� Required specializations (for facets) which also refers to
<tt>ctype_byname&lt;wchar_t&gt;</tt> which has no special consideration.
</p>

<p>
Is the intent an explicit <em>instantiation</em> which would use a slightly
different syntax? Should the explicit specialization simply be struck?
</p>

<p><i>[
2010-01-31 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
22.2 [locale.syn]
</p>

<blockquote>
<p>
Strike the explicit specialization for <tt>ctype_byname&lt;char&gt;</tt> from
the <tt>&lt;locale&gt;</tt> synopsis
</p>
<blockquote><pre>...
template &lt;class charT&gt; class ctype_byname;
<del>template &lt;&gt;            class ctype_byname&lt;char&gt;;  // <i>specialization</i></del>
...
</pre></blockquote>
</blockquote>





<hr>
<h3><a name="1299"></a>1299. Confusing typo in specification for <tt>get_time</tt></h3>
<p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-12-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Extended Manipulators 27.7.4 [ext.manip] p8 defines the semantics of
<tt>get_time</tt> in terms of a function <tt>f</tt>.
</p>

<blockquote><pre>template &lt;class charT, class traits&gt;
void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm* tmb, const charT* fmt) {
   typedef istreambuf_iterator&lt;charT, traits&gt; Iter;
   typedef time_get&lt;charT, Iter&gt; TimeGet;

   ios_base::iostate err = ios_base::goodbit;
   const TimeGet&amp; tg = use_facet&lt;TimeGet&gt;(str.getloc());

   tm.get(Iter(str.rdbuf()), Iter(), str, err, tmb, fmt, fmt + traits::length(fmt));

   if (err != ios_base::goodbit)
       str.setstate(err):
}
</pre></blockquote>

<p>
Note the call to <tt>tm.get</tt>.  This is clearly an error, as <tt>tm</tt> is a
type and not an object.  I believe this should be <tt>tg.get</tt>, rather than
<tt>tm</tt>, but this is not my area of expertise.
</p>

<p><i>[
2010-01-14 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
Change 27.7.4 [ext.manip] p8:
</p>

<blockquote><pre>template &lt;class charT, class traits&gt;
void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm* tmb, const charT* fmt) {
   typedef istreambuf_iterator&lt;charT, traits&gt; Iter;
   typedef time_get&lt;charT, Iter&gt; TimeGet;

   ios_base::iostate err = ios_base::goodbit;
   const TimeGet&amp; tg = use_facet&lt;TimeGet&gt;(str.getloc());

   t<ins>g</ins><del>m</del>.get(Iter(str.rdbuf()), Iter(), str, err, tmb, fmt, fmt + traits::length(fmt));

   if (err != ios_base::goodbit)
       str.setstate(err):
}
</pre></blockquote>





<hr>
<h3><a name="1303"></a>1303. <tt>shared_ptr</tt>, <tt>unique_ptr</tt>, and rvalue references v2</h3>
<p><b>Section:</b> 20.9.9.2 [unique.ptr.single], 20.9.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2010-01-23 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>
20.9.10.2 [util.smartptr.shared]/1 still says:
</p>

<blockquote><pre>template &lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y, D&gt;&amp; r) = delete;
template &lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y, D&gt;&amp; r) = delete;
</pre></blockquote>

<p>
I believe that this is unnecessary now that "rvalue references v2"
prevents rvalue references from binding to lvalues, and I didn't
see a Library Issue tracking this.
</p>

<p><i>[
2010-02-12 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>
Strike from 20.9.9.2 [unique.ptr.single]:
</p>

<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
  ...
  unique_ptr(const unique_ptr&amp;) = delete;
  <del>template &lt;class U, class E&gt; unique_ptr(const unique_ptr&lt;U, E&gt;&amp;) = delete;</del>
  unique_ptr&amp; operator=(const unique_ptr&amp;) = delete;
  <del>template &lt;class U, class E&gt; unique_ptr&amp; operator=(const unique_ptr&lt;U, E&gt;&amp;) = delete;</del>
};
</pre></blockquote>

<p>
Strike from 20.9.10.2 [util.smartptr.shared]:
</p>

<blockquote><pre>template&lt;class T&gt; class shared_ptr {
  ...
  <del>template &lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y, D&gt;&amp; r) = delete;</del>
  ...
  <del>template &lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y, D&gt;&amp; r) = delete;</del>
  ...
};
</pre></blockquote>






<hr>
<h3><a name="1306"></a>1306. <tt>pointer</tt> and <tt>const_pointer</tt> for <tt>&lt;array&gt;</tt></h3>
<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2010-01-24 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Class <tt>&lt;array&gt;</tt> is the only sequence container class that has no
types <tt>pointer</tt> and <tt>const_pointer</tt> defined. You might argue that
this makes no sense because there is no allocator support, but on the other
hand, types <tt>reference</tt> and <tt>const_reference</tt> are defined for
<tt>array</tt>.
</p>

<p><i>[
2010-02-11 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add to Class template array 23.3.1 [array]:
</p>

<blockquote><pre>namespace std {
  template &lt;class T, size_t N &gt;
  struct array {
    ...
    typedef T value_type;
    <ins>typedef T * pointer;</ins>
    <ins>typedef const T * const_pointer;</ins>
    ...
  };
}
</pre></blockquote>





<hr>
<h3><a name="1307"></a>1307. <tt>exception_ptr</tt> and <tt>allocator</tt> pointers don't understand !=</h3>
<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-01-26 <b>Last modified:</b> 2010-11-19</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current requirements for a conforming implementation of
<tt>std::exception_ptr</tt> (18.8.5 [propagation]/1-6) does not clarify
whether the expression
</p>

<blockquote><pre>e1 != e2
e1 != nullptr
</pre></blockquote>

<p>
with <tt>e1</tt> and <tt>e2</tt> being two values of type
<tt>std::exception_ptr</tt> are supported or not. Reason for this oddity is that
the concept <tt>EqualityComparable</tt> does not provide operator <tt>!=</tt>.
</p>

<p>
For the same reason programmers working against the types <tt>X::pointer</tt>,
<tt>X::const_pointer</tt>, <tt>X::void_pointer</tt>, and
<tt>X::const_void_pointer</tt> of any allocator concept <tt>X</tt> (20.2.5 [allocator.requirements]/4 + Table 40) in a generic context can not rely
on the availability of the != operation, which is rather unnatural and
error-prone.
</p>

<p><i>[
2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3073.html">N3073</a>.
</p>


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="1309"></a>1309. Missing expressions for <tt>Move/CopyConstructible</tt></h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-02-03 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 33 � MoveConstructible requirements [moveconstructible] and
Table 34 � CopyConstructible requirements [copyconstructible] support
solely the following expression:
</p>

<blockquote><pre>T t(rv)
</pre></blockquote>

<p>
where <tt>rv</tt> is defined to be as "non-const rvalue of type <tt>T</tt>"  and
<tt>t</tt> as a "modifiable lvalue of type <tt>T</tt>" in 20.2.1 [utility.arg.requirements]/1.
</p>

<p>
This causes two different defects:
</p>

<ol type="a">
<li>
<p>
We cannot move/copy-initialize a <em>const</em> lvalue of type <tt>T</tt> as in:
</p>

<blockquote><pre>int get_i();

const int i1(get_i());
</pre></blockquote>

<p>
both in Table 33 and in Table 34.
</p>
</li>

<li>
<p>
The single support for
</p>

<blockquote><pre>T t(rv)
</pre></blockquote>

<p>
in case of <tt>CopyConstructible</tt> means that we cannot provide an
lvalue as a source of a copy as in
</p>

<blockquote><pre>const int&amp; get_lri();

int i2(get_lri());
</pre></blockquote>
</li>
</ol>

<p>
I believe this second defect is due to the fact that this single
expression supported <em>both</em> initialization situations according
to the old (implicit) lvalue reference -&gt; rvalue reference
conversion rules.
</p>

<p>
Finally [copyconstructible] refers to some name <tt>u</tt> which is not part of
the expression, and both [copyconstructible] and [moveconstructible] should
support construction expressions from temporaries - this would be a stylistic
consequence in the light of the new <tt>DefaultConstructible</tt> requirements
and compared with existing requirements (see e.g. Container requirements or the
output/forward iterator requirements)..
</p>

<p><i>[
2010-02-09 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>


<p><i>[
2010-02-10 Reopened. The proposed wording of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1283">1283</a> has been
merged here.
]</i></p>


<p><i>[
2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>

<li>
<p>
Change 20.2.1 [utility.arg.requirements]/1 as indicated: <i>[This change
suggestion is motivated to make type descriptions clearer: First, <tt>a</tt>,
<tt>b</tt>, and <tt>c</tt> <em>may</em> also be non-<tt>const T</tt>. Second, <tt>u</tt>
is described in a manner consistent with the container requirements tables.]</i>
</p>

<blockquote>
1 The template definitions in the C++ standard library refer to various named
requirements whose details are set out in tables 31-38. In these tables,
<tt>T</tt> is a<ins>n object or reference</ins> type to be supplied by a C++
program instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
values of type <ins>(possibly</ins> <tt>const<ins>)</ins> T</tt>; <tt>s</tt> and
<tt>t</tt> are modifiable lvalues of type <tt>T</tt>; <tt>u</tt> <ins>denotes an
identifier;</ins> <del>is a value of type (possibly <tt>const</tt>) <tt>T</tt>;
and</del> <tt>rv</tt> is a<ins>n</ins> <del>non-const</del> rvalue of type
<tt>T</tt><ins>; and <tt>v</tt> is an lvalue of type (possibly <tt>const</tt>)
<tt>T</tt> or an rvalue of type <tt>const T</tt></ins>.
</blockquote>
</li>

<li>
<p>
In 20.2.1 [utility.arg.requirements] Table 33 ([moveconstructible])
change as indicated <i>[Note: The symbol <tt>u</tt> is defined to be either a
const or a non-const value and is the right one we need here]</i>:
</p>

<blockquote>
<table border="1">
<caption>Table 33 � <tt>MoveConstructible</tt> requirements [moveconstructible]</caption>

<tbody><tr>
<th>Expression</th>
<th>Post-condition</th>
</tr>

<tr>
<td>
<tt>T <del>t</del><ins>u</ins>(rv)<ins>;</ins></tt>
</td>
<td>
<tt><del>t</del><ins>u</ins></tt> is equivalent
to the value of <tt>rv</tt> before the construction
</td>
</tr>

<tr>
<td><ins><tt>T(rv)</tt></ins></td>
<td><ins><tt>T(rv)</tt> is equivalent to the value of <tt>rv</tt> before the
construction</ins></td>
</tr>

<tr>
<td colspan="2">[<i>Note:</i>
<del>There is no requirement on the value of <tt>rv</tt> after the
construction.</del>
<ins><tt>rv</tt> remains a valid object.  Its state is unspecified.</ins>
� <i>end note</i>]</td>
</tr>
</tbody></table>
</blockquote>
</li>

<li>
<p>
In 20.2.1 [utility.arg.requirements] Table 34 ([copyconstructible])
change as indicated <i>[Note: The symbol <tt>u</tt> is defined to be either a
const or a non-const value and is the right one we need here. The expressions
using <tt>a</tt> are recommended to ensure that lvalues are supported as sources
of the copy expression]</i>:
</p>

<blockquote>
<table border="1">
<caption>Table 34 � <tt>CopyConstructible</tt> requirements [copyconstructible]<br>
<ins>(in addition to <tt>MoveConstructible</tt>)</ins></caption>

<tbody><tr>
<th>Expression</th>
<th>Post-condition</th>
</tr>

<tr>
<td>
<tt>T <del>t</del><ins>u</ins>(<del>r</del>v)<ins>;</ins></tt>
</td>
<td>
the value of <tt><del>u</del><ins>v</ins></tt>
is unchanged and is equivalent to <tt><del>t</del><ins>u</ins></tt>
</td>
</tr>

<tr>
<td>
<ins><tt>T(v)</tt></ins>
</td>
<td><ins>the value of <tt>v</tt> is unchanged and is equivalent to <tt>T(v)</tt></ins>
</td>
</tr>

<tr>
<td colspan="2"><del>[<i>Note:</i> A type that satisfies the
<tt>CopyConstructible</tt> requirements also satisfies the <tt>MoveConstructible</tt>
requirements. � <i>end note</i>]</del></td>
</tr>

</tbody></table>
</blockquote>

</li>

<li>
<p>
In Table 35 � MoveAssignable requirements [moveassignable] change as
indicated:
</p>

<blockquote>

<table border="1">
<caption>Table 35 � <tt>MoveAssignable</tt> requirements <b>[moveassignable]</b></caption>
<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Return value</th>
<th>Post-condition</th>
</tr>
<tr>
<td>
<tt>t = rv</tt>
</td>
<td>
<tt>T&amp;</tt>
</td>
<td>
<tt>t</tt>
</td>
<td>
<tt>t</tt> is equivalent to the value of <tt>rv</tt> before the assigment.
</td>
</tr>
<tr>
<td colspan="4">
[<i>Note:</i>
<del>There is no requirement on the value of <tt>rv</tt> after the
assignment.</del>
<ins><tt>rv</tt> remains a valid object.  Its state is unspecified.</ins>
� <i>end note</i>]
</td>
</tr>
</tbody></table>

</blockquote>
</li>

<li>
<p>
In 20.2.1 [utility.arg.requirements] change Table 36 as indicated:
</p>

<blockquote>
<table border="1">
<caption>Table 36 � <tt>CopyAssignable</tt> requirements
[copyassignable]<br><ins>(in addition to <tt>MoveAssignable</tt>)</ins></caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Return value</th>
<th>Post-condition</th>
</tr>

<tr>
<td><tt>t = <del>u</del><ins>v</ins></tt></td>
<td><tt>T&amp;</tt></td>
<td><tt>t</tt></td>
<td><tt>t</tt> is equivalent to <tt><del>u</del><ins>v</ins></tt>, the value of
<tt><del>u</del><ins>v</ins></tt> is unchanged</td>
</tr>

<tr>
<td colspan="4"><del>[<i>Note:</i> A type that satisfies the <tt>CopyAssignable</tt>
requirements also satisfies the <tt>MoveAssignable</tt> requirements. �
<i>end note</i>]</del></td>
</tr>

</tbody></table>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="1312"></a>1312. <tt>vector::data</tt> no longer returns a raw pointer</h3>
<p><b>Section:</b> 23.4.1.3 [vector.data] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-02-07 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The original intent of <tt>vector::data</tt> was to match <tt>array::data</tt>
in providing a simple API with direct access to the contiguous buffer of
elements that could be passed to a "classic" C API.  At some point, the return
type became the '<tt>pointer</tt>' typedef, which is not derived from the
<tt>allocator</tt> via allocator traits - it is no longer specified to precisely
<tt>T *</tt>.  The return type of this function should be corrected to no longer
use the typedef.
</p>

<p><i>[
2010-02-10 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
23.4.1 [vector]
</p>

<p>
Update the class definition in p2:
</p>

<blockquote><pre>// 23.3.6.3 data access
<del>pointer</del><ins>T *</ins> data();
<del>const_pointer</del><ins>const T *</ins> data() const;
</pre></blockquote>

<p>
23.4.1.3 [vector.data]
</p>

<p>
Adjust signatures:
</p>

<blockquote><pre><del>pointer</del><ins>T *</ins> data();
<del>const_pointer</del><ins>const T *</ins> data() const;
</pre></blockquote>





<hr>
<h3><a name="1316"></a>1316. <tt>scoped_allocator_adaptor operator==</tt> has no definition</h3>
<p><b>Section:</b> 20.10 [allocator.adaptor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-02-11 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.adaptor">issues</a> in [allocator.adaptor].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The WP 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">N3000</a>)
contains these declarations:
</p>

<blockquote>
<pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
  bool operator==(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
                  const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);
template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
  bool operator!=(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
                  const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>
</blockquote>

<p>
But does not define what the behavior of these operators are.
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add a new section after 20.10.3 [allocator.adaptor.members]:
</p>

<blockquote>
<p><b>Scoped allocator operators  [scoped.adaptor.operators]</b></p>

<pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
  bool operator==(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
                  const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>

<blockquote>
<i>Returns:</i> <code>a.outer_allocator() == b.outer_allocator()</code>
if <code>sizeof...(InnerAllocs)</code> is zero; otherwise,
<code>a.outer_allocator() == b.outer_allocator() &amp;&amp;
a.inner_allocator() == b.inner_allocator()</code>.
</blockquote>

<pre>template &lt;class OuterA1, class OuterA2, class... InnerAllocs&gt;
  bool operator!=(const scoped_allocator_adaptor&lt;OuterA1, InnerAllocs...&gt;&amp; a,
                  const scoped_allocator_adaptor&lt;OuterA2, InnerAllocs...&gt;&amp; b);</pre>

<blockquote>
<i>Returns:</i> <code>!(a == b)</code>.
</blockquote>

</blockquote>






<hr>
<h3><a name="1319"></a>1319. Containers should require an iterator that is at least a Forward Iterator</h3>
<p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2010-02-16 <b>Last modified:</b> 2010-11-24</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements on container iterators are spelled out in
23.2.1 [container.requirements.general], table 91.
</p>

<blockquote>
<table border="1">
<caption>Table 91 � Container requirements</caption>

<tbody><tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational semantics</th>
<th>Assertion/note<br>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="5"><center>...</center></td>
</tr>

<tr>
<td><tt>X::iterator</tt></td>
<td>iterator type whose value type is <tt>T</tt></td>
<td></td>
<td>any iterator category except output iterator. Convertible to
<tt>X::const_iterator</tt>.</td>
<td>compile time</td>
</tr>

<tr>
<td><tt>X::const_iterator</tt></td>
<td>constant iterator type whose value type is <tt>T</tt></td>
<td></td>
<td>any iterator category except output iterator</td>
<td>compile time</td>
</tr>

<tr>
<td colspan="5"><center>...</center></td>
</tr>

</tbody></table>
</blockquote>

<p>
As input iterators do not have the multi-pass guarantee, they are not suitable
for iterating over a container.  For example, taking two calls to
<tt>begin()</tt>, incrementing either iterator might invalidate the other. 
While data structures might be imagined where this behaviour produces
interesting and useful results, it is very unlikely to meet the full set of
requirements for a standard container.
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<p>
Daniel notes: I changed the currently suggested P/R slightly, because it is not robust in regard to new fundamental iterator
catagories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward 
iterator requirements.
</p>

<blockquote>
Moved to Tentatively Ready with revised wording after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li>Change Table 93 � Container requirements in [container.requirements.general] as indicated:
<blockquote>
<table border="1">
<caption>Table 93 � Container requirements</caption>

<tbody>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Operational<br>semantics</th>
<th>Assertion/note<br>pre-/post-condition</th>
<th>Complexity</th>
</tr>

<tr>
<td colspan="5" align="center"><tt>...</tt></td>
</tr>

<tr>
<td><tt>X::iterator</tt></td>
<td>iterator type<br>whose value<br>type is <tt>T</tt></td>
<td></td>
<td>any iterator category<br><del>except output iterator</del><ins><br>that meets the forward iterator requirements</ins>. convertible<br>to<br><tt>X::const_iterator</tt></td>
<td>compile time</td>
</tr>

<tr>
<td><tt>X::const_iterator</tt></td>
<td>constant iterator type<br>whose value<br>type is <tt>T</tt></td>
<td></td>
<td>any iterator category<br><del>except output iterator</del><ins><br>that meets the forward iterator requirements</ins>.</td>
<td>compile time</td>
</tr>

<tr>
<td colspan="5" align="center"><tt>...</tt></td>
</tr>

</tbody></table>
</blockquote>

</li>
</ol>






<hr>
<h3><a name="1321"></a>1321. <tt>scoped_allocator_adaptor construct</tt> and <tt>destroy</tt> don't
use <tt>allocator_traits</tt></h3>
<p><b>Section:</b> 20.10.3 [allocator.adaptor.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-02-16 <b>Last modified:</b> 2010-11-20</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.10.3 [allocator.adaptor.members] p8-9 says:
</p>

<blockquote>

<pre>template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
8 <i>Effects:</i> let <tt><i>OUTERMOST</i>(x)</tt> be <tt>x</tt> if <tt>x</tt>
does not have an <tt>outer_allocator()</tt> function and
<tt><i>OUTERMOST</i>(x.outer_allocator())</tt> otherwise.
</p>

<ul>
<li>
If <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
<tt>false</tt> and <tt>is_constructible&lt;T, Args...&gt;::value</tt> is
<tt>true</tt>, calls <tt><i>OUTERMOST</i>(*this).construct(p,
std::forward&lt;Args&gt;(args)...)</tt>.
</li>

<li>
Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
<tt>true</tt> and <tt>is_constructible&lt;T, allocator_arg_t,
inner_allocator_type, Args...&gt;::value</tt> is <tt>true</tt>, calls
<tt><i>OUTERMOST</i>(*this).construct(p, allocator_arg,
inner_allocator(),std::forward&lt;Args&gt;(args)...)</tt>.
</li>

<li>
Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
<tt>true</tt> and <tt>is_constructible&lt;T, Args...,
inner_allocator_type&gt;::value</tt> is <tt>true</tt>, calls
<tt><i>OUTERMOST</i>(*this).construct(p, std::forward&lt;Args&gt;(args)...,
inner_allocator())</tt>.
</li>

<li>
Otherwise, the program is ill-formed. [<i>Note:</i> an error will result if
<tt>uses_allocator</tt> evaluates to <tt>true</tt> but the specific constructor
does not take an allocator. This definition prevents a silent failure to pass an
inner allocator to a contained element. � <i>end note</i>]
</li>
</ul>

</blockquote>

<pre>template &lt;class T&gt;
  void destroy(T* p);
</pre>
<blockquote>
9 <i>Effects:</i> calls <tt>outer_allocator().destroy(p)</tt>.
</blockquote>

</blockquote>

<p>
In all other calls where applicable <tt>scoped_allocator_adaptor</tt> does not
call members of an allocator directly, but rather does so indirectly via
<tt>allocator_traits</tt>.  For example:
</p>

<blockquote>
<pre>size_type max_size() const;
</pre>
<blockquote>
7 <i>Returns:</i>
<tt><b>allocator_traits&lt;OuterAlloc&gt;::</b>max_size(outer_allocator())</tt>.
</blockquote>
</blockquote>

<p>
Indeed, without the indirection through <tt>allocator_traits</tt> the
definitions for <tt>construct</tt> and <tt>destroy</tt> are likely to fail at
compile time since the <tt>outer_allocator()</tt> may not have the members
<tt>construct</tt> and <tt>destroy</tt>.
</p>

<p><i>[
The proposed wording is a product of Pablo, Daniel and Howard.
]</i></p>


<p><i>[
2010 Pittsburgh:  Moved to NAD Editorial.  Rationale added below.
]</i></p>




<p><b>Rationale:</b></p>
<p>
Solved by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3059.pdf">N3059</a>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
In 20.10.3 [allocator.adaptor.members] move and change p8
as indicated, and change p9 as indicated:
</p>

<blockquote>

<p>
<ins>Let <tt><i>OUTERMOST(x)</i></tt> be <tt><i>x</i></tt> if <tt><i>x</i></tt>
does not have an <tt>outer_allocator()</tt> <ins>member</ins> function and
<tt><i>OUTERMOST(x.outer_allocator())</i></tt> otherwise. Let
<tt><i>OUTERMOST_ALLOC_TRAITS(x)</i></tt> be
<tt>allocator_traits&lt;decltype(<i>OUTERMOST(x)</i>)&gt;</tt>.
[<i>Note:</i> <tt><i>OUTERMOST(x)</i></tt> and
<tt><i>OUTERMOST_ALLOC_TRAITS(x)</i></tt> are recursive operations.  It is
incumbent upon the definition of <tt>outer_allocator()</tt> to ensure that the
recursion terminates.  It <em>will</em> terminate for all instantiations
of <tt>scoped_allocator_adaptor</tt>. � <i>end note</i>]
</ins>
</p>

<pre>template &lt;class T, class... Args&gt;
  void construct(T* p, Args&amp;&amp;... args);
</pre>
<blockquote>

<p>
8 <i>Effects:</i> <del>let <tt><i>OUTERMOST(x)</i></tt> be <tt><i>x</i></tt> if
<tt><i>x</i></tt> does not have an <tt>outer_allocator()</tt> function and
<tt><i>OUTERMOST(x.outer_allocator())</i></tt> otherwise.</del>
</p>

<ul>
<li>
If <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
<tt>false</tt> and <tt>is_constructible&lt;T, Args...&gt;::value</tt> is
<tt>true</tt>, calls <tt><del><i>OUTERMOST(*this)</i>.</del>
<ins><i>OUTERMOST_ALLOC_TRAITS(outer_allocator())</i>::</ins>construct(
<ins><i>OUTERMOST(outer_allocator())</i>,</ins> p,
std::forward&lt;Args&gt;(args)... )</tt>.
</li>

<li>
Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
<tt>true</tt> and <tt>is_constructible&lt;T, allocator_arg_t,
inner_allocator_type, Args...&gt;::value</tt> is <tt>true</tt>, calls
<tt><del><i>OUTERMOST(*this)</i>.</del>
<ins><i>OUTERMOST_ALLOC_TRAITS(outer_allocator())</i>::</ins>construct(
<ins><i>OUTERMOST(outer_allocator())</i>,</ins> p, allocator_arg,
inner_allocator(), std::forward&lt;Args&gt;(args)... )</tt>.
</li>

<li>
Otherwise, if <tt>uses_allocator&lt;T, inner_allocator_type&gt;::value</tt> is
<tt>true</tt> and <tt>is_constructible&lt;T, Args...,
inner_allocator_type&gt;::value</tt> is <tt>true</tt>, calls
<tt><del><i>OUTERMOST(*this)</i>.</del>
<ins><i>OUTERMOST_ALLOC_TRAITS(outer_allocator())</i>::</ins>construct(
<ins><i>OUTERMOST(outer_allocator())</i>,</ins> p,
std::forward&lt;Args&gt;(args)..., inner_allocator() )</tt>.
</li>

<li>
Otherwise, the program is ill-formed. [<i>Note:</i> an error will result if
<tt>uses_allocator</tt> evaluates to <tt>true</tt> but the specific constructor
does not take an allocator. This definition prevents a silent failure to pass an
inner allocator to a contained element. � <i>end note</i>]
</li>
</ul>

</blockquote>

<pre>template &lt;class T&gt;
  void destroy(T* p);
</pre>
<blockquote>
9 <i>Effects:</i> calls <tt><del>outer_allocator().</del>
<ins><i>OUTERMOST_ALLOC_TRAITS(outer_allocator())</i>::</ins>destroy(
<ins><i>OUTERMOST(outer_allocator())</i>,</ins> p)</tt>.
</blockquote>

</blockquote>






<hr>
<h3><a name="1322"></a>1322. Explicit <tt>CopyConstructible</tt> requirements are insufficient</h3>
<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-02-16 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
With the acceptance of library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#822">822</a> only
direct-initialization is supported, and not copy-initialization in the
requirement sets <tt>MoveConstructible</tt> and <tt>CopyConstructible</tt>. This
is usually a good thing, if only the library implementation needs to obey these
restrictions, but the Empire strikes back quickly:
</p>

<ol>
<li>
<p>
<em>Affects user-code</em>: <tt>std::exception_ptr</tt> is defined purely via
requirements, among them <tt>CopyConstructible</tt>. A strict reading of the
standard would make implementations conforming where <tt>std::exception_ptr</tt>
has an explicit copy-c'tor and user-code must code defensively. This is a very
unwanted effect for such an important component like
<tt>std::exception_ptr</tt>.
</p>
</li>

<li>
<p>
<em>Wrong re-use</em>: Recently proposed requirement sets
(<tt>NullablePointer</tt> as of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3025.html">N3025</a>,
Hash) or cleanup of existing requirement sets (e.g. iterator requirements as of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3046.html">N3046</a>)
tend to reuse existing requirement sets, so reusing <tt>CopyConstructible</tt>
is attempting, even in cases, where the intend is to support copy-initialization
as well.
</p>
</li>

<li>
<p>
<em>Inconsistency</em>: The current iterator requirements set Table 102 (output
iterator requirements) and Table 103 (forward iterator requirements) demonstrate
quite clearly a strong divergence of copy-semantics: The specified semantics of
</p>

<blockquote><pre>X u(a);
X u = a;
</pre></blockquote>

<p>
are underspecified compared to the most recent clarifications of the
<tt>CopyConstructible</tt> requirements, c.f. issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1309">1309</a> which is
very unsatisfactory. This will become worse for each further issue that involves
the <tt>CopyConstructible</tt> specification (for possible directions see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1173">1173</a>).
</p>
</li>
</ol>

<p>
The suggested resolution is to define two further requirements
<tt>implicit-MoveConstructible</tt> and <tt>implicit-CopyConstructible</tt> (or
any other reasonable name like <tt>MoveConvertible</tt> and
<tt>CopyConvertible</tt>) each with a very succinct but precise meaning solving
all three problems mentioned above.
</p>

<p><i>[Batavia: Resolved by accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3215.html">n3215</a>.]</i></p>







<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Add the following new table ?? after Table 34 � <tt>MoveConstructible</tt>
requirements [moveconstructible]:
</p>

<blockquote>

<table border="1">
<caption><ins>Table ?? � <tt>Implicit MoveConstructible</tt> requirements
[implicit.moveconstructible] (in addition to
<tt>MoveConstructible</tt>)</ins></caption>

<tbody><tr>
<th><ins>Expression</ins></th>
<th><ins>Operational Semantics</ins></th>
</tr>

<tr>
<td><ins><tt>T u = rv;</tt></ins></td>
<td><ins>Equivalent to: <tt>T u(rv);</tt></ins></td>
</tr>

</tbody></table>
</blockquote>

</li>

<li>
<p>
Add the following new table ?? after Table 35 � <tt>CopyConstructible</tt>
requirements [copyconstructible]:
</p>

<blockquote>

<table border="1">
<caption><ins>Table ?? � <tt>Implicit CopyConstructible</tt> requirements
[implicit.copyconstructible] (in addition to
<tt>CopyConstructible</tt>)</ins></caption>

<tbody><tr>
<th><ins>Expression</ins></th>
<th><ins>Operational Semantics</ins></th>
</tr>

<tr>
<td><ins><tt>T u = v;</tt></ins></td>
<td><ins>Equivalent to: <tt>T u(v);</tt></ins></td>
</tr>

</tbody></table>
</blockquote>

</li>

<li>
<p>
Change 20.2.3 [nullablepointer.requirements]/1 as follows:
</p>

<blockquote>
<p>
A <tt>NullablePointer</tt> type is a pointer-like type that supports null
values. A type <tt>P</tt> meets the requirements of <tt>NullablePointer</tt> if:
</p>

<ul>
<li>
<tt>P</tt> satisfies the requirements of <tt>EqualityComparable</tt>,
<tt>DefaultConstructible</tt>, <tt><ins>implicit</ins> CopyConstructible</tt>,
<tt>CopyAssignable</tt>, and <tt>Destructible</tt>,
</li>

<li>[..]</li>
</ul>
</blockquote>
</li>

<li>
<p>
Change 20.2.4 [hash.requirements]/1 as indicated: <i>[explicit
copy-constructible functors could not be provided as arguments
to any algorithm that takes these by value. Also a typo is fixed.]</i>
</p>

<blockquote>
<p>
1 A type <tt>H</tt> meets the <i>Hash</i> requirements if:
</p>
<ul>
<li>
it is a function object type (20.8),
</li>
<li>
it satis<ins>fies</ins><del>ifes</del> the requirements of
<tt><ins>implicit</ins> CopyConstructible</tt> and <tt>Destructible</tt>
(20.2.1),
</li>
<li>
[..]
</li>
</ul>

</blockquote>

</li>

<li>
<p>
Change 20.7.1 [meta.rqmts]/1+2 as indicated:
</p>

<blockquote>
<p>
1 A <i>UnaryTypeTrait</i> describes a property of a type. It shall be a class
template that takes one template type argument and, optionally, additional
arguments that help define the property being described. It shall be
<tt>DefaultConstructible</tt>, <tt><ins>implicit</ins> CopyConstructible</tt>,
[..]
</p>

<p>
2 A <tt>BinaryTypeTrait</tt> describes a relationship between two types. It
shall be a class template that takes two template type arguments and,
optionally, additional arguments that help define the relationship being
described. It shall be <tt>DefaultConstructible</tt>,
<tt><ins>implicit </ins>CopyConstructible</tt>, and [..]
</p>

</blockquote>

</li>

<li>
<p>
Change 20.8.2 [func.require]/4 as indicated: <i>[explicit
copy-constructible functors could not be provided as arguments to any algorithm
that takes these by value]</i>
</p>

<blockquote>
4 Every call wrapper (20.8.1) shall be <tt><ins>implicit</ins>
MoveConstructible</tt>. A simple call wrapper is a call wrapper that is
<tt><ins>implicit</ins> CopyConstructible</tt> and <tt>CopyAssignable</tt> and
whose copy constructor, move constructor, and assignment operator do not throw
exceptions. [..]
</blockquote>
</li>

<li>
<p>
Change 20.8.4 [refwrap]/1 as indicated:
</p>

<blockquote>
1 <tt>reference_wrapper&lt;T&gt;</tt> is a<ins>n <tt>implicit</tt></ins>
<tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> wrapper around a
reference to an object or function of type <tt>T</tt>.
</blockquote>
</li>

<li>
<p>
Change 20.8.10.1.2 [func.bind.bind]/5+9 as indicated:
</p>

<blockquote>
<p>
5 <i>Remarks:</i> The return type shall satisfy the requirements of
<tt><ins>implicit</ins> MoveConstructible</tt>. If all of <tt>FD</tt> and
<tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt>, then the
return type shall satisfy the requirements of <tt><ins>implicit</ins>
CopyConstructible</tt>. [<i>Note:</i> this implies that all of <tt>FD</tt> and
<tt>TiD</tt> are <tt>MoveConstructible</tt>. � <i>end note</i>]
</p>

<p>
[..]
</p>

<p>
9 <i>Remarks:</i> The return type shall satisfy the requirements of
<tt><ins>implicit</ins> MoveConstructible</tt>. If all of <tt>FD</tt> and
<tt>TiD</tt> satisfy the requirements of <tt>CopyConstructible</tt>, then the
return type shall satisfy the requirements of <tt><ins>implicit</ins>
CopyConstructible</tt>. [<i>Note:</i> this implies that all of <tt>FD</tt> and
<tt>TiD</tt> are <tt>MoveConstructible</tt>. � <i>end note</i>]
</p>
</blockquote>

</li>

<li>
<p>
Change 20.8.10.1.3 [func.bind.place] as indicated:
</p>

<blockquote>
1 All placeholder types shall be <tt>DefaultConstructible</tt> and
<tt><ins>implicit</ins> CopyConstructible</tt>, and [..]
</blockquote>
</li>

<li>
<p>
Change 20.9.9 [unique.ptr]/5 as indicated:
</p>

<blockquote>
5 Each object of a type <tt>U</tt> instantiated form the <tt>unique_ptr</tt>
template specified in this subclause has the strict ownership semantics,
specified above, of a unique pointer. In partial satisfaction of these
semantics, each such <tt>U</tt> is <tt><ins>implicit</ins>
MoveConstructible</tt> and <tt>MoveAssignable</tt>, but is not
<tt>CopyConstructible</tt> nor <tt>CopyAssignable</tt>. The template parameter
<tt>T</tt> of <tt>unique_ptr</tt> may be an incomplete type.
</blockquote>
</li>

<li>
<p>
Change 20.9.10.2 [util.smartptr.shared]/2 as indicated:
</p>

<blockquote>
2 Specializations of <tt>shared_ptr</tt> shall be
<tt><ins>implicit</ins> CopyConstructible</tt>, <tt>CopyAssignable</tt>, and
<tt>LessThanComparable</tt>, [..]
</blockquote>
</li>

<li>
<p>
Change 20.9.10.3 [util.smartptr.weak]/2 as indicated:
</p>

<blockquote>
2 Specializations of <tt>weak_ptr</tt> shall be <tt><ins>implicit</ins>
CopyConstructible</tt> and <tt>CopyAssignable</tt>, allowing their use in
standard containers. The template parameter <tt>T</tt> of <tt>weak_ptr</tt> may
be an incomplete type.
</blockquote>
</li>

<li>
<p>
Change 24.2.2 [iterator.iterators]/2 as indicated: <i>[This fixes a
defect in the Iterator requirements. None of the usual algorithms accepting
iterators would be usable with iterators with explicit copy-constructors]</i>
</p>

<blockquote>
<p>
2 A type <tt>X</tt> satisfies the Iterator requirements if:
</p>

<ul>
<li>
<tt>X</tt> satisfies the <tt><ins>implicit</ins> CopyConstructible</tt>,
<tt>CopyAssignable</tt>, and <tt>Destructible</tt> requirements (20.2.1)
and lvalues of type <tt>X</tt> are swappable (20.2.2), and [..]
</li>
<li>...</li>
</ul>

</blockquote>

</li>

<li>
<p>
Change D.12.1 [auto.ptr]/3 as indicated:
</p>

<blockquote>
3 [..] Instances of <tt>auto_ptr</tt> meet the requirements of
<tt><ins>implicit</ins> MoveConstructible</tt> and <tt>MoveAssignable</tt>, but
do not meet the requirements of <tt>CopyConstructible</tt> and
<tt>CopyAssignable</tt>. � <i>end note</i>]
</blockquote>
</li>

</ol>






<hr>
<h3><a name="1323"></a>1323. <tt>basic_string::replace</tt> should use <tt>const_iterator</tt></h3>
<p><b>Section:</b> 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-02-19 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::replace">issues</a> in [string::replace].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>
In contrast to all library usages of purely positional iterator values several
overloads of <tt>std::basic_string::replace</tt> still use iterator instead of
<tt>const_iterator</tt> arguments. The paper
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3021.pdf">N3021</a>
quite nicely visualizes the purely positional responsibilities of the function
arguments.
</p>

<p>
This should be fixed to make the library consistent, the proposed changes are
quite mechanic.
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>

<li>
<p>
In 21.4 [basic.string], class template <tt>basic_string</tt> synopsis
change as indicated:
</p>

<blockquote><pre>// 21.4.6 modifiers:
...
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      const basic_string&amp; str);
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      const charT* s, size_type n);
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      const charT* s);
basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      size_type n, charT c);
template&lt;class InputIterator&gt;
  basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                        InputIterator j1, InputIterator j2);
basic_string&amp; replace(<ins>const_</ins>iterator, <ins>const_</ins>iterator,
                      initializer_list&lt;charT&gt;);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.18, change the following signatures
as indicated:
</p>

<blockquote><pre>basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const basic_string&amp; str);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.21, change the following signatures
as indicated:
</p>

<blockquote><pre>basic_string&amp;
  replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const charT* s, size_type n);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.24, change the following signatures
as indicated:
</p>

<blockquote><pre>basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, const charT* s);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.27, change the following signatures
as indicated:
</p>

<blockquote><pre>basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2, size_type n,
                      charT c);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.30, change the following signatures
as indicated:
</p>

<blockquote><pre>template&lt;class InputIterator&gt;
  basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                        InputIterator j1, InputIterator j2);
</pre></blockquote>
</li>

<li>
<p>
In 21.4.6.6 [string::replace] before p.33, change the following signatures
as indicated:
</p>

<blockquote><pre>basic_string&amp; replace(<ins>const_</ins>iterator i1, <ins>const_</ins>iterator i2,
                      initializer_list&lt;charT&gt; il);
</pre></blockquote>
</li>

</ol>






<hr>
<h3><a name="1324"></a>1324. Still too many implicit conversions for <tt>pair</tt> and  <tt>tuple</tt></h3>
<p><b>Section:</b> 20.3.5.2 [pairs.pair], 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-03-20 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In analogy to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#811">811</a>, <tt>tuple</tt>'s variadic
constructor
</p>

<blockquote><pre>template &lt;class... UTypes&gt;
explicit tuple(UTypes&amp;&amp;... u);
</pre></blockquote>

<p>
creates the same problem as pair:
</p>

<blockquote><pre>#include &lt;tuple&gt;

int main()
{
  std::tuple&lt;char*&gt; p(0);
}
</pre></blockquote>

<p>
produces a similar compile error for a recent gcc implementation.
</p>

<p>
I suggest to follow the same resolution path as has been applied to
<tt>pair</tt>'s corresponding c'tor, that is require that these c'tors should
not participate in overload resolution, if the arguments are not implicitly
convertible to the element types.
</p>

<p>
Further-on both <tt>pair</tt> and <tt>tuple</tt> provide converting constructors
from different <tt>pairs</tt>/<tt>tuples</tt> that should be not available, if
the corresponding element types are not implicitly convertible. It seems
astonishing that in the following example
</p>

<blockquote><pre>struct A {
  explicit A(int);
};

A  a = 1; <font color="#C80000">// Error</font>

std::tuple&lt;A&gt; ta = std::make_tuple(1); <font color="#C80000">// # OK?</font>
</pre></blockquote>

<p>
the initialization marked with # could be well-formed.
</p>

<p><i>[
Only constraints on constructors are suggested. Adding similar constraints on
assignment operators is considered as QoI, because the assigments wouldn't be
well-formed anyway.
]</i></p>


<ol>

<li>
<p>
Following 20.3.5.2 [pairs.pair]/5 add a new Remarks element:
</p>

<blockquote><pre>template&lt;class U, class V&gt; pair(const pair&lt;U, V&gt;&amp; p);
</pre>

<blockquote>
<p>
5 <i>Effects:</i> Initializes members from the corresponding members of the
argument<del>, performing implicit conversions as needed</del>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>U</tt> is implicitly convertible to <tt>first_type</tt>
and <tt>V</tt> is implicitly convertible to <tt>second_type</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>

<li>
<p>
Following 20.3.5.2 [pairs.pair]/6 add a new Remarks element:
</p>

<blockquote><pre>template&lt;class U, class V&gt; pair(pair&lt;U, V&gt;&amp;&amp; p);
</pre>

<blockquote>
<p>
6 <i>Effects:</i> The constructor initializes <tt>first</tt> with
<tt>std::move(p.first)</tt> and second with <tt>std::move(p.second)</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>U</tt> is implicitly convertible to <tt>first_type</tt>
and <tt>V</tt> is implicitly convertible to <tt>second_type</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/7 add a new Remarks element:
</p>

<blockquote><pre>template &lt;class... UTypes&gt;
explicit tuple(UTypes&amp;&amp;... u);
</pre>

<blockquote>
<p>
6 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the requirements of
<tt>MoveConstructible</tt> (Table 33) from the corresponding type in
<tt>UTypes</tt>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
</p>

<p>
7 <i>Effects:</i> Initializes the elements in the <tt>tuple</tt> with the
corresponding value in <tt>std::forward&lt;UTypes&gt;(u)</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
corresponding type in <tt>Types</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/13 add a new Remarks element:
</p>

<blockquote><pre>template &lt;class... UTypes&gt; tuple(const tuple&lt;UTypes...&gt;&amp; u);
</pre>

<blockquote>
<p>
12 <i>Requires:</i> Each type in <tt>Types</tt> shall be constructible from the
corresponding type in <tt>UTypes</tt>. <tt>sizeof...(Types) ==
sizeof...(UTypes)</tt>.
</p>

<p>
13 <i>Effects:</i> Constructs each element of <tt>*this</tt> with the
corresponding element of <tt>u</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
corresponding type in <tt>Types</tt>.</ins>
</p>

<p>
14 [<i>Note:</i> <tt>enable_if</tt> can be used to make the converting
constructor and assignment operator exist only in the cases where the source and
target have the same number of elements. � <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/16 add a new Remarks element:
</p>

<blockquote><pre>template &lt;class... UTypes&gt; tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
15 <i>Requires:</i> Each type in <tt>Types</tt> shall shall satisfy the
requirements of <tt>MoveConstructible</tt> (Table 33) from the corresponding
type in <tt>UTypes</tt>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
</p>

<p>
16 <i>Effects:</i> Move-constructs each element of <tt>*this</tt> with the
corresponding element of <tt>u</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless each type in <tt>UTypes</tt> is implicitly convertible to its
corresponding type in <tt>Types</tt>.</ins>
</p>

<p>
[<i>Note:</i> <tt>enable_if</tt> can be used to make the converting constructor
and assignment operator exist only in the cases where the source and target have
the same number of elements. � <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/18 add a new Remarks element:
</p>

<blockquote><pre>template &lt;class U1, class U2&gt; tuple(const pair&lt;U1, U2&gt;&amp; u);
</pre>

<blockquote>
<p>
17 <i>Requires:</i> The first type in <tt>Types</tt> shall be constructible from
<tt>U1</tt> and the second type in <tt>Types</tt> shall be constructible from
<tt>U2</tt>. <tt>sizeof...(Types) == 2</tt>.
</p>

<p>
18 <i>Effects:</i> Constructs the first element with <tt>u.first</tt> and the
second element with <tt>u.second</tt>.
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>U1</tt> is implicitly convertible to the first type in
<tt>Types</tt> and <tt>U2</tt> is implicitly convertible to the second type in
<tt>Types</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Following 20.4.2.1 [tuple.cnstr]/20 add a new Remarks element:
</p>

<blockquote><pre>template &lt;class U1, class U2&gt; tuple(pair&lt;U1, U2&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
19 <i>Requires:</i> The first type in <tt>Types</tt> shall shall satisfy the
requirements of <tt>MoveConstructible</tt>(Table 33) from <tt>U1</tt> and the
second type in <tt>Types</tt> shall be move-constructible from <tt>U2</tt>.
<tt>sizeof...(Types) == 2</tt>.
</p>

<p>
20 <i>Effects:</i> Constructs the first element with <tt>std::move(u.first)</tt>
and the second element with <tt>std::move(u.second)</tt>
</p>

<p>
<ins><i>Remarks:</i> This constructor shall not participate in overload
resolution unless <tt>U1</tt> is implicitly convertible to the first type in
<tt>Types</tt> and <tt>U2</tt> is implicitly convertible to the second type in
<tt>Types</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

</ol>
<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
</blockquote>


<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.






<hr>
<h3><a name="1325"></a>1325. bitset</h3>
<p><b>Section:</b> 20.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Christopher Jefferson <b>Opened:</b> 2010-03-07 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As mentioned on the boost mailing list:
</p>

<p>
The following code, valid in C++03, is broken in C++0x due to ambiguity
between the "<tt>unsigned long long</tt>" and "<tt>char*</tt>"
constructors.
</p>

<blockquote><pre>#include &lt;bitset&gt;
std::bitset&lt;10&gt; b(0);
</pre></blockquote>

<p><i>[
The proposed resolution has been reviewed by Stephan T. Lavavej.
]</i></p>


<p><i>[
Post-Rapperswil
]</i></p>


<p>
The proposed resolution has two problems:
</p>
<ul>
<li>
<p>it fails to provide support for non-terminated strings, which
could be easily added and constitutes an important use-case. For
example, the following code would invoke UB with the current
P/R:</p>
<blockquote>
<pre>char s[4] = { '0', '1', '0', '1' }; // notice: not null-terminated!
bitset&lt;4&gt; b(s, 0, 4);
</pre></blockquote>
because it requires the evaluation (under the as-if rule, to be fair,
but it doesn't matter) of <tt>basic_string&lt;char&gt;(s)</tt>
</li>
<li>
<p>it promotes a consistency between the two <tt>bitset</tt>
constructors that take a <tt>const std::string&amp;</tt> and a
<tt>const char*</tt>, respectively, while practice established by
<tt>std::basic_string</tt> would recommend a different set of
parameters. In particular, the constructor of
<tt>std::basic_string</tt> that takes a <tt>const char*</tt> does
not have a <tt>pos</tt> parameter</p>
</li>
</ul>

<blockquote>
Moved to Tentatively Ready with revised wording provided by Alberto Ganesh Babati after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>


<ol>
<li>In the synopsis of header <tt>&lt;bitset&gt;</tt> in
20.5 [template.bitset]/1, replace the fourth bitset constructor:
<blockquote>
<pre><del>explicit bitset(const char *str);</del>
<ins>template &lt;class charT&gt;
  explicit bitset(
    const charT *str,
    typename basic_string&lt;charT&gt;::size_type n = basic_string&lt;charT&gt;::npos,
    charT zero = charT('0'), charT one = charT('1'));</ins>
</pre></blockquote>
</li>
<li>In 20.5.1 [bitset.cons]/8:
<blockquote>
<pre><del>explicit bitset(const char *str);</del>
<ins>template &lt;class charT&gt;
explicit
bitset(const charT *str,
       typename basic_string&lt;charT&gt;::size_type n = basic_string&lt;charT&gt;::npos,
       charT zero = charT('0'), charT one = charT('1'));</ins>
</pre></blockquote>
Effects: Constructs an object of class
<tt>bitset&lt;N&gt;</tt> as if by
<del>bitset(string(str)).</del>
<blockquote><pre><ins>
bitset(
  n == basic_string&lt;charT&gt;::npos
    ? basic_string&lt;charT&gt;(str)
    : basic_string&lt;charT&gt;(str, n),
  0, n, zero, one)
</ins></pre></blockquote>
</li>
</ol>






<hr>
<h3><a name="1326"></a>1326. Missing/wrong preconditions for <tt>pair</tt> and <tt>tuple</tt> functions</h3>
<p><b>Section:</b> 20.3.5.2 [pairs.pair], 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-03-07 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are several constructors and creation functions of std::tuple
that impose requirements on it's arguments, that are unnecessary
restrictive and don't match the intention for the supported argument
types. This is related to the fact that tuple is supposed to accept both
object types and lvalue-references and the usual MoveConstructible and
CopyConstructible requirements are bad descriptions for non-const
references. Some examples:
</p>

<ol type="a">
<li>
<p>
20.4.2.1 [tuple.cnstr] before p.4 and p.8, resp.:
</p>

<blockquote><pre>explicit tuple(const Types&amp;...);
</pre>
<blockquote>
4 <i>Requires:</i> Each type in <tt>Types</tt> shall be copy constructible.
</blockquote>

<pre>tuple(const tuple&amp; u) = default;
</pre>
<blockquote>
8 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the requirements of
<tt>CopyConstructible</tt> (Table 34).

</blockquote>
</blockquote>

<p>
A tuple that contains lvalue-references to non-const can never
satisfy the <tt>CopyConstructible</tt> requirements. <tt>CopyConstructible</tt>
requirements <i>refine</i> the <tt>MoveConstructible</tt> requirements and
this would require that these lvalue-references could bind
rvalues. But the core language does not allow that. Even, if we
would interpret that requirement as referring to the underlying
non-reference type, this requirement would be wrong as well,
because there is no reason to disallow a type such as
</p>

<blockquote><pre>struct NoMoveNoCopy {
  NoMoveNoCopy(NoMoveNoCopy&amp;&amp;) = delete;
  NoMoveNoCopy(const NoMoveNoCopy&amp;) = delete;
  ...
}:
</pre></blockquote>

<p>
for the instantiation of <tt>std::tuple&lt;NoMoveNoCopy&amp;&gt;</tt> and
that of it's copy constructor.
</p>

<p>
A more reasonable requirement for this example would be to require that
"<tt>is_constructible&lt;Ti, const Ti&amp;&gt;::value</tt> shall
evaluate to true for all <tt>Ti</tt> in <tt>Types</tt>". In this case
the special reference-folding and const-merging rules of references
would make this well-formed in all cases. We could also add the further
constraint "if <tt>Ti</tt> is an object type, it shall satisfy the
<tt>CopyConstructible</tt> requirements", but this additional
requirement seems not really to help here. Ignoring it would only mean
that if a user would provide a curious object type <tt>C</tt> that
satisfies the <tt>std::is_constructible&lt;C, const C&amp;&gt;</tt>
test, but not the "<tt>C</tt> is <tt>CopyConstructible</tt>" test would
produce a <tt>tuple&lt;C&gt;</tt> that does not satisfy the
<tt>CopyConstructible</tt> requirements as well.
</p>
</li>

<li>
<p>
20.4.2.1 [tuple.cnstr] before p.6 and p.10, resp.:
</p>

<blockquote><pre>template &lt;class... UTypes&gt;
explicit tuple(UTypes&amp;&amp;... u);
</pre>

<blockquote>
6 <i>Requires:</i> Each type in <tt>Types</tt> shall satisfy the
requirements of <tt>MoveConstructible</tt> (Table 33) from the
corresponding type in <tt>UTypes</tt>. <tt>sizeof...(Types) ==
sizeof...(UTypes)</tt>.
</blockquote>

<pre>tuple(tuple&amp;&amp; u);
</pre>
<blockquote>
10 <i>Requires:</i> Each <tt>type</tt> in <tt>Types</tt> shall shall
satisfy the requirements of <tt>MoveConstructible</tt> (Table 33).
</blockquote>
</blockquote>

<p>
We have a similar problem as in (a): Non-const lvalue-references
are intended template arguments for <tt>std::tuple</tt>, but cannot satisfy
the <tt>MoveConstructible</tt> requirements. In this case the correct
requirements would be
</p>

<blockquote>
<tt>is_constructible&lt;Ti, Ui&gt;::value</tt> shall evaluate to true
for all <tt>Ti</tt> in <tt>Types</tt> and for all <tt>Ui</tt> in
<tt>UTypes</tt>
</blockquote>

<p>
and
</p>

<blockquote>
<tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall evaluate to true
for all <tt>Ti</tt> in <tt>Types</tt>
</blockquote>

<p>
respectively.
</p>
</li>
</ol>

<p>
Many <tt>std::pair</tt> member functions do not add proper requirements, e.g.
the default c'tor does not require anything. This is corrected within the
suggested resolution. Further-on the P/R has been adapted to the FCD numbering.
</p>

<p><i>[
2010-03-25 Daniel updated wording:
]</i></p>


<blockquote>
The issue became updated to fix some minor inconsistencies and to ensure a
similarly required fix for <tt>std::pair</tt>, which has the same specification
problem as <tt>std::tuple</tt>, since <tt>pair</tt> became extended to support
reference members as well.
</blockquote>

<p><i>[Original proposed resolution:]</i></p>

<ol>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/1 as indicated <i>[The changes for the effects
elements are not normative changes, they just ensure
harmonization with existing wording style]</i>:
</p>

<blockquote><pre>constexpr pair();
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>first_type</tt> and <tt>second_type</tt> shall satisfy
the <tt>DefaultConstructible</tt> requirements.</ins>
</p>

<p>
1 <i>Effects:</i> <ins>Value-initializes <tt>first</tt> and
<tt>second</tt>.</ins><del>Initializes its members as if implemented: <tt>pair()
: first(), second() { }</tt>.</del>
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/2 as indicated:
</p>

<blockquote><pre>pair(const T1&amp; x, const T2&amp; y);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>is_constructible&lt;T1, const T1&amp;&gt;::value</tt>
is <tt>true</tt> and <tt>is_constructible&lt;T2, const T2&amp;&gt;::value</tt>
is <tt>true</tt>.</ins>
</p>

<p>
2 <i>Effects:</i> The constructor initializes <tt>first</tt> with <tt>x</tt> and
<tt>second</tt> with <tt>y</tt>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/3 as indicated:
</p>

<blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>is_constructible&lt;first_type, U&gt;::value</tt> is
<tt>true</tt> and <tt>is_constructible&lt;second_type, V&gt;::value</tt> is
<tt>true</tt>.</ins>
</p>

<p>
3 <i>Effects:</i> The constructor initializes <tt>first</tt> with
<tt>std::forward&lt;U&gt;(x)</tt> and <tt>second</tt> with
<tt>std::forward&lt;V&gt;(y)</tt>.
</p>

<p>
4 <i>Remarks:</i> If <tt>U</tt> is not implicitly convertible to
<tt>first_type</tt> or <tt>V</tt> is not implicitly convertible to
<tt>second_type</tt> this constructor shall not participate in overload
resolution.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/5 as indicated <i>[The change in the effects
element should be non-normatively and is in compatible to the change suggestion
of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1324">1324</a>]</i>:
</p>

<blockquote><pre>template&lt;class U, class V&gt; pair(const pair&lt;U, V&gt;&amp; p);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>is_constructible&lt;first_type, const
U&amp;&gt;::value</tt> is <tt>true</tt> and <tt>is_constructible&lt;second_type,
const V&amp;&gt;::value</tt> is <tt>true</tt>.</ins>
</p>

<p>
5 <i>Effects:</i> Initializes members from the corresponding members of the
argument<del>, performing implicit conversions as needed</del>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/6 as indicated:
</p>

<blockquote><pre>template&lt;class U, class V&gt; pair(pair&lt;U, V&gt;&amp;&amp; p);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>is_constructible&lt;first_type, U&gt;::value</tt> is
<tt>true</tt> and <tt>is_constructible&lt;second_type, V&gt;::value</tt> is
<tt>true</tt>.</ins>
</p>

<p>
6 <i>Effects:</i> The constructor initializes <tt>first</tt> with
<tt>std::<del>move</del><ins>forward&lt;U&gt;</ins>(p.first)</tt> and
<tt>second</tt> with
<tt>std::<del>move</del><ins>forward&lt;V&gt;</ins>(p.second)</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair]/7+8 as indicated [The deletion in the effects
element should be non-normatively]:
</p>

<blockquote><pre>template&lt;class... Args1, class... Args2&gt;
  pair(piecewise_construct_t,
       tuple&lt;Args1...&gt; first_args, tuple&lt;Args2...&gt; second_args);
</pre>

<blockquote>
<p>
7 <i>Requires:</i> <ins><tt>is_constructible&lt;first_type,
Args1...&gt;::value</tt> is <tt>true</tt> and
<tt>is_constructible&lt;second_type, Args2...&gt;::value</tt> is
<tt>true</tt>.</ins> <del>All the types in <tt>Args1</tt> and <tt>Args2</tt>
shall be <tt>CopyConstructible</tt> (Table 35). <tt>T1</tt> shall be
constructible from <tt>Args1</tt>. <tt>T2</tt> shall be constructible from
<tt>Args2</tt>.</del>
</p>

<p>
8 <i>Effects:</i> The constructor initializes <tt>first</tt> with arguments of
types <tt>Args1...</tt> obtained by forwarding the elements of
<tt>first_args</tt> and initializes <tt>second</tt> with arguments of types
<tt>Args2...</tt> obtained by forwarding the elements of <tt>second_args</tt>.
<del>(Here, forwarding an element <tt>x</tt> of type <tt>U</tt> within a
<tt>tuple</tt> object means calling <tt>std::forward&lt;U&gt;(x)</tt>.)</del>
This form of construction, whereby constructor arguments for <tt>first</tt> and
<tt>second</tt> are each provided in a separate <tt>tuple</tt> object, is called
piecewise construction.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.3.5.2 [pairs.pair] before 12 as indicated:
</p>

<blockquote><pre>pair&amp; operator=(pair&amp;&amp; p);
</pre>

<blockquote>
<p>
<ins><i>Requires:</i> <tt>first_type</tt> and <tt>second_type</tt> shall satisfy
the <tt>MoveAssignable</tt> requirements.</ins>
</p>

<p>
12 <i>Effects:</i> Assigns to <tt>first</tt> with <tt>std::move(p.first)</tt>
and to <tt>second</tt> with <tt>std::move(p.second)</tt>.
</p>

<p>
13 <i>Returns:</i> <tt>*this</tt>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change [pairs.pair] before 14 as indicated: [The heterogeneous usage
of MoveAssignable is actually not defined,
but the library uses it at several places, so we follow this tradition
until a better term has been agreed on. One
alternative could be to write "first_type shall be assignable from an
rvalue of U [..]"]
</p>

<blockquote><pre>template&lt;class U, class V&gt; pair&amp; operator=(pair&lt;U, V&gt;&amp;&amp; p);
</pre>

<blockquote>

<p>
<ins><i>Requires:</i> <tt>first_type</tt> shall be <tt>MoveAssignable</tt> from
<tt>U</tt> and <tt>second_type</tt> shall be <tt>MoveAssignable</tt> from
<tt>V</tt>.</ins>
</p>

<p>
14 <i>Effects:</i> Assigns to <tt>first</tt> with <tt>std::move(p.first)</tt>
and to <tt>second</tt> with <tt>std::move(p.second)</tt>.
</p>

<p>
15 <i>Returns:</i> <tt>*this</tt>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/4+5 as indicated:
</p>

<blockquote><pre>explicit tuple(const Types&amp;...);
</pre>

<blockquote>
<p>
4 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
Ti&amp;&gt;::value == true</tt> for e</ins><del>E</del>ach type
<ins><tt>Ti</tt></ins> in <tt>Types</tt><del> shall be copy
constructible</del>.
</p>

<p>
5 <i>Effects:</i> <del>Copy i</del><ins>I</ins>nitializes each element with the
value of the corresponding parameter.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/6 as indicated:
</p>

<blockquote><pre>template &lt;class... UTypes&gt;
explicit tuple(UTypes&amp;&amp;... u);
</pre>

<blockquote>
<p>
6 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, Ui&gt;::value ==
true</tt> for e</ins><del>E</del>ach type <ins><tt>Ti</tt></ins> in
<tt>Types</tt> <del>shall satisfy the requirements of
<tt>MoveConstructible</tt> (Table 33) from</del><ins>and for</ins> the
corresponding type <ins><tt>Ui</tt></ins> in <tt>UTypes</tt>.
<tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
</p>

<p>
7 <i>Effects:</i> Initializes the elements in the <tt>tuple</tt> with the
corresponding value in <tt>std::forward&lt;UTypes&gt;(u)</tt>.
</p>

</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/8+9 as indicated:
</p>

<blockquote><pre>tuple(const tuple&amp; u) = default;
</pre>

<blockquote>
<p>
8 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
Ti&amp;&gt;::value == true</tt> for e</ins><del>E</del>ach type
<ins><tt>Ti</tt></ins> in <tt>Types</tt><del> shall satisfy the
requirements of <tt>CopyConstructible</tt>(Table 34)</del>.
</p>

<p>
9 <i>Effects:</i> <ins>Initializes</ins><del>Copy constructs</del> each element
of <tt>*this</tt> with the corresponding element of <tt>u</tt>.
</p>

</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/10+11 as indicated:
</p>

<blockquote><pre>tuple(tuple&amp;&amp; u);
</pre>

<blockquote>
<p>
10 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(Types))</tt> and
let <tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>.
Then <tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for
all <tt>i</tt>.</ins> <del>Each type in <tt>Types</tt> shall shall satisfy the
requirements of <tt>MoveConstructible</tt> (Table 34)</del>.
</p>

<p>
11 <i>Effects:</i> <ins>For each <tt>Ti</tt> in <tt>Types</tt>, initializes the
<tt>i</tt><sup><i>th</i></sup></ins> <del>Move-constructs each</del> element of
<tt>*this</tt> with <del>the corresponding element of</del>
<ins><tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(</tt></ins><tt>u</tt><ins><tt>))</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/15+16 as indicated:
</p>

<blockquote><pre>template &lt;class... UTypes&gt; tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
15 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(Types))</tt>,
<tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>, and
<tt>Ui</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>. Then
<tt>is_constructible&lt;Ti, Ui&gt;::value</tt> shall be <tt>true</tt> for all
<tt>i</tt>.</ins> <del>Each type in <tt>Types</tt> shall shall satisfy the
requirements of <tt>MoveConstructible</tt> (Table 34) from the corresponding
type in <tt>UTypes</tt></del>. <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
</p>

<p>
16 <i>Effects:</i> <ins>For each type <tt>Ti</tt>, initializes the
<tt>i</tt><sup><i>th</i></sup></ins> <del>Move-constructs each</del> element of
<tt>*this</tt> with <del>the corresponding element of</del>
<ins><tt>std::forward&lt;Ui&gt;(get&lt;i&gt;(</tt></ins><tt>u</tt><ins><tt>))</tt></ins>.
</p>

</blockquote>
</blockquote>

</li>

<li>
<p>
Change 20.4.2.1 [tuple.cnstr]/19+20 as indicated:
</p>

<blockquote><pre>template &lt;class U1, class U2&gt; tuple(pair&lt;U1, U2&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
19 <i>Requires:</i> <ins><tt>is_constructible&lt;T1, U1&gt;::value ==
true</tt> for <tt>t</tt></ins><del><tt>T</tt></del>he first type
<ins><tt>T1</tt></ins> in <tt>Types</tt> <del>shall shall satisfy the
requirements of <tt>MoveConstructible</tt>(Table 33) from
<tt>U1</tt></del> and <ins><tt>is_constructible&lt;T2, U2&gt;::value ==
true</tt> for</ins> the second type <ins><tt>T2</tt></ins> in
<tt>Types</tt> <del>shall be move-constructible from <tt>U2</tt></del>.
<tt>sizeof...(Types) == 2</tt>.
</p>

<p>
20 <i>Effects:</i> <ins>Initializes</ins><del>Constructs</del> the first
element with
<tt>std::<ins>forward&lt;U1&gt;</ins><del>move</del>(u.first)</tt> and
the second element with
<tt>std::<ins>forward&lt;U2&gt;</ins><del>move</del>(u.second)</tt>.
</p>

</blockquote>
</blockquote>
</li>

<li>
<p>
Change 20.4.2.4 [tuple.creation]/9-16 as indicated:
</p>

<blockquote><pre>template &lt;class... TTypes, class... UTypes&gt;
tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
</pre>

<blockquote>
<p>
9 <i>Requires:</i> <ins><tt>is_constructible&lt;Ti, const
Ti&amp;&gt;::value == true</tt> for each type <tt>Ti</tt></ins><del>All
the types</del> in <tt>TTypes</tt> <del>shall be
<tt>CopyConstructible</tt> (Table 34)</del>.
<ins><tt>is_constructible&lt;Ui, const Ui&amp;&gt;::value == true</tt>
for each type <tt>Ui</tt></ins><del>All the types</del> in
<tt>UTypes</tt> <del>shall be <tt>CopyConstructible</tt> (Table
34)</del>.
</p>

<p>
10 <i>Returns:</i> A <tt>tuple</tt> object constructed by
<ins>initializing</ins><del>copy constructing</del> its first
<tt>sizeof...(TTypes)</tt> elements from the corresponding elements of
<tt>t</tt> and <ins>initializing</ins><del>copy constructing</del> its
last <tt>sizeof...(UTypes)</tt> elements from the corresponding elements
of <tt>u</tt>.
</p>
</blockquote>

<pre>template &lt;class... TTypes, class... UTypes&gt;
tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
</pre>

<blockquote>
<p>
11 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
<tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
<tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
<tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
<tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for each
type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, const Uj&amp;&gt;::value</tt>
shall be <tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
<tt>TTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34). All the types in
<tt>UTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35)</del>.
</p>

<p>
12 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
<tt>i</tt><sup><i>th</i></sup> element with
<tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(t))</tt> for all <tt>Ti</tt> in
<tt>TTypes</tt> and initializing the
<tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
<tt>get&lt;j&gt;(u)</tt> for all <tt>Uj</tt> in <tt>UTypes</tt>.</ins> <del>move
constructing its first <tt>sizeof...(TTypes)</tt> elements from the
corresponding elements of <tt>t</tt> and copy constructing its last
<tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
<tt>u</tt></del>.
</p>
</blockquote>

<pre>template &lt;class... TTypes, class... UTypes&gt;
tuple&lt;TTypes..., UTypes...&gt; tuple_cat(const tuple&lt;TTypes...&gt;&amp; t, tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
13 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
<tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
<tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
<tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
<tt>is_constructible&lt;Ti, const Ti&amp;&gt;::value</tt> shall be <tt>true</tt>
for each type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, Uj&gt;::value</tt>
shall be <tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
<tt>TTypes</tt> shall be <tt>CopyConstructible</tt> (Table 35). All the types in
<tt>UTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34)</del>.
</p>

<p>
14 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
<tt>i</tt><sup><i>th</i></sup> element with <tt>get&lt;i&gt;(t)</tt> for each
type <tt>Ti</tt> and initializing the
<tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
<tt>std::forward&lt;Uj&gt;(get&lt;j&gt;(u))</tt> for each type <tt>Uj</tt></ins>
<del>copy constructing its first <tt>sizeof...(TTypes)</tt> elements from the
corresponding elements of <tt>t</tt> and move constructing its last
<tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
<tt>u</tt></del>.
</p>
</blockquote>

<pre>template &lt;class... TTypes, class... UTypes&gt;
tuple&lt;TTypes..., UTypes...&gt; tuple_cat(tuple&lt;TTypes...&gt;&amp;&amp; t, tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>

<blockquote>
<p>
15 <i>Requires:</i> <ins>Let <tt>i</tt> be in <tt>[0, sizeof...(TTypes))</tt>,
<tt>Ti</tt> be the <tt>i</tt><sup><i>th</i></sup> type in <tt>Types</tt>,
<tt>j</tt> be in <tt>[0, sizeof...(UTypes))</tt>, and <tt>Uj</tt> be the
<tt>j</tt><sup><i>th</i></sup> type in <tt>UTypes</tt>.
<tt>is_constructible&lt;Ti, Ti&gt;::value</tt> shall be <tt>true</tt> for each
type <tt>Ti</tt> and <tt>is_constructible&lt;Uj, Uj&gt;::value</tt> shall be
<tt>true</tt> for each type <tt>Uj</tt></ins> <del>All the types in
<tt>TTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34). All the types in
<tt>UTypes</tt> shall be <tt>MoveConstructible</tt> (Table 34)</del>.
</p>

<p>
16 <i>Returns:</i> A <tt>tuple</tt> object constructed by <ins>initializing the
<tt>i</tt><sup><i>th</i></sup> element with
<tt>std::forward&lt;Ti&gt;(get&lt;i&gt;(t))</tt> for each type <tt>Ti</tt> and
initializing the <tt>(j+sizeof...(TTypes))</tt><sup><i>th</i></sup> element with
<tt>std::forward&lt;Uj&gt;(get&lt;j&gt;(u))</tt> for each type <tt>Uj</tt></ins>
<del>move constructing its first <tt>sizeof...(TTypes)</tt> elements from the
corresponding elements of <tt>t</tt> and move constructing its last
<tt>sizeof...(UTypes)</tt> elements from the corresponding elements of
<tt>u</tt></del>.
</p>
</blockquote>
</blockquote>
</li>
</ol>


<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
</blockquote>


<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.






<hr>
<h3><a name="1327"></a>1327. templates defined in <tt>&lt;cmath&gt;</tt> replacing C macros with the same name</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Michael Wong <b>Opened:</b> 2010-03-07 <b>Last modified:</b> 2010-11-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 26.8 [c.math]p12
The templates defined in <tt>&lt;cmath&gt;</tt> replace the C99 macros
with the same names. The templates have the following declarations:
</p>

<blockquote><pre>namespace std {
template &lt;class T&gt; bool signbit(T x);
template &lt;class T&gt; int fpclassify(T x);
template &lt;class T&gt; bool isfinite(T x);
template &lt;class T&gt; bool isinf(T x);
template &lt;class T&gt; bool isnan(T x);
template &lt;class T&gt; bool isnormal(T x);
template &lt;class T&gt; bool isgreater(T x, T y);
template &lt;class T&gt; bool isgreaterequal(T x, T y);
template &lt;class T&gt; bool isless(T x, T y);
template &lt;class T&gt; bool islessequal(T x, T y);
template &lt;class T&gt; bool islessgreater(T x, T y);
template &lt;class T&gt; bool isunordered(T x, T y);
}
</pre></blockquote>

<p>
and p13:
</p>

<blockquote>
13 The templates behave the same as the C99 macros with corresponding
names defined in C99 7.12.3, Classification macros, and C99 7.12.14,
Comparison macros in the C standard.
</blockquote>

<p>
The C Std versions look like this:
</p>

<blockquote>
<p>
7.12.14.1/p1:
</p>
<blockquote>
<p>
Synopsis
</p>
<p>
1 <tt>#include &lt;math.h&gt;</tt>
</p>
<pre>int isgreaterequal(real-floating x, real-floating y);
</pre>
</blockquote>
</blockquote>

<p>
which is not necessarily the same types as is required by C++ since the
two parameters may be different. Would it not be better if it were truly
aligned with C?
</p>

<p><i>[
2010 Pittsburgh:  Bill to ask WG-14 if heterogeneous support for the
two-parameter macros is intended.
]</i></p>


<p><i>[
2010-09-13 Daniel comments:
]</i></p>


<blockquote>
I recommend to resolve this issue as NAD Editorial because
the accepted resolution for NB comment <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3162.html#US136">US-136</a>
by motion 27 does address this.
</blockquote>

<p><i>[
2010-09-14 Bill comments:
]</i></p>


<blockquote>
Motion 27 directly addresses LWG 1327 and solves the problem
presented there. Moreover, the solution has been aired before
WG14 with no dissent. These functions now behave the same for
mixed-mode calls in both C and C++
</blockquote>



<p><b>Proposed resolution:</b></p>
Apply proposed resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3162.html#US136">US-136</a>





<hr>
<h3><a name="1328"></a>1328. istream extractors not setting failbit if eofbit is already set</h3>
<p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2010-02-17 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
basing on the recent discussion on the library reflector, see c++std-lib-27728
and follow ups, I hereby formally ask for LWG 419 to be re-opened, the rationale
being that according to the current specifications, per
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf">n3000</a>,
it seems actually impossible to seek away from end of file, contrary to the
rationale which led <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a> to its closure as NAD. My request is also
supported by Martin Sebor, and I'd like also to add, as tentative proposed
resolution for the re-opened issue, the wording suggested by Sebor, thus, change
the beginning of 27.7.1.1.3 [istream::sentry]/2, to:
</p>

<blockquote>
2 <i>Effects:</i> If <tt><ins>(!noskipws &amp;&amp; !</ins>is.good())</tt> is
<tt><del>false</del> <ins>true</ins></tt>, calls <tt>is.setstate(failbit)</tt>.
Otherwise prepares for formatted or unformatted input. ...
</blockquote>

<p><i>[
2010-10 Batavia"
]</i></p>

<p>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a>.
</p>

<p>
Previous proposed resolution:
</p><p>
Change 27.7.1.1.3 [istream::sentry]/2:
</p>

<blockquote>
2 <i>Effects:</i> If <tt><ins>(!noskipws &amp;&amp; !</ins>is.good())</tt> is
<tt><del>false</del> <ins>true</ins></tt>, calls <tt>is.setstate(failbit)</tt>.
Otherwise prepares for formatted or unformatted input. ...
</blockquote>



<p></p>


<p><b>Proposed resolution:</b></p>
Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a>.





<hr>
<h3><a name="1333"></a>1333. Missing forwarding during std::function invocation</h3>
<p><b>Section:</b> 20.8.14.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-03-26 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.inv">issues</a> in [func.wrap.func.inv].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current wording of 20.8.14.2.4 [func.wrap.func.inv]/1:
</p>

<blockquote><pre>R operator()(ArgTypes... args) const
</pre>

<blockquote>
<i>Effects:</i> <tt><i>INVOKE</i>(f, t1, t2, ..., tN, R)</tt> (20.8.2), where
<tt>f</tt> is the target object (20.8.1) of <tt>*this</tt> and <tt>t1, t2, ...,
tN</tt> are the values in <tt>args...</tt>.
</blockquote>
</blockquote>

<p>
uses an unclear relation between the actual args and the used variables
<tt>ti</tt>. It should be made clear, that <tt>std::forward</tt> has to be used
to conserve the expression lvalueness.
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 20.8.14.2.4 [func.wrap.func.inv]/1+2 as indicated:
</p>

<blockquote><pre>R operator()(ArgTypes... args) const
</pre>

<blockquote>
<p>
1 <i>Effects:</i>: <tt><i>INVOKE</i>(f,
<ins>std::forward&lt;ArgTypes&gt;(args)...</ins><del>t1, t2, ..., tN</del>,
R)</tt> (20.8.2), where <tt>f</tt> is the target object (20.8.1) of
<tt>*this</tt> <del>and <tt>t1, t2, ..., tN</tt> are the values in
<tt>args...</tt></del>.
</p>

<p>
2 <i>Returns:</i> Nothing if <tt>R</tt> is <tt>void</tt>, otherwise the return
value of <tt><i>INVOKE</i>(f,
<ins>std::forward&lt;ArgTypes&gt;(args)...</ins><del>t1, t2, ..., tN</del>,
R)</tt>.
</p>

<p>
3 <i>Throws:</i> <tt>bad_function_call</tt> if <tt>!*this</tt>; otherwise, any
exception thrown by the wrapped callable object.
</p>
</blockquote>
</blockquote>






<hr>
<h3><a name="1334"></a>1334. Insert iterators are broken for some proxy  containers compared to C++03</h3>
<p><b>Section:</b> 24.5.2.2.2 [back.insert.iter.op=], 24.5.2.4.2 [front.insert.iter.op=], X [insert.insert.iter.op=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-03-28 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In C++03 this was valid code:
</p>

<blockquote><pre>#include &lt;vector&gt;
#include &lt;iterator&gt;

int main() {
  typedef std::vector&lt;bool&gt; Cont;
  Cont c;
  std::back_insert_iterator&lt;Cont&gt; it = std::back_inserter(c);
  *it = true;
}
</pre></blockquote>

<p>
In C++0x this code does no longer compile because of an ambiguity error for this
<tt>operator=</tt> overload pair:
</p>

<blockquote><pre>back_insert_iterator&lt;Container&gt;&amp;
operator=(typename Container::const_reference value);

back_insert_iterator&lt;Container&gt;&amp;
operator=(typename Container::value_type&amp;&amp; value);
</pre></blockquote>

<p>
This is so, because for proxy-containers like <tt>std::vector&lt;bool&gt;</tt>
the <tt>const_reference</tt> usually is a non-reference type and in this case
it's identical to <tt>Container::value_type</tt>, thus forming the ambiguous
overload pair
</p>

<blockquote><pre>back_insert_iterator&lt;Container&gt;&amp;
operator=(bool value);

back_insert_iterator&lt;Container&gt;&amp;
operator=(bool&amp;&amp; value);
</pre></blockquote>

<p>
The same problem exists for <tt>std::back_insert_iterator</tt>,
<tt>std::front_insert_iterator</tt>, and <tt>std::insert_iterator</tt>.
</p>

<p>
One possible fix would be to require that <tt>const_reference</tt> of a proxy
container must not be the same as the <tt>value_type</tt>, but this would break
earlier valid code. The alternative would be to change the first signature to
</p>

<blockquote><pre>back_insert_iterator&lt;Container&gt;&amp;
operator=(const typename Container::const_reference&amp; value);
</pre></blockquote>

<p>
This would have the effect that this signature <em>always</em> expects an lvalue
or rvalue, but it would not create an ambiguity relative to the second form with
rvalue-references. [For all non-proxy containers the signature will be the same
as before due to reference-collapsing and const folding rules]
</p>


<p><i>[
Post-Rapperswil
]</i></p>


<p>
This problem is not restricted to the unspeakable <tt>vector&lt;bool&gt;</tt>, but is already existing for other proxy 
containers like gcc's <tt>rope</tt> class. The following code does no longer work ([Bug libstdc++/44963]):
</p>
<blockquote><pre>#include &lt;iostream&gt;
#include &lt;ext/rope&gt;

using namespace std;

int main()
{
     __gnu_cxx::crope line("test");
     auto ii(back_inserter(line));

     *ii++ = 'm'; // #1
     *ii++ = 'e'; // #2

     cout &lt;&lt; line &lt;&lt; endl;
}
</pre></blockquote>
<p>
Both lines marked with #1 and #2 issue now an error because the library has properly implemented the current
wording state (Thanks to Paolo Calini for making me aware of this real-life example).
</p>
<p>
The following P/R is a revision of the orignal P/R and was initially suggested by Howard 
Hinnant. Paolo verified that the approach works in gcc.
</p>

<blockquote>
Moved to Tentatively Ready with revised wording after 6 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>The wording refers to N3126.</i></p>

<ol>
<li>Change [back.insert.iterator], class <tt>back_insert_iterator</tt> synopsis as indicated:
<blockquote><pre>template &lt;class Container&gt;
class back_insert_iterator :
 public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
protected:
 Container* container;
public:
 [..]
 back_insert_iterator&lt;Container&gt;&amp;
   operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
 back_insert_iterator&lt;Container&gt;&amp;
   operator=(typename Container::value_type&amp;&amp; value);
 [..]
};
</pre></blockquote>
</li>
<li>Change [back.insert.iter.op=] before p. 1 as indicated:
<blockquote><pre>back_insert_iterator&lt;Container&gt;&amp;
   operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
</pre>
<blockquote>
1 <em>Effects</em>: <tt>container-&gt;push_back(value)</tt>;<br>
2 <em>Returns</em>: <tt>*this</tt>.
</blockquote></blockquote>
</li>
<li>Change [front.insert.iterator], class <tt>front_insert_iterator</tt> synposis as indicated:
<blockquote><pre>template &lt;class Container&gt;
class front_insert_iterator :
 public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
protected:
 Container* container;
public:
 [..]
 front_insert_iterator&lt;Container&gt;&amp;
   operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
 front_insert_iterator&lt;Container&gt;&amp;
   operator=(typename Container::value_type&amp;&amp; value);
 [..]
};
</pre></blockquote>
</li>
<li>Change [front.insert.iter.op=] before p.1 as indicated:
<blockquote><pre>front_insert_iterator&lt;Container&gt;&amp;
   operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
</pre>
<blockquote>
1 <em>Effects</em>: <tt>container-&gt;push_front(value)</tt>;<br>
2 <em>Returns</em>: <tt>*this</tt>.
</blockquote></blockquote>
</li>
<li>Change [insert.iterator], class insert_iterator synopsis as indicated:
<blockquote><pre>template &lt;class Container&gt;
   class insert_iterator :
     public iterator&lt;output_iterator_tag,void,void,void,void&gt; {
   protected:
     Container* container;
     typename Container::iterator iter;
   public:
     [..]
     insert_iterator&lt;Container&gt;&amp;
       operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
     insert_iterator&lt;Container&gt;&amp;
       operator=(typename Container::value_type&amp;&amp; value);
     [..]
   };
</pre></blockquote>
</li>
<li>Change [insert.iter.op=] before p. 1 as indicated:
<blockquote><pre>insert_iterator&lt;Container&gt;&amp;
    operator=(<ins>const</ins> typename Container::<del>const_reference</del><ins>value_type&amp;</ins> value);
</pre>
<blockquote>
1 <em>Effects</em>: 
<blockquote><pre>  iter = container-&gt;insert(iter, value);
  ++iter;
</pre></blockquote>
2 <em>Returns</em>: <tt>*this</tt>.
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="1335"></a>1335. Insufficient requirements for <tt>tuple::operator&lt;()</tt></h3>
<p><b>Section:</b> 20.4.2.7 [tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2010-05-15 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The requirements section for <tt>std::tuple</tt> says the following: 
</p>

<blockquote>
<i>Requires:</i> For all <tt>i</tt>, where <tt>0 &lt;= i and i &lt;
sizeof...(Types)</tt>, <tt>get&lt;i&gt;(t) &lt; get&lt;i&gt;(u)</tt> is a valid
expression returning a type that is convertible to <tt>bool</tt>.
<tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
</blockquote>

<p>
This is necessary but not sufficient, as the algorithm for comparing
<tt>tuple</tt>s also computes <tt>get&lt;i&gt;(u) &lt; get&lt;i&gt;(t)</tt>
(note the order)
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<blockquote>
Moved to Tentatively Ready with updated wording correcting change-bars after 6 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li>Change [tuple.rel] before p. 4 as indicated [<strong>Remark to the editor: This paragraph doesn't have a number yet,
but it seems to me as if it should have one</strong>]:
<blockquote><pre>template&lt;class... TTypes, class... UTypes&gt;
bool operator&lt;(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<em>Requires</em>: For all <tt>i</tt>, where <tt>0 &lt;= i</tt> and <tt>i &lt; sizeof...(Types)</tt>, 
<tt>get&lt;i&gt;(t) &lt; get&lt;i&gt;(u)</tt> <ins>and <tt>get&lt;i&gt;(u) &lt; get&lt;i&gt;(t)</tt></ins><del>is 
a valid expression returning a type that is</del><ins> are valid expressions returning types that 
are</ins> convertible to <tt>bool</tt>. <tt>sizeof...(TTypes) == sizeof...(UTypes)</tt>.
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="1337"></a>1337. Swapped arguments in <tt>regex_traits::isctype</tt></h3>
<p><b>Section:</b> 28.7 [re.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-06-21 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.traits">issues</a> in [re.traits].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
28.7 [re.traits]/12 describes <tt>regex_traits::isctype</tt> in terms
of <tt>ctype::is(c, m)</tt>, where <tt>c</tt> is a <tt>charT</tt> and <tt>m</tt>
is a <tt>ctype_base::mask</tt>.  Unfortunately 22.4.1.1.1 [locale.ctype.members]
specifies this function as <tt>ctype::is(m, c)</tt>
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Change 28.7 [re.traits]/12:
</p>

<blockquote><pre>bool isctype(charT c, char_class_type f) const;
</pre>
<blockquote>
<p>
11 ...
</p>
<p>
12 <i>Returns:</i> Converts <tt>f</tt> into a value <tt>m</tt> of type
<tt>std::ctype_base::mask</tt> in an unspecified manner, and returns
<tt>true</tt> if <tt>use_facet&lt;ctype&lt;charT&gt;
&gt;(getloc()).is(<del>c</del><ins>m</ins>, <del>m</del><ins>c</ins>)</tt> is
<tt>true</tt>. Otherwise returns <tt>true</tt> if <tt>f</tt> bitwise or'ed with
the result of calling <tt>lookup_classname</tt> with an iterator pair that
designates the character sequence <tt>"w"</tt> is not equal to 0 and <tt>c ==
'_'</tt>, or if <tt>f</tt> bitwise or'ed with the result of calling
<tt>lookup_classname</tt> with an iterator pair that designates the character
sequence <tt>"blank"</tt> is not equal to 0 and <tt>c</tt> is one of an
implementation-defined subset of the characters for which <tt>isspace(c,
getloc())</tt> returns <tt>true</tt>, otherwise returns <tt>false</tt>.
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="1338"></a>1338. LWG 1205 incorrectly applied</h3>
<p><b>Section:</b> 25.2.13 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-06-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a> (currently in WP) clarified the return value of several
algorithms when dealing with empty ranges.  In particular it recommended for
25.2.13 [alg.search]:
</p>

<blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2);

template&lt;class ForwardIterator1, class ForwardIterator2,
         class BinaryPredicate&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2,
           BinaryPredicate pred);
</pre>
<blockquote>
<p>
1 <i>Effects:</i> ...
</p>
<p>
2 <i>Returns:</i> ... Returns <tt>last1</tt> if no such iterator is found.
</p>
<p><ins>
3 <i>Remarks:</i> Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty.
</ins></p>
</blockquote>
</blockquote>

<p>
Unfortunately this got translated to an incorrect specification for what gets
returned when no such iterator is found (N3092):
</p>

<blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2);

template&lt;class ForwardIterator1, class ForwardIterator2,
         class BinaryPredicate&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2,
           BinaryPredicate pred);
</pre>
<blockquote>
<p>
1 <i>Effects:</i> ...
</p>
<p>
2 <i>Returns:</i> ... Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is
empty or if no such iterator is found.
</p>
</blockquote>
</blockquote>

<p>
LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a> is correct and N3092 is not equivalent nor correct.
</p>

<p>
I have not reviewed the other 10 recommendations of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1205">1205</a>.
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<blockquote>
It was verified that none of the remaining possibly affected algorithms does have any similar problems and a concrete P/R was added
that used a similar style as has been applied to the other cases.
</blockquote>

<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>Change [alg.search]/2 as indicated:
<blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2);

template&lt;class ForwardIterator1, class ForwardIterator2,
            class BinaryPredicate&gt;
  ForwardIterator1
    search(ForwardIterator1 first1, ForwardIterator1 last1,
           ForwardIterator2 first2, ForwardIterator2 last2,
           BinaryPredicate pred);
</pre>
<blockquote><p>
1 - [...]
</p>
2 - <em>Returns</em>: The first iterator <tt>i</tt> in the range <tt>[first1,last1 - (last2-first2))</tt> such that for any nonnegative
integer <tt>n</tt> less than <tt>last2 - first2</tt> the following corresponding conditions hold: <tt>*(i + n) == *(first2 + n)</tt>, 
<tt>pred(*(i + n), *(first2 + n)) != false</tt>. Returns <tt>first1</tt> if <tt>[first2,last2)</tt> is empty <del>or</del><ins>, otherwise
	returns <tt>last1</tt></ins> if no such iterator is found.
</blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="1339"></a>1339. <tt>uninitialized_fill_n</tt> should return the end of its range</h3>
<p><b>Section:</b> 20.9.8.4 [uninitialized.fill.n] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Jared Hoberock <b>Opened:</b> 2010-07-14 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092's</a>
specification of <tt>uninitialized_fill_n</tt> discards useful information and
is inconsistent with other algorithms such as <tt>fill_n</tt> which accept an
iterator and a size.  As currently specified, <tt>unintialized_fill_n</tt>
requires an additional linear traversal to find the end of the range.
</p>

<p>
Instead of returning <tt>void</tt>, <tt>unintialized_fill_n</tt> should return
one past the last iterator it dereferenced.
</p>

<p><i>[
Post-Rapperswil:
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
In section 20.9 [memory] change:,
</p>

<blockquote><pre>template &lt;class ForwardIterator, class Size, class T&gt;
  <del>void</del> <ins>ForwardIterator</ins> uninitialized_fill_n(ForwardIterator first, Size n, const T&amp; x);
</pre></blockquote>


<p>
In section 20.9.8.4 [uninitialized.fill.n] change,
</p>

<blockquote><pre>template &lt;class ForwardIterator, class Size, class T&gt;
  <del>void</del> <ins>ForwardIterator</ins> uninitialized_fill_n(ForwardIterator first, Size n, const T&amp; x);
</pre>
<blockquote>
<p>
1 <i>Effects:</i>
</p>
<blockquote><pre>for (; n--; ++first)
  ::new (static_cast&lt;void*&gt;(&amp;*first))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type(x);
<ins>return first;</ins>
</pre></blockquote>
</blockquote>
</blockquote>






<hr>
<h3><a name="1340"></a>1340. Why does <tt>forward_list::resize</tt> take the object to be copied by value?</h3>
<p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> 		
James McNellis <b>Opened:</b> 2010-07-16 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.modifiers">issues</a> in [forwardlist.modifiers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf">N3092</a>
23.3.3.4 [forwardlist.modifiers], the <tt>resize()</tt> member function is 
declared as:
</p>

<blockquote><pre>void resize(size_type sz, value_type c); 
</pre></blockquote>

<p>
The other sequence containers (<tt>list</tt>, <tt>deque</tt>, and
<tt>vector</tt>) take <tt>'c'</tt> by const reference.
</p>

<p>
Is there a reason for this difference?  If not, then <tt>resize()</tt> should 
be declared as: 
</p>

<blockquote><pre>void resize(size_type sz, const value_type&amp; c); 
</pre></blockquote>

<p>
The declaration would need to be changed both at its declaration in the class
definition at 23.3.3 [forwardlist]/3 and where its behavior is specified
at 23.3.3.4 [forwardlist.modifiers]/22.
</p>

<p>
This would make <tt>forward_list</tt> consistent with the CD1 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>.
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<p>
Daniel changed the P/R slightly, because one paragraph number has been changed since the issue
had been submitted. He also added a similar Requires element that exists in all other containers with
a <tt>resize</tt> member function. He deliberately did not touch the wrong usage of "default-constructed" because that
will be taken care of by LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>.
</p>

<blockquote>
Moved to Tentatively Ready with revised wording after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>


<ol>
<li>Change [forwardlist]/3, class template <tt>forward_list</tt> synopsis, as indicated:
<blockquote><pre>...
void resize(size_type sz);
void resize(size_type sz, <ins>const</ins> value_type<ins>&amp;</ins> c);
void clear();
...
</pre></blockquote>
</li>
<li>Change [forwardlist.modifiers]/27 as indicated: 
<blockquote><pre>	
void resize(size_type sz);
void resize(size_type sz, <ins>const</ins> value_type<ins>&amp;</ins> c);
</pre>
<blockquote>
27 <em>Effects</em>: If <tt>sz &lt; distance(begin(), end())</tt>, erases the last <tt>distance(begin(), end()) - sz</tt> elements
from the list. Otherwise, inserts <tt>sz - distance(begin(), end())</tt> elements at the end of the list. For the first 
signature the inserted elements are default constructed, and for the second signature they are copies of <tt>c</tt>.
<p>
<ins>28 - <em>Requires</em>: <tt>T</tt> shall be <tt>DefaultConstructible</tt> for the first form and	it shall be <tt>CopyConstructible</tt> 
	for the second form.</ins></p>
</blockquote></blockquote>
</li>
</ol>






<hr>
<h3><a name="1344"></a>1344. [FCD] Replace <tt>throw()</tt> with <tt>noexcept</tt></h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1351">1351</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-60, CH-16</b></p>
<p>
Dynamic exception specifications are deprecated; the
library should recognise this by replacing all non-throwing
exception specifications of the form <tt>throw()</tt> with the
<tt>noexcept</tt> form.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<p>
Replace all non-throwing exception specifications
of the form 'throw()' with the 'noexcept' form.
</p>

<p><i>[
2010-10-31 Daniel comments:
]</i></p>


<blockquote>
The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">n3148</a>
would satisfy this request.
</blockquote>

<p><i>[
2010-Batavia:
]</i></p>

<blockquote>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">n3148</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">n3148</a>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3150.html">n3150</a>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.html">n3195</a>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">n3155</a>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3156.html">n3156</a>





<hr>
<h3><a name="1346"></a>1346. [FCD] Apply <tt>noexcept</tt> where library specification does not permit exceptions</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1352">1352</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-62, CH-17</b></p>
<p>
Issues with efficiency and unsatisfactory semantics mean
many library functions document they do not throw
exceptions with a Throws: Nothing clause, but do not
advertise it with an exception specification. The semantic
issues are largely resolved with the new 'noexcept'
specifications, and the noexcept operator means we will
want to detect these guarantees programatically in order
to construct programs taking advantage of the guarantee.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<p>
Add a <tt>noexcept</tt> exception specification on each
libary API that offers an unconditional <i>Throws</i>:
Nothing guarantee. Where the guarantee is
conditional, add the appropriate
<tt>noexcept(<i>constant-expression</i>)</tt> if an appropriate
constant expression exists.
</p>

<p><i>[
2010-10-31 Daniel comments:
]</i></p>


<blockquote>
The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3149.html">n3149</a>
would satisfy this request.
</blockquote>

<p><i>[
2010-Batavia:
]</i></p>

<blockquote>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3149.html">n3149</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
This issue is resolved by the adoption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.html">n3195</a>





<hr>
<h3><a name="1347"></a>1347. [FCD] Apply <tt>noexcept</tt> judiciously throughout the library</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-63, US-80</b></p>
<p>
Since the newly introduced operator <tt>noexcept</tt> makes it
easy (easier than previously) to detect whether or not a
function has been declared with the empty exception
specification (including <tt>noexcept</tt>) library functions that
cannot throw should be decorated with the empty
exception specification. Failing to do so and leaving it as a
matter of QoI would be detrimental to portability and
efficiency.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Review the whole library, and apply the <tt>noexcept</tt>
specification where it is appropriate.
</p>

<p><i>[
2010-10-31 Daniel comments:
]</i></p>


<blockquote>
The proposed resolution of the combination of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">n3155</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3156.html">n3156</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3157.html">n3157</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3167.html">n3167</a>
would satisfy this request. The paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3150.html">n3150</a> is related
to this as well.
</blockquote>

<p><i>[
2010 Batavia:
]</i></p>

<p>
While the LWG expects to see further papers in this area, sufficient action was taken in Batavia to close the issue as Resolved by the listed papers.
</p>



<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">n3155</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3156.html">n3156</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3157.html">n3157</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3167.html">n3167</a> and remotely
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3150.html">n3150</a>





<hr>
<h3><a name="1354"></a>1354. [FCD] The definition of deadlock excludes cases involving a single thread</h3>
<p><b>Section:</b> 17.3.8 [defns.deadlock] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-52</b></p>
<p>
The definition of deadlock in 17.3.7 excludes cases
involving a single thread making it incorrect.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
The definition should be corrected.
</p>

<p><i>[
2010 Batavia Concurrency group provides a Proposed Resolution
]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
Change 17.3.8 [defns.deadlock] as indicated:
<blockquote>
<b>deadlock</b>
<p>
<del>two</del><ins>one</ins> or more threads are unable to continue execution because each is blocked waiting for one or more of the
others to satisfy some condition.
</p></blockquote>





<hr>
<h3><a name="1355"></a>1355. [FCD] The definition of move-assignment operator is redundant</h3>
<p><b>Section:</b> 17.3.16 [defns.move.assign.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-50</b></p>
<p>
This definition of move-assignment operator is redundant
and confusing now that the term move-assignment
operator is defined by the core language in subclause
12.8p21.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> provides a superior resolution.
</blockquote>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Strike subclause 17.3.16 [defns.move.assign.op].
Add a cross-reference to (12.8) to 17.3.12.
</p>



<p><b>Proposed resolution:</b></p>
Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.





<hr>
<h3><a name="1356"></a>1356. [FCD] The definition of move-constructor is redundant</h3>
<p><b>Section:</b> 17.3.17 [defns.move.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-51</b></p>
<p>
This definition of move-constructor is redundant and
confusing now that the term constructor is defined by the
core language in subclause 12.8p3.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> provides a superior resolution.
</blockquote>

<p><i>[
2010 Batavia: resolved as NAD Editorial by adopting paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.
]</i></p>

<p>
Original proposed resolution preserved for reference:
</p>
<blockquote>
<p>
Strike subclause 17.3.14, [defns.move.ctor]
</p>

<blockquote><del>
<b>17.3.14	[defns.move.ctor]</b><br>
move constructor a constructor which accepts only an rvalue argument of the type being constructed and might modify the argument as a side effect during construction.
</del></blockquote>
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.





<hr>
<h3><a name="1357"></a>1357. [FCD] Library bitmask types to not satisfy the bimask type requirements</h3>
<p><b>Section:</b> 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitmask.types">issues</a> in [bitmask.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-53</b></p>
<p>
The bitmask types defined in 27.5.2 and 28.5 contradict
the bitmask type requirements in 17.5.2.1.3, and have
missing or incorrectly defined operators.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
See Appendix 1 - Additional Details
</p>

<p><i>[
2010 - Rapperswil
]</i></p>

<p>
The paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>
was made available during the meeting to resolve this comment, but withdrawn from formal motions
to give others time to review the document.  There was no technical objection, and it is expected
that this paper will go forward at the next meeting. 
</p>



<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html">n3110</a>.





<hr>
<h3><a name="1360"></a>1360. [FCD] Add <tt>&lt;atomic&gt;</tt> to free-standing implementations</h3>
<p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-57</b></p>
<p>
The atomic operations facility is closely tied to clause 1
and the memory model. It is not easily supplied as an
after-market extension, and should be trivial to implement
of a single-threaded serial machine. The consequence of
not having this facility will be poor interoperability with
future C++ libraries that memory model concerns
seriously, and attempt to treat them in a portable way.
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add <tt>&lt;atomic&gt;</tt> to table 15, headers required for a
free-standing implementation.





<hr>
<h3><a name="1362"></a>1362. [FCD] Description of binding to rvalue-references should use the new 'xvalue' vocabulary</h3>
<p><b>Section:</b> 17.6.3.9 [res.on.arguments] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.arguments">issues</a> in [res.on.arguments].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-82</b></p>
<p>
17.6.3.9 [res.on.arguments] p.1. b.3: The second Note can benefit by adopting recent nomenclature.
</p>


<p><i>[
Resolution proposed by the ballot comment:
]</i></p>

<p>
Rephrase the Note in terms of xvalue.
</p>

<p><i>[
Pre-Batavia:
]</i></p>

<p>
Walter Brown provides wording.
</p>

<p><i>[Batavia: Immediate]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>


<p><b>Proposed resolution:</b></p>

<p>
Amend the note in 17.6.3.9 [res.on.arguments] p1 bullet 3.
</p>
<blockquote>
[ <i>Note</i>: If a program casts an lvalue to an <del>rvalue</del><ins>xvalue</ins> while passing that lvalue to a library function (e.g. by calling the function with the argument <tt>move(x)</tt>), the program is effectively asking that function to treat that lvalue as a temporary. The implementation is free to optimize away aliasing checks which might be needed if the argument was anlvalue. <i>—endnote</i>]
</blockquote>






<hr>
<h3><a name="1363"></a>1363. [FCD] <tt>offsetof</tt> should be marked <tt>noexcept</tt></h3>
<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-68</b></p>
<p>
There is no reason for the offsetof macro to invoke
potentially throwing operations, so the result of
noexcept(offsetof(type,member-designator)) should be
true.
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>Add to the end of 18.2p4:</p>
<blockquote><ins>
No operation invoked by the offsetof macro shall
throw an exception, and
<tt>noexcept(offsetof(type,member-designator))</tt> shall
be true.</ins>
</blockquote>





<hr>
<h3><a name="1365"></a>1365. [FCD] Thread-safety of handler functions</h3>
<p><b>Section:</b> 18.6.2 [alloc.errors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-71</b></p>
<p>
The thread safety of <tt>std::set_new_handler()</tt>,
<tt>std::set_unexpected()</tt>, <tt>std::set_terminate()</tt>, is
unspecified making the the functions impossible to use in a thread
safe manner.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
The thread safety guarantees for the functions
must be specified and new interfaces should be
provided to make it possible to query and install
handlers in a thread safe way.
</blockquote>

<p><i>[
2010-10-31 Daniel comments:
]</i></p>


<blockquote>
The proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3122.html">n3122</a>
partially addresses this request. This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1366">1366</a>.
</blockquote>


<p><i>[
2010-Batavia:
]</i></p>

<blockquote>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.html">n3189</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved in Batavia by accepting  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.html">n3189</a>.





<hr>
<h3><a name="1366"></a>1366. [FCD] New-handler and data races</h3>
<p><b>Section:</b> 18.6.1.4 [new.delete.dataraces] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE-14</b></p>
<p>
It is unclear how a user replacement function can
simultaneously satisfy the race-free conditions imposed in
this clause and query the new-handler in case of a failed
allocation with the only available, mutating interface
<tt>std::set_new_handler</tt>.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<p>
Offer a non-mutating interface to query the current new-handler.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3122.html">n3122</a> would solve this issue.
This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1365">1365</a>.
</blockquote>

<p><i>[
2010-Batavia:
]</i></p>

<blockquote>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.html">n3189</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved in Batavia by accepting  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.html">n3189</a>.





<hr>
<h3><a name="1367"></a>1367. [FCD] Deprecate library support for checking dynamic exception specifications</h3>
<p><b>Section:</b> D.13 [exception.unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-72</b></p>
<p>
Dynamic exception specifications are deprecated, so
clause 18.8.2 that describes library support for this facility
should move to Annex D, with the exception of the
<tt>bad_exception</tt> class which is retained to indicate other
failures in the exception dispatch mechanism (e.g. calling
<tt>current_exception()</tt>).
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
With the exception of 18.8.2.1 [bad.exception],
move clause 18.8.2 diectly to Annex D.
[bad.exception] should simply become the new
18.8.2.





<hr>
<h3><a name="1368"></a>1368. [FCD] Thread safety of <tt>std::uncaught_exception()</tt></h3>
<p><b>Section:</b> 18.8.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-73</b></p>
<p>
The thread safety <tt>std::uncaught_exception()</tt> and the
result of the function when multiple threads throw
exceptions at the same time are unspecified. To make the
function safe to use in the presence of exceptions in
multiple threads the specification needs to be updated.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Update this clause to support safe calls from
multiple threads without placing synchronization
requirements on the user.
</p>

<p><i>[
2010 Batavia Concurrency group provides a Proposed Resolution
]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>Change 18.8.4 [uncaught] p. 1 as follows:</p>
<p>
<i>Returns</i>: <tt>true</tt> after <ins> the current thread has initialized </ins><del>initializing</del>
 an exception object (15.1) until a handler for the exception (including <tt>unexpected()</tt> or <tt>terminate()</tt>) 
 is activated (15.3). [ <i>Note</i>: This includes stack unwinding (15.2). � <i>end note</i> ]
</p>






<hr>
<h3><a name="1370"></a>1370. [FCD] <tt>throw_with_nested</tt> should not use perfect forwarding</h3>
<p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-84</b></p>
<p>
The <tt>throw_with_nested</tt> specification passes in its argument as
<tt>T&amp;&amp;</tt> (perfect forwarding pattern), but then discusses
requirements on <tt>T</tt> without taking into account that <tt>T</tt>
may be an lvalue-reference type. It is also not clear in the spec that
<tt>t</tt> is intended to be perfectly forwarded.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Patch [except.nested] p6-7 to match the intent with regards to
requirements on <tt>T</tt> and the use of
<tt>std::forward&lt;T&gt;(t)</tt>.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3144.html">n3144</a> would solve this issue.
</blockquote>

<p><i>[2010-11-10 Batavia: LWG accepts Howard's updated wording with
corrected boo boos reported by Sebastian Gesemann and Pete Becker,
which is approved for Immediate adoption this meeting.]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p> 
<p><i>Change 18.8.7 nested_exception [except.nested] as indicated:</i></p>
<blockquote>
  <pre>[[noreturn]] template &lt;class T&gt; void throw_with_nested(T&amp;&amp; t);
</pre>
  <blockquote>
    <p><ins>Let <tt>U</tt> be <tt>remove_reference&lt;T&gt;::type</tt> </ins></p>
    <p>6 <i>Requires:</i> <tt><del>T</del> <ins>U</ins></tt> shall be <tt>
    CopyConstructible</tt>. </p>
    <p>7 <i>Throws:</i> If <tt><del>T</del> <ins>U</ins></tt> is a non-union 
    class type not derived from <tt>nested_exception</tt>, an exception of 
    unspecified type that is publicly derived from both <tt><del>T</del> <ins>U</ins></tt> 
    and <tt>nested_exception</tt> <ins>and constructed from <tt>std::forward&lt;T&gt;(t)</tt></ins>, 
    otherwise <ins>throws</ins> <tt><ins>std::forward&lt;T&gt;(</ins>t<ins>)</ins></tt>.
    </p>
  </blockquote>
</blockquote>





<hr>
<h3><a name="1372"></a>1372. [FCD] Adopt recommended practice for standard error categories</h3>
<p><b>Section:</b> 19.5.1.5 [syserr.errcat.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-76</b></p>
<p>
The C++0x FCD recommends, in a note (see 19.5.1.1/1), that users
create a single <tt>error_category</tt> object for each user defined error
category and specifies <tt>error_category</tt> equality comparsions based on
equality of addresses (19.5.1.3). The Draft apparently ignores this
when specifying standard error category objects in section 19.5.1.5,
by allowing the <tt>generic_category()</tt> and <tt>system_category()</tt>
functions to return distinct objects for each invocation.
</p>
<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Append a new sentence to 19.5.1.5 [syserr.errcat.objects]/1, and append
the same sentence to 19.5.1.5/3.
</p>
<blockquote><ins>
All calls of this function return references to the same object.
</ins></blockquote>





<hr>
<h3><a name="1377"></a>1377. [FCD] The revised <tt>forward</tt> is not compatible with access-control</h3>
<p><b>Section:</b> 20.3 [utility] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility">issues</a> in [utility].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-90</b></p>
<p>
In n3090, at variance with previous iterations of the idea
discussed in papers and incorporated in WDs,
<tt>std::forward</tt> is constrained via <tt>std::is_convertible</tt>,
thus is not robust wrt access control. This causes problems in
normal uses as implementation detail of member
functions. For example, the following snippet leads to a
compile time failure, whereas that was not the case for an
implementation along the lines of n2835 (using <tt>enable_if</tt>s
instead of concepts for the constraining, of course)
</p>
<pre>#include &lt;utility&gt;
struct Base { Base(Base&amp;&amp;); };

struct Derived
  : private Base
{
  Derived(Derived&amp;&amp; d)
    : Base(std::forward&lt;Base&gt;(d)) { }
};
</pre>
<p>
In other terms, LWG 1054 can be resolved in a better
way, the present status is not acceptable.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3143.html">n3143</a> would solve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved as NAD Editorial by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3143.html">n3143</a>.





<hr>
<h3><a name="1378"></a>1378. [FCD] <tt>pair</tt> and <tt>tuple</tt> have too many conversions</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE-15</b></p>
<p>
Several function templates of <tt>pair</tt> and <tt>tuple</tt> allow for too
many implicit conversions, for example:
</p>
<pre>#include &lt;tuple&gt;
std::tuple&lt;char*&gt; p(0); // Error?

struct A { explicit A(int){} };
A a = 1; // Error
std::tuple&lt;A&gt; ta = std::make_tuple(1); // OK?
</pre>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Consider to add wording to constrain these function templates.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
</blockquote>




<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.





<hr>
<h3><a name="1379"></a>1379. [FCD] <tt>pair</tt> copy-assignment not consistent for references</h3>
<p><b>Section:</b> 20.3.5.2 [pairs.pair] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-95</b></p>
<p>
Copy-assignment for <tt>pair</tt> is defaulted and does not work
for pairs with reference members. This is inconsistent with
conversion-assignment, which deliberately succeeds even
if one or both elements are reference types, just as for
<tt>tuple</tt>. The copy-assignment operator should be
consistent with the conversion-assignment operator and
with <tt>tuple</tt>'s assignment operators.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would provide a superior resolution,
because <tt>pair</tt> does not depend on the semantic requirements of <tt>CopyAssignable</tt>.
</blockquote>

<p><i>[
2010-11 Batavia
]</i></p>

<p>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
</p>



<p><b>Proposed resolution:</b></p>
Add to <tt>pair</tt> synopsis:
<blockquote>
<tt>pair&amp; operator=(const pair&amp; p);</tt>
</blockquote>
<p>
Add before paragraph 9:
</p>
<blockquote>
<tt>pair&amp; operator=(const pair&amp; p);</tt>
<blockquote>
<p>
<i>Requires</i>: <tt>T1</tt> and <tt>T2</tt> shall satisfy the
requirements of <tt>CopyAssignable</tt>.
</p>
<p>
<i>Effects</i>: Assigns <tt>p.first</tt> to <tt>first</tt> and <tt>p.second</tt> to
<tt>second</tt>.
<i>Returns</i>: <tt>*this</tt>.
</p>
</blockquote>
</blockquote>





<hr>
<h3><a name="1380"></a>1380. [FCD] <tt>pair</tt> and <tt>tuple</tt> of references need to better specify move-semantics</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE-16</b></p>
<p>
Several <tt>pair</tt> and <tt>tuple</tt> functions in regard to move
operations are incorrectly specified if the member types
are references, because the result of a <tt>std::move</tt> cannot
be assigned to lvalue-references. In this context the usage
of the requirement sets <tt>MoveConstructible</tt> and
<tt>CopyConstructible</tt> also doesn't make sense, because
non-const lvalue-references cannot satisfy these requirements.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Replace the usage of <tt>std::move</tt> by that of
<tt>std::forward</tt> and replace <tt>MoveConstructible</tt> and
<tt>CopyConstructible</tt> requirements by other requirements.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
</blockquote>

<p><i>[
2010-11 Batavia:
]</i></p>


<blockquote>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
</blockquote>



<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.





<hr>
<h3><a name="1381"></a>1381. [FCD] Ballot Comment GB-85</h3>
<p><b>Section:</b> X [pair.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-85</b></p>
<p>
While <tt>std::pair</tt> may happen to hold a pair of iterators
forming a valid range, this is more likely a coincidence
than a feature guaranteed by the semantics of the <tt>pair</tt>
template. A distinct range-type should be supplied to
enable the new for-loop syntax rather than overloading an
existing type with a different semantic.
</p>

<p>
If a replacement facility is required for C++0x,
consider n2995.
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Strike 20.3.5.4 and the matching declarations in
20.3 header synopsis.





<hr>
<h3><a name="1382"></a>1382. [FCD] <tt>pair</tt> and <tt>tuple</tt> constructors should <tt>forward</tt> arguments</h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-96</b></p>
<p>
<tt>pair</tt> and <tt>tuple</tt> constructors and assignment operators use
<tt>std::move</tt> when they should use <tt>std::forward</tt>. This
causes lvalue references to be erroneously converted to
rvalue references. Related requirements clauses are also
wrong.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<blockquote>
See Appendix 1 - Additional Details
</blockquote>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue.
</blockquote>

<p><i>[
2010-11 Batavia
]</i></p>

<p>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.
</p>



<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.





<hr>
<h3><a name="1383"></a>1383. [FCD] Inconsistent defaulted move/copy members in <tt>pair</tt> and <tt>tuple</tt></h3>
<p><b>Section:</b> 20.3.5 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-97</b></p>
<p>
<tt>pair</tt>'s class definition in N3092 20.3.5.2 [pairs.pair]
contains "<tt>pair(const pair&amp;) = default;</tt>" and 
"<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>". The latter is described by
20.3.5.2 [pairs.pair] p.12-13.
</p>
"<tt>pair(const pair&amp;) = default;</tt>" is a user-declared explicitly defaulted
copy constructor. According to 12.8 [class.copy]/10, this inhibits 
the implicitly-declared move constructor. <tt>pair</tt> should be move constructible. 
(12.8 [class.copy]/7 explains that "<tt>pair(pair&lt;U, V&gt;&amp;&amp; p)</tt>" 
will never be instantiated to move <tt>pair&lt;T1, T2&gt;</tt> to <tt>pair&lt;T1, T2&gt;</tt>.)<br>
"<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>" is a user-provided move
assignment operator (according to 8.4.2 [dcl.fct.def.default]/4: "A 
special member function is user-provided if it is user-declared and not explicitly defaulted
on its first declaration."). According to 12.8 [class.copy]/20, this inhibits
the implicitly-declared copy assignment operator. <tt>pair</tt>
should be copy assignable, and was in C++98/03. (Again,
12.8 [class.copy]/7 explains that "<tt>operator=(const pair&lt;U, V&gt;&amp; p)</tt>" 
will never be instantiated to copy <tt>pair&lt;T1, T2&gt;</tt> to <tt>pair&lt;T1, T2&gt;</tt>.)<br>
Additionally, "<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>" is
unconditionally defined, whereas according to 12.8 [class.copy]/25,
defaulted copy/move assignment operators are defined as
deleted in several situations, such as when non-static data
members of reference type are present.
<p>
If "<tt>pair(const pair&amp;) = default;</tt>" and "<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>" 
were removed from <tt>pair</tt>'s class definition in 20.3.5.2 [pairs.pair] and from 
20.3.5.2 [pairs.pair]/12-13, <tt>pair</tt> would
receive implicitly-declared copy/move constructors and
copy/move assignment operators, and 12.8 [class.copy]/25 would
apply. The implicitly-declared copy/move constructors
would be trivial when <tt>T1</tt> and <tt>T2</tt> have trivial copy/move
constructors, according to 12.8 [class.copy]/13, and similarly for the
assignment operators, according to12.8 [class.copy]/27. Notes could
be added as a reminder that these functions would be
implicitly-declared, but such notes would not be necessary
(the Standard Library specification already assumes a
high level of familiarity with the Core Language, and
casual readers will simply assume that <tt>pair</tt> is copyable
and movable).
</p><p>
Alternatively, <tt>pair</tt> could be given explicitly-defaulted
copy/move constructors and copy/move assignment
operators. This is a matter of style.
</p><p>
<tt>tuple</tt> is also affected. <tt>tuple</tt>'s class definition in 20.4 [tuple] contains:
</p><pre>tuple(const tuple&amp;) = default;
tuple(tuple&amp;&amp;);
tuple&amp; operator=(const tuple&amp;);
tuple&amp; operator=(tuple&amp;&amp;);
</pre>
They should all be removed or all be explicitly-defaulted,
to be consistent with <tt>pair</tt>. Additionally, 20.4.2.1 [tuple.cnstr]/8-9 specifies the 
behavior of an explicitly defaulted function, which is currently inconsistent with
<tt>pair</tt>.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
Either remove "<tt>pair(const pair&amp;) = default;</tt>" and
"<tt>pair&amp; operator=(pair&amp;&amp; p);</tt>" from <tt>pair</tt>'s class
definition in  20.3.5.2 [pairs.pair] and from  20.3.5.2 [pairs.pair] p.12-13, or
give pair explicitly-defaulted copy/move constructors and copy/move assignment operators.<br>
Change <tt>tuple</tt> to match.
</blockquote>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a> would solve this issue:
The move/copy constructor will be defaulted, but the corresponding assignment operators need a non-default implementation
because they are supposed to work for references as well.
</blockquote>



<p><b>Proposed resolution:</b></p>
See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3140.html">n3140</a>.





<hr>
<h3><a name="1384"></a>1384. [FCD] Ballot Comment US-98</h3>
<p><b>Section:</b> 20.4.2.4 [tuple.creation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.creation">issues</a> in [tuple.creation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-98</b></p>
<p>
pack_arguments is poorly named. It does not reflect the
fact that it is a tuple creation function and that it forwards
arguments.
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Rename pack_arguments to forward_as_tuple
throughout the standard.





<hr>
<h3><a name="1386"></a>1386. FCD Ballot Comment US-99</h3>
<p><b>Section:</b> 20.4.2.4 [tuple.creation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.creation">issues</a> in [tuple.creation].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-99</b></p>
<p>
pack_arguments is overly complex.
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
This issue resulted from a lack of understanding of
how references are forwarded. The definition of
pack_arguments should be simply:<br>
template &lt;class... Types&gt;
tuple&lt;<del>A</del>Types<ins>&amp;&amp;</ins>&gt;
pack_arguments(Types&amp;&amp;...t);<br>
<del>Types:Let Ti be each type in Types....</del><br>
Effects: ...<br>
Returns:<br>
tuple&lt;<del>A</del>Types<ins>&amp;&amp;</ins>...&gt;(std::forward&lt;Types&gt;(t)...)<br>
The synopsis should also change to reflect this
simpler signature.





<hr>
<h3><a name="1387"></a>1387. [FCD] Ballot Comment GB-87</h3>
<p><b>Section:</b> X [tuple.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-87</b></p>
<p>
There is no compelling reason to assume a
heterogeneous tuple of two elements holds a pair of
iterators forming a valid range. Unlike std::pair, there are
no functions in the standard library using this as a return
type with a valid range, so there is even less reason to try
to adapt this type for the new for-loop syntax.
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Strike 20.4.2.10 and the matching declarations in
the header synopsis in 20.4.





<hr>
<h3><a name="1388"></a>1388. FCD Ballot Comment US-100</h3>
<p><b>Section:</b> 20.6.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-100</b></p>
<p>
LWG 1281 was discussed in Pittsburgh, and the decision
there was to accept the typedef as proposed and move to
Review. Unfortunately the issue was accidentally applied
to the FCD, and incorrectly. The FCD version of the
typedef refers to ratio&lt;N, D&gt;, but the typedef is intended
to refer to ratio&lt;num, den&gt; which in general is not the
same type.
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Accept the current proposed wording of LWG
1281 which adds:<br>
typedef ratio&lt;num, den&gt; type;





<hr>
<h3><a name="1389"></a>1389. [FCD] Compile-time rational arithmetic and overflow</h3>
<p><b>Section:</b> 20.6.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-89</b></p>
<p>
The alias representations of the <tt>ratio</tt> arithmetic templates
do not allow implementations to avoid overflow, since they
explicitly specify the form of the aliased template
instantiation. For example
<tt>ratio_multiply</tt>, <tt>ratio&lt;2, LLONG_MAX&gt;</tt> is <em>required</em> to
alias <tt>ratio&lt;2*LLONG_MAX, LLONG_MAX*2&gt;</tt>, which
overflows, so is ill-formed. However, this is trivially equal
to <tt>ratio&lt;1, 1&gt;</tt>. It also contradicts the opening statement of
20.6.2 [ratio.arithmetic] p. 1 "implementations may use other algorithms to
compute these values".
</p>

<p><i>[
2010-10-25 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3131.html">n3131</a> would solve this issue.
</blockquote>

<p><i>[Batavia: Resoved by accepting
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3210.html">n3210</a>.]</i></p>




<p><b>Proposed resolution:</b></p>
Change the wording in 20.6.2 [ratio.arithmetic] p. 2-5 as follows:
<p>
</p><blockquote><pre>template &lt;class R1, class R2&gt; using ratio_add = <em>see below</em>;
</pre><blockquote>
2 The type <tt>ratio_add&lt;R1, R2&gt;</tt> shall be a synonym for <del><tt>ratio&lt;T1, T2&gt;</tt></del>
<ins><tt>ratio&lt;U, V&gt;</tt> such that <tt>ratio&lt;U, V&gt;::num</tt> and <tt>ratio&lt;U, V&gt;::den</tt> 
are the same as the corresponding members of <tt>ratio&lt;T1, T2&gt;</tt> would be in the absence of 
arithmetic overflow</ins> where <tt>T1</tt> has the value <tt>R1::num * R2::den + R2::num * R1::den</tt> 
and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>. <ins>If the required values of <tt>ratio&lt;U, V&gt;::num</tt> 
and <tt>ratio&lt;U, V&gt;::den</tt> cannot be represented in <tt>intmax_t</tt> then the program is ill-formed.</ins>
</blockquote></blockquote>
<blockquote><pre>template &lt;class R1, class R2&gt; using ratio_subtract = <em>see below</em>;
</pre><blockquote>
3 The type <tt>ratio_subtract&lt;R1, R2&gt;</tt> shall be a synonym for <del><tt>ratio&lt;T1, T2&gt;</tt></del>
<ins><tt>ratio&lt;U, V&gt;</tt> such that <tt>ratio&lt;U, V&gt;::num</tt> and <tt>ratio&lt;U, V&gt;::den</tt> 
are the same as the corresponding members of <tt>ratio&lt;T1, T2&gt;</tt> would be in the absence of 
arithmetic overflow</ins> where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num * R1::den</tt> 
and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>. <ins>If the required values of <tt>ratio&lt;U, V&gt;::num</tt> 
and <tt>ratio&lt;U, V&gt;::den</tt> cannot be represented in <tt>intmax_t</tt> then the program is ill-formed.</ins>
</blockquote></blockquote>
<blockquote><pre>template &lt;class R1, class R2&gt; using ratio_multiply = <em>see below</em>;
</pre><blockquote>
4 The type <tt>ratio_multiply&lt;R1, R2&gt;</tt> shall be a synonym for <del><tt>ratio&lt;T1, T2&gt;</tt></del>
<ins><tt>ratio&lt;U, V&gt;</tt> such that <tt>ratio&lt;U, V&gt;::num</tt> and <tt>ratio&lt;U, V&gt;::den</tt> 
are the same as the corresponding members of <tt>ratio&lt;T1, T2&gt;</tt> would be in the absence of 
arithmetic overflow</ins> where <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> 
has the value <tt>R1::den * R2::den</tt>. <ins>If the required values of <tt>ratio&lt;U, V&gt;::num</tt> 
and <tt>ratio&lt;U, V&gt;::den</tt> cannot be represented in <tt>intmax_t</tt> then the program is ill-formed.</ins>
</blockquote></blockquote>
<blockquote><pre>template &lt;class R1, class R2&gt; using ratio_divide = <em>see below</em>;
</pre><blockquote>
5 The type <tt>ratio_divide&lt;R1, R2&gt;</tt> shall be a synonym for <del><tt>ratio&lt;T1, T2&gt;</tt></del>
<ins><tt>ratio&lt;U, V&gt;</tt> such that <tt>ratio&lt;U, V&gt;::num</tt> and <tt>ratio&lt;U, V&gt;::den</tt> 
are the same as the corresponding members of <tt>ratio&lt;T1, T2&gt;</tt> would be in the absence of 
arithmetic overflow</ins> where <tt>T1</tt> has the value <tt>R1::num * R2::den</tt> and <tt>T2</tt> 
has the value <tt>R1::den * R2::num</tt>. <ins>If the required values of <tt>ratio&lt;U, V&gt;::num</tt> 
and <tt>ratio&lt;U, V&gt;::den</tt> cannot be represented in <tt>intmax_t</tt> then the program is ill-formed.</ins>
</blockquote></blockquote>





<hr>
<h3><a name="1390"></a>1390. [FCD] Limit speculative compilation for constructible/convertible traits</h3>
<p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE-17</b></p>
<p>
Speculative compilation for <tt>std::is_constructible</tt> and
<tt>std::is_convertible</tt> should be limited, similar to the core
language (see 14.8.2 paragraph 8).
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> would solve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.





<hr>
<h3><a name="1391"></a>1391. [FCD] constructible/convertible traits and access control</h3>
<p><b>Section:</b> 20.7 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE-18</b></p>
<p>
Several type traits require compiler support, e.g.
<tt>std::is_constructible</tt> or <tt>std::is_convertible</tt>.
Their current specification seems to imply, that the corresponding
test expressions should be well-formed, even in absense of access:
</p>
<pre>class X { X(int){} };
constexpr bool test = std::is_constructible&lt;X, int&gt;::value;
</pre>
<p>
The specification does not clarify the context of this test
and because it already goes beyond normal language
rules, it's hard to argue by means of normal language
rules what the context and outcome of the test should be.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Specify that <tt>std::is_constructible</tt> and
<tt>std::is_convertible</tt> will return <tt>true</tt> only for
public constructors/conversion functions.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> would solve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.





<hr>
<h3><a name="1392"></a>1392. [FCD] <tt>result_of</tt> should support pointer-to-data-member</h3>
<p><b>Section:</b> 20.7.4 [meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary">issues</a> in [meta.unary].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-102</b></p>
<p>
Despite Library Issue 520's ("<tt>result_of</tt> and pointers to
data members") resolution of CD1, the FCD's <tt>result_of</tt>
supports neither pointers to member functions nor
pointers to data members. It should.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Ensure <tt>result_of</tt> supports pointers to member
functions and pointers to data members.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3123.html">n3123</a> would solve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3123.html">n3123</a>.





<hr>
<h3><a name="1393"></a>1393. [FCD] Trivial traits imply noexcept</h3>
<p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-92</b></p>
<p>
Trivial functions implicitly declare a <tt>noexcept</tt> exception
specification, so the references to <tt>has_trivial_*</tt> traits in the
<tt>has_nothrow_*</tt> traits are redundant, and should be struck for clarity.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
For each of the <tt>has_nothrow_<i>something</i></tt> traits,
remove all references to the matching
<tt>has_trivial_<i>something</i></tt> traits.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a> would solve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3142.html">n3142</a>.





<hr>
<h3><a name="1394"></a>1394. [FCD] Ballot Comment DE-19</h3>
<p><b>Section:</b> 20.7.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE-19</b></p>
<p>
The fundamental trait is_constructible reports false
positives, e.g.
</p>
<pre>is_constructible&lt;char*, void*&gt;::value
</pre>
evaluates to true, even though a corresponding variable
initialization would be ill-formed.

<p><i>[
Resolved in Rapperswil by paper N3047.
]</i></p>




<p><b>Proposed resolution:</b></p>
Remove all false positives from the domain of
is_constructible.





<hr>
<h3><a name="1397"></a>1397. [FCD] Deprecate '98 binders</h3>
<p><b>Section:</b> 20.8 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-95</b></p>
<p>
The adaptable function protocol supported by
<tt>unary_function</tt>/<tt>binary_function</tt> has been superceded by
lambda expressions and <tt>std::bind</tt>. Despite the name, the
protocol is not very adaptable as it requires intrusive
support in the adaptable types, rather than offering an
external traits-like adaption mechanism. This protocol and
related support functions should be deprecated, and we
should not make onerous requirements for the
specification to support this protocol for callable types
introduced in this standard revision, including those
adopted from TR1. It is expected that high-quality
implementations will provide such support, but we should
not have to write robust standard specifications mixing this
restricted support with more general components such as
<tt>function</tt>, <tt>bind</tt> and <tt>reference_wrapper</tt>.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Move clauses 20.8.3, 20.8.9, 20.8.11 and 20.8.12
to Annex D.
</p>
<p>
Remove the requirements to conditionally derive from
<tt>unary</tt>/<tt>binary_function</tt> from <tt>function</tt>,
<tt>reference_wrapper</tt>, and the results of calling <tt>mem_fn</tt>
and <tt>bind</tt>.
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3145.html">n3145</a> would solve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3198.html">N3198</a>.





<hr>
<h3><a name="1399"></a>1399. [FCD] <tt>function</tt> does not need an <tt>explicit</tt> default constructor</h3>
<p><b>Section:</b> 20.8.14.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-3</b></p>
<p>
<tt>explicit</tt> default contructor is defined in <tt>std::function</tt>.
Although it is allowed according to 12.3.1, it seems
unnecessary to qualify the constructor as <tt>explicit</tt>.
If it is <tt>explicit</tt>, there will be a limitation in <tt>initializer_list</tt>.
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Remove <tt>explicit</tt>.
<pre>namespace std {
template&lt;class&gt; class function;
// undefined
template&lt;class R, class... ArgTypes&gt;
class function&lt;R(ArgTypes...)&gt;
: public unary_function&lt;T1, R&gt;
// iff sizeof...(ArgTypes) == 1 and ArgTypes contains T1
: public binary_function&lt;T1, T2, R&gt;
// iff sizeof...(ArgTypes) == 2 and ArgTypes contains T1 andT2
{
public:typedef R result_type;
// 20.8.14.2.1, construct/copy/destroy:
  <del>explicit</del> function();
</pre>





<hr>
<h3><a name="1400"></a>1400. FCD <tt>function</tt> does not need an <tt>explicit</tt> default constructor</h3>
<p><b>Section:</b> 20.8.14.2.1 [func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-4</b></p>
<p>
Really does the <tt>function</tt> require that default constructor is <tt>explicit</tt>?
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Remove explicit.
<pre>function();
template &lt;class A&gt;
function(allocator_arg_t, const A&amp; a);
</pre>





<hr>
<h3><a name="1402"></a>1402. [FCD] <tt>nullptr</tt> constructors for smart pointers should be <tt>constexpr</tt></h3>
<p><b>Section:</b> 20.9 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-100</b></p>

The <tt>unique_ptr</tt> and <tt>shared_ptr</tt> constructors taking
<tt>nullptr_t</tt> delegate to a <tt>constexpr</tt> constructor, and could be
<tt>constexpr</tt> themselves.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
In the 20.9.10.2 [unique.ptr.single] synopsis add
"constexpr" to unique_ptr(nullptr_t).<br>
In the 20.9.10.3 [unique.ptr.runtime] synopsis add
"constexpr" to unique_ptr(nullptr_t).<br>
In the 20.9.11.2 [util.smartptr.shared] synopsis
add "constexpr" to shared_ptr(nullptr_t).





<hr>
<h3><a name="1403"></a>1403. [FCD] Inconsistent definitions for <tt>allocator_arg</tt></h3>
<p><b>Section:</b> 20.9.1 [allocator.tag] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-85</b></p>
<p>
There are inconsistent definitions for <tt>allocator_arg</tt>.
In 20.9 [memory] paragraph 1,
</p>
<pre>constexpr allocator_arg_t allocator_arg = allocator_arg_t();
</pre>
and in 20.9.1,
<pre>const allocator_arg_t allocator_arg = allocator_arg_t();
</pre>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Change "const" to "constexpr" in 20.9.1 as
follows.
<pre>constexpr allocator_arg_t allocator_arg = allocator_arg_t();
</pre>





<hr>
<h3><a name="1404"></a>1404. [FCD] <tt>pointer_traits</tt> should have a <tt>size_type</tt> member</h3>
<p><b>Section:</b> 20.9.3 [pointer.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-106</b></p>
<p>
<tt>pointer_traits</tt> should have a <tt>size_type</tt> member for completeness.
</p>
<p>
Add <tt>typedef <i>see below</i> size_type;</tt> to the generic
<tt>pointer_traits</tt> template and <tt>typedef size_t
size_type;</tt> to <tt>pointer_traits&lt;T*&gt;</tt>. Use
<tt>pointer_traits::size_type</tt> and
<tt>pointer_traits::difference_type</tt> as the defaults for
<tt>allocator_traits::size_type</tt> and
<tt>allocator_traits::difference_type</tt>.
</p>
<p>
See Appendix 1 - Additional Details
</p>

<p><i>[
Post-Rapperswil, Pablo provided wording:
]</i></p>


<p>
The original ballot comment reads simply: "<tt>pointer_traits</tt> should have a 
<tt>size_type</tt> for completeness."  The additional details reveal, however,
that the desire for a <tt>size_type</tt> is actually driven by the needs
of <tt>allocator_traits</tt>.  The <tt>allocator_traits</tt> template should get its
default <tt>difference_type</tt> from <tt>pointer_traits</tt> but if it did,
it should get its <tt>size_type</tt> from the same source.  Unfortunately,
there is no obvious meaning for <tt>size_type</tt> in <tt>pointer_traits</tt>.
</p>
<p>
Alisdair suggested, however, that the natural relationship between
<tt>difference_type</tt> and <tt>size_type</tt> can be expressed simply by the
<tt>std::make_unsigned&lt;T&gt;</tt> metafunction.  Using this metafunction,
we can easily define <tt>size_type</tt> for <tt>allocator_traits</tt> without
artificially adding <tt>size_type</tt> to <tt>pointer_traits</tt>.
</p>

<blockquote>
Moved to Tentatively Ready after 6 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>





<p><b>Proposed resolution:</b></p>
<p>
In [allocator.requirements], Table 42, change two rows as follows:
</p>
<blockquote>
<table border="1">
  <tbody><tr>
    <td><tt>X::size_type</tt></td>
    <td>unsigned integral type</td>
    <td>a type that can represent the size of the largest object in the
    allocation model</td>
    <td><tt>
      <del>size_t</del>
      <ins>make_unsigned&lt;X::difference_type&gt;::type</ins>
    </tt></td>
  </tr>
  <tr>
    <td><tt>X::difference_type</tt></td>
    <td>signed integral type</td>
    <td>a type that can represent the difference between any two pointers in
    the allocation model</td>
    <td><tt>
      <del>ptrdiff_t</del>
      <ins>pointer_traits&lt;X::pointer&gt;::difference_type</ins>
    </tt></td>
  </tr>
</tbody></table>
</blockquote>
<p>
In [allocator.traits.types], Change the definition of difference_type and
size_type as follows:
</p>
<blockquote>
  <tt>typedef</tt> <i>see below</i> <tt>difference_type;</tt>
  <blockquote>
    <i>Type:</i> <tt>Alloc::difference_type</tt> if such a type exists,
    else <tt><del>ptrdiff_t</del>
    <ins>pointer_traits&lt;pointer&gt;::difference_type</ins></tt>.
  </blockquote>

  <tt>typedef</tt> <i>see below</i> <tt>size_type;</tt>
  <blockquote>
    <i>Type:</i> <tt>Alloc::size_type</tt> if such a type exists,
    else <tt><del>size_t</del>
    <ins>make_unsigned&lt;difference_type&gt;::type</ins></tt>.
  </blockquote>
</blockquote>





<hr>
<h3><a name="1405"></a>1405. [FCD] Ballot Comment US-107</h3>
<p><b>Section:</b> 20.10 [allocator.adaptor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.adaptor">issues</a> in [allocator.adaptor].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-107</b></p>

scoped_allocator_adaptor should have its own header.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
See Appendix 1 - Additional Details





<hr>
<h3><a name="1407"></a>1407. [FCD] Synch <tt>shared_ptr</tt> constructors taking movable types</h3>
<p><b>Section:</b> 20.9.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-108</b></p>

<tt>shared_ptr</tt> should have the same policy for constructing
from <tt>auto_ptr</tt> as <tt>unique_ptr</tt>. Currently it does not.

<p><i>[
Resolved in Rapperswil by paper N3109.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add �template &lt;class Y&gt; explicit
shared_ptr(auto_ptr&lt;Y&gt;&amp;); to
[util.smartptr.shared.const] (and to the synopsis).





<hr>
<h3><a name="1409"></a>1409. [FCD] Specify whether <tt>monotonic_clock</tt> is a distinct type or a typedef</h3>
<p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.monotonic">issues</a> in [time.clock.monotonic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-111</b></p>
<p>
What it means for <tt>monotonic_clock</tt> to be a synonym is
undefined. If it may or may not be a typedef, then certain
classes of programs become unportable.
</p>

<p><i>[
Resolution proposed in ballot comment:
]</i></p>

<p>
Require that it be a distinct class type.
</p>

<p><i>[
2010-11-01 Daniel comments:
]</i></p>

<blockquote>
Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3128</a> addresses
this issue by replacing <tt>monotonic_clock</tt> with <tt>steady_clock</tt>, which is not a typedef.
</blockquote>



<p><b>Proposed resolution:</b></p>
This is resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.





<hr>
<h3><a name="1410"></a>1410. [FCD] Add a feature-detect macro for <tt>monotonic_clock</tt></h3>
<p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.monotonic">issues</a> in [time.clock.monotonic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1411">1411</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-107, DE-20</b></p>
<p>
1.4 [intro.compliance] p.9 states that which conditionally
supported constructs are available should be provided in the 
documentation for the implementation. This doesn't help programmers trying
to write portable code, as they must then rely on
implementation-specific means to determine the
availability of such constructs. In particular, the presence
or absence of <tt>std::chrono::monotonic_clock</tt> may require
different code paths to be selected. This is the only
conditionally-supported library facility, and differs from the
conditionally-supported language facilities in that it has
standard-defined semantics rather than implementation-defined
semantics.
</p>

<p><i>[
Resolution proposed in ballot comment:
]</i></p>

<p>
Provide feature test macro for determining the
presence of <tt>std::chrono::monotonic_clock</tt>. Add
<tt>_STDCPP_HAS_MONOTONIC_CLOCK</tt> to the
<tt>&lt;chrono&gt;</tt> header, which is defined if
<tt>monotonic_clock</tt> is present, and not defined if it is
not present.
</p>

<p><i>[
2010-11-01 Daniel comments:
]</i></p>

<blockquote>
Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3128</a> addresses
this issue by replacing <tt>monotonic_clock</tt> with <tt>steady_clock</tt>, which is not conditionally supported,
so there is no need to detect it.
</blockquote>



<p><b>Proposed resolution:</b></p>
This is resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.





<hr>
<h3><a name="1412"></a>1412. [FCD] Make monotonic clocks mandatory</h3>
<p><b>Section:</b> X [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.monotonic">issues</a> in [time.clock.monotonic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses CH-21</b></p>
<p>
Monotonic clocks are generally easy to provide on all
systems and are implicitely required by some of the library
facilities anyway.
</p>

<p><i>[
2010-11-01 Daniel comments:
]</i></p>

<blockquote>
Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3128</a> addresses
this issue by replacing <tt>monotonic_clock</tt> with <tt>steady_clock</tt>, which is mandatory.
</blockquote>

<p><i>[
2010-11-13 Batavia meeting:
]</i></p>

<p>
This is resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.
The original resolution is preserved for reference:
</p>
<blockquote>
<p>Make monotonic clocks mandatory.</p>
<p>Strike X [time.clock.monotonic] p.2</p>
<blockquote>
<tt>2</tt> <del>The class <tt>monotonic_clock</tt> is conditionally supported.</del>
</blockquote>

<p>Change 30.2.4 [thread.req.timing] p.2 accordingly</p>
<blockquote>
The member functions whose names end in <tt>_for</tt> take an argument that
specifies a relative time. Implementations should use a monotonic clock to
measure time for these functions. <del>[ <em>Note</em>: Implementations are not
required to use a monotonic clock because such a clock may not be available.
� <em>end note</em> ]</del>
</blockquote>
</blockquote>



<p><b>Proposed resolution:</b></p>
This is resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.





<hr>
<h3><a name="1414"></a>1414. [FCD] Fixing remaining dead links to <tt>POS_T</tt> and <tt>OFF_T</tt></h3>
<p><b>Section:</b> 21.2.3.2 [char.traits.specializations.char16_t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1444">1444</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-109, GB-123</b></p>

<p>
It is not clear what the specification means for
u16streampos, u32streampos or wstreampos when they
refer to the requirements for POS_T in 21.2.2, as there
are no longer any such requirements. Similarly the annex
D.7 refers to the requirements of type POS_T in 27.3 that
no longer exist either.
</p>
<p>
Clarify the meaning of all cross-reference to the
removed type POS_T.
</p>


<p><i>[
Post-Rapperswil, Daniel provides the wording.
]</i></p>


<p>
When preparing the wording for this issue I first thought about adding both <tt>u16streampos</tt> and <tt>u32streampos</tt>
to the [iostream.forward] header <tt>&lt;iosfwd&gt;</tt> synopsis similar to <tt>streampos</tt> and <tt>wstreampos</tt>,
but decided not to do so, because the IO library does not yet actively support the <tt>char16_t</tt> and <tt>char32_t</tt> 
character types. Adding those would misleadingly imply that they would be part of the iostreams. Also, the addition
would make them also similarly equal to a typedef to <tt>fpos&lt;mbstate_t&gt;</tt>, as for <tt>streampos</tt> and 
<tt>wstreampos</tt>, so there is no loss for users that would like to use the proper <tt>fpos</tt> instantiation for
these character types.
</p>
<p>
Additionally the way of referencing was chosen to follow the style suggested by NB comment 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3118.html#GB108">GB 108</a>.
</p>

<blockquote>
Moved to Tentatively Ready with proposed wording after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
<i>The following wording changes are against N3126.</i>
</p>

<ol>
<li>Change [char.traits.specializations.char16_t]/1 as indicated:
<blockquote><p>
1 - The type <tt>u16streampos</tt> shall be an implementation-defined type that satisfies the requirements 
for <del><tt>POS_T</tt> in 21.2.2</del><ins><tt>pos_type</tt> in [iostreams.limits.pos]</ins>.
</p></blockquote>
</li>
<li>Change [char.traits.specializations.char32_t]/1 as indicated:
<blockquote><p>
1 - The type <tt>u32streampos</tt> shall be an implementation-defined type that satisfies the requirements 
for <del><tt>POS_T</tt> in 21.2.2</del><ins><tt>pos_type</tt> in [iostreams.limits.pos]</ins>.
</p></blockquote>
</li>
<li>Change [char.traits.specializations.wchar.t]/2 as indicated:
<blockquote><p>
2 - The type <tt>wstreampos</tt> shall be an implementation-defined type that satisfies the requirements 
for <del><tt>POS_T</tt> in 21.2.2</del><ins><tt>pos_type</tt> in [iostreams.limits.pos]</ins>.
</p></blockquote>
</li>
<li>Change [fpos.operations], Table 124 � Position type requirements as indicated:
<blockquote><p>
</p><table border="1">
<caption>Table 124 � Position type requirements</caption>

<tbody>
<tr>
<th>Expression</th>
<th>Return type</th>
<th><tt>...</tt></th>
</tr>

<tr>
<td><tt>...</tt></td>
<td><tt>...</tt></td>
<td><tt>...</tt></td>
</tr>
<tr>
<td><tt>O(p)</tt></td>
<td><del><tt>OFF_T</tt></del><ins><tt>streamoff</tt></ins></td>
<td>...</td>
</tr>
<tr>
<td><tt>...</tt></td>
<td><tt>...</tt></td>
<td><tt>...</tt></td>
</tr>
<tr>
<td><tt>o = p - q</tt></td>
<td><del><tt>OFF_T</tt></del><ins><tt>streamoff</tt></ins></td>
<td><tt>...</tt></td>
</tr>
<tr>
<td><tt>streamsize(o)</tt><br><tt>O(sz)</tt></td>
<td><tt>streamsize</tt><br><del><tt>OFF_T</tt></del><ins><tt>streamoff</tt></ins></td>
<td><tt>...</tt></td>
</tr>

</tbody></table>
<p></p></blockquote>
</li>
<li>Change [depr.ios.members]/1 as indicated:
<p>
</p><blockquote><pre>namespace std {
 class ios_base {
 public:
   typedef T1 io_state;
   typedef T2 open_mode;
   typedef T3 seek_dir;
   typedef <del>OFF_T</del><ins><em>implementation-defined</em></ins> streamoff;
   typedef <del>POS_T</del><ins><em>implementation-defined</em></ins> streampos;
   // remainder unchanged
 };
}
</pre></blockquote>
<p></p>
</li>
<li>Change [depr.ios.members]/5+6 as indicated:
<blockquote><p>
5 - The type <tt>streamoff</tt> is an implementation-defined type that satisfies the requirements 
of <del>type <tt>OFF_T</tt> (27.5.1)</del><ins><tt>off_type</tt> in [iostreams.limits.pos]</ins>.
</p>
<p>
6 - The type <tt>streampos</tt> is an implementation-defined type that satisfies the requirements 
of <del>type <tt>POS_T</tt> (27.3)</del><ins><tt>pos_type</tt> in [iostreams.limits.pos]</ins>.
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="1416"></a>1416. [FCD] <tt>forward_list::erase_after</tt> should not be allowed to throw</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> DIN <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses DE-21</b></p>

23.2.1/11 provides a general no-throw guarantee for
erase() container functions, exceptions from this are
explicitly mentioned for individual containers. Because of
its different name, forward_list's erase_after() function is
not ruled by this but should so.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Add a "<i>Throws</i>: Nothing" clause to both
<tt>erase_after</tt> overloads in 23.3.3.4, [forwardlist.modifiers].
</p>





<hr>
<h3><a name="1417"></a>1417. [FCD] <tt>front</tt>/<tt>back</tt> on a zero-sized
<tt>array</tt> should be undefined</h3>
<p><b>Section:</b> 23.3.1.7 [array.zero] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-26</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-112</b></p>
<p>
Should the effect of calling <tt>front</tt>/<tt>back</tt> on a zero-sized
<tt>array</tt> really be implementation defined i.e. require the
implementor to define behaviour?
</p>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Change "implementation defined" to "undefined"





<hr>
<h3><a name="1423"></a>1423. [FCD] Ballot Comment JP-6</h3>
<p><b>Section:</b> 23.6.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-6</b></p>

Constructor accepting an allocator as a single parameter
should be qualified as explicit.
<pre>namespace std {
template &lt;class Key, class T, class Compare =
less&lt;Key&gt;,
class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
class map {
public:
...
map(const Allocator&amp;);
</pre>

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add explicit.
<pre>namespace std {
template &lt;class Key, class T, class Compare =
less&lt;Key&gt;,
class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
class map {
public:
...
explicit map(const Allocator&amp;);
</pre>





<hr>
<h3><a name="1424"></a>1424. [FCD] Ballot Comment JP-7</h3>
<p><b>Section:</b> 23.6.2 [multimap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
Constructor accepting an allocator as a single parameter
should be qualified as explicit.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add explicit.
<pre>namespace std {
template &lt;class Key, class T, class Compare =
less&lt;Key&gt;,
class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
class multimap {
public:
...
explicit multimap(const Allocator&amp;);
</pre>





<hr>
<h3><a name="1425"></a>1425. [FCD] Ballot Comment JP-8</h3>
<p><b>Section:</b> 23.6.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-8</b></p>
Constructor accepting an allocator as a single parameter
should be qualified as explicit.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add explicit.
<pre>namespace std {
template &lt;class Key, class Compare = less&lt;Key&gt;,
class Allocator = allocator&lt;Key&gt; &gt;
class set {
public:
...
explicit set(const Allocator&amp;);
</pre>





<hr>
<h3><a name="1426"></a>1426. [FCD] Ballot Comment JP-9</h3>
<p><b>Section:</b> 23.6.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-9</b></p>

Constructor accepting an allocator as a single parameter
should be qualified as explicit.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add explicit.
<pre>namespace std {
template &lt;class Key, class Compare = less&lt;Key&gt;,
class Allocator = allocator&lt;Key&gt; &gt;
class multiset {
public:
...
explicit multiset(const Allocator&amp;);
</pre>





<hr>
<h3><a name="1427"></a>1427. [FCD] Ballot Comment JP-10</h3>
<p><b>Section:</b> 23.7.1 [unord.map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.map">issues</a> in [unord.map].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-10</b></p>

Constructor accepting an allocator as a single parameter
should be qualified as explicit.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add explicit.
<pre>namespace std {
template &lt;class Key,
template &lt;class Key,
class T,
class Hash = hash&lt;Key&gt;,
class Pred = std::equal_to&lt;Key&gt;,
class Alloc = std::allocator&lt;std::pair&lt;const Key,
T&gt; &gt; &gt;
class unordered_map
{
public:
...
explicit unordered_map(const Allocator&amp;);
</pre>





<hr>
<h3><a name="1428"></a>1428. [FCD] Ballot Comment JP-11</h3>
<p><b>Section:</b> 23.7.2 [unord.multimap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-11</b></p>

Constructor accepting an allocator as a single parameter
should be qualified as explicit.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add explicit.
<pre>namespace std {
template &lt;class Key,
class T,
class Hash = hash&lt;Key&gt;,
class Pred = std::equal_to&lt;Key&gt;,
class Alloc = std::allocator&lt;std::pair&lt;const Key,
T&gt; &gt; &gt;
class unordered_multimap
{
public:
...
explicit unordered_multimap(const Allocator&amp;);
</pre>





<hr>
<h3><a name="1429"></a>1429. [FCD] Ballot Comment JP-12</h3>
<p><b>Section:</b> 23.7.3 [unord.set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-12</b></p>

Constructor accepting an allocator as a single parameter
should be qualified as explicit.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add explicit.
<pre>namespace std {
template &lt;class Key,
class Hash = hash&lt;Key&gt;,
class Pred = std::equal_to&lt;Key&gt;,
class Alloc = std::allocator&lt;Key&gt; &gt;
class unordered_set
{
public:
...
explicit unordered_set(const Allocator&amp;);
</pre>





<hr>
<h3><a name="1430"></a>1430. [FCD] Ballot Comment JP-13</h3>
<p><b>Section:</b> 23.7.4 [unord.multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP-13</b></p>

Constructor accepting an allocator as a single parameter
should be qualified as explicit.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Add explicit.
<pre>namespace std {
template &lt;class Key,
class Hash = hash&lt;Key&gt;,
class Pred = std::equal_to&lt;Key&gt;,
class Alloc = std::allocator&lt;Key&gt; &gt;
class unordered_multiset
{
public:
...
explicit unordered_multiset(const Allocator&amp;);
</pre>





<hr>
<h3><a name="1431"></a>1431. [FCD] Ballot Comment US-120</h3>
<p><b>Section:</b> 25.2.12 [alg.is_permutation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-120</b></p>

is_permutation is underspecified for anything but the
simple case where both ranges have the same value type
and the comparison function is an equivalence relation.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
Restrict is_permutation to the case where it is well
specified. See Appendix 1 - Additional Details





<hr>
<h3><a name="1432"></a>1432. [FCD] random_shuffle signatures</h3>
<p><b>Section:</b> 25.3.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1433">1433</a></p>
<p><b>Discussion:</b></p>

<p><b>Addresses US-121, GB-119</b></p>

<p>
<tt>random_shuffle</tt> and <tt>shuffle</tt> should be consistent in how
they accept their source of randomness: either both by
rvalue reference or both by lvalue reference.
</p>

<p><i>[
Post-Rapperswil, Daniel provided wording
]</i></p>


<p>
The signatures of the <tt>shuffle</tt> and <tt>random_shuffle</tt> algorithms are different
in regard to the support of rvalues and lvalues of the provided generator:
</p>

<p>
</p><blockquote><pre>template&lt;class RandomAccessIterator, class RandomNumberGenerator&gt;
void random_shuffle(RandomAccessIterator first,
RandomAccessIterator last,
RandomNumberGenerator<b>&amp;&amp;</b> rand);
</pre></blockquote>
<p></p>

<p>
</p><blockquote><pre>template&lt;class RandomAccessIterator, class UniformRandomNumberGenerator&gt;
void shuffle(RandomAccessIterator first,
RandomAccessIterator last,
UniformRandomNumberGenerator<b>&amp;</b> g);
</pre></blockquote>
<p></p>

<p>
The first form uses the perfect forwarding signature and that change compared to
<tt>C++03</tt> was done intentionally as shown in the first rvalue proposal 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Improved%20random_shuffle">papers</a>.
</p>

<p>
While it is true, that random generators are excellent examples of stateful
functors, there still exist good reasons to support rvalues as arguments:
</p>

<p>
</p><ol>
<li>If one of the shuffle algorithms is called with the intention to shuffle items with a reproducible ordering 
	from a given generator class, it makes sense to create a generator exactly at the call point.
</li>
<li>Other algorithms with similar need for stateful functors (like <tt>std::generate</tt> and <tt>std::generate_n</tt>) 
	accept both rvalues and lvalues as well.
</li>
<li>Given the deduction rules for perfect forwarding it is hard for a user to produce code that does the wrong thing 
unintentionally. Any lvalue generator will deduce an lvalue-reference and behave as in <tt>C++03</tt>. In the specific 
cases, where rvalues are provided, the argument will be accepted instead of being rejected.
</li>
</ol>
<p></p>

<p>
Arguments have been raised that accepting rvalues is error-prone or even fundamentally wrong. The author of this 
proposal disagrees with that position for two additional reasons:
</p>

<p>
</p><ol>
<li>Enforcing lvalues as arguments won't prevent user code to enforce what they
want. So given
<blockquote><pre>my_generator get_generator(int size);
</pre></blockquote>
instead of writing
<blockquote><pre>std::vector&lt;int&gt; v = ...;
std::shuffle(v.begin(), v.end(), get_generator(v.size()));
</pre></blockquote>
they will just write
<blockquote><pre>std::vector&lt;int&gt; v = ...;
auto gen = get_generator(v.size());
std::shuffle(v.begin(), v.end(), gen);
</pre></blockquote>
and feel annoyed about the need for it.
</li>
<li>Generators may be copyable and movable, and random number engines are <em>required</em> to be <tt>CopyConstructible</tt> 
and this is obviously a generally useful property for such objects. It is also useful and sometimes necessary to start a 
generator with exactly a specific seed again and again and thus to provide a new generator (or a copy) for each call. The 
<tt>CopyConstructible</tt> requirements allow providing rvalues of generators and thus this idiom must be useful as well. 
Therefore preventing <tt>[random_]shuffle</tt> to accept rvalues is an unnecessary restriction which doesn't prevent any 
user-error, if there would exist one.
</li>
</ol>
<p></p>

<p>
Thus this proposal recommends to make both <tt>shuffle</tt> functions consistent and perfectly forward-able.
</p>

<blockquote>
Moved to Tentatively Ready after 6 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<ol>
<li>Change [algorithms.general], header <tt>&lt;algorithm&gt;</tt> synopsis as indicated:
<blockquote><pre>template&lt;class RandomAccessIterator, class UniformRandomNumberGenerator&gt;
void shuffle(RandomAccessIterator first, RandomAccessIterator last,
UniformRandomNumberGenerator&amp;<ins>&amp;</ins> rand);
</pre></blockquote>
</li>
<li>Change the prototype description of [alg.random.shuffle] as indicated:
<blockquote><pre>template&lt;class RandomAccessIterator, class UniformRandomNumberGenerator&gt;
void shuffle(RandomAccessIterator first, RandomAccessIterator last,
UniformRandomNumberGenerator&amp;<ins>&amp;</ins> rand);
</pre></blockquote>
</li>
</ol>






<hr>
<h3><a name="1435"></a>1435. [FCD] Unclear returns specifications for C99 complex number functions</h3>
<p><b>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-120</b></p>

The complex number functions added for compatibility
with the C99 standard library are defined purely as a
cross-reference, with no hint of what they should return.
This is distinct from the style of documentation for the
functions in the earlier standard. In the case of the
inverse-trigonometric and hyperbolic functions, a
reasonable guess of the functionality may be made from
the name, this is not true of the cproj function, which
apparently returns the projection on the Reimann Sphere.
A single line description of each function, associated with
the cross-reference, will greatly improve clarity.

<p><i>[2010-11-06 Beman provides proposed resolution wording.]</i></p>


<p><i>[
2010 Batavia: The working group concurred with the issue's Proposed Resolution
]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>Change 26.4.7 complex value operations [complex.value.ops] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i> the projection of <tt>x</tt> onto the Riemann 
    sphere.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cproj</tt>, 
    defined in 7.3.9.4.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; acos(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc cosine  of <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cacos</tt>, 
    defined in 7.3.5.1.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; asin(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc sine  of <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>casin</tt>, 
    defined in 7.3.5.2.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; atan(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc tangent  of <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>catan</tt>, 
    defined in 7.3.5.3.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; acosh(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic cosine of
    <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>cacosh</tt>, 
    defined in 7.3.6.1.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; asinh(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic sine  of <tt>
    x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>casinh</tt>, 
    defined in 7.3.6.2.</p>
  </blockquote>
</blockquote>

<p><i>Change 26.4.8 complex transcendentals [complex.transcendentals] as indicated:</i></p>
<blockquote>
  <p><tt>template&lt;class T&gt; complex&lt;T&gt; atanh(const complex&lt;T&gt;&amp; x);</tt></p>
  <blockquote>
    <p><ins><i>Returns:</i>&nbsp; the complex arc hyperbolic tangent  of
    <tt>x</tt>.</ins></p>
    <p><del><i>Effects:</i></del> <ins><i>Remarks:</i></ins> Behaves the same as the C function <tt>catanh</tt>, 
    defined in 7.3.6.2.</p>
  </blockquote>
</blockquote>







<hr>
<h3><a name="1436"></a>1436. [FCD] Random number engine constructor concerns</h3>
<p><b>Section:</b> 26.5.3 [rand.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-121</b></p>

All the random number engine types in this clause have a
constructor taking an unsigned integer type, and a
constructor template for seed sequences. This means that
an attempt to create a random number engine seeded by
an integer literal must remember to add the appropriate
unsigned suffix to the literal, as a signed integer will
attempt to use the seed sequence template, yielding
undefined behaviour, as per 26.5.1.1p1a. It would be
helpful if at least these anticipated cases produced a
defined behaviour, either an erroneous program with
diagnostic, or a conversion to unsigned int forwarding to
the appropriate constructor.

<p><i>[
2010-11-03 Daniel comments and provides a proposed resolution:
]</i></p>


<p>
I suggest to apply a similar solution as recently suggested for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1234">1234</a>.
It is basically a requirement for an implementation to constrain the template.
</p>

<p><i>[
2010-11-04 Howard suggests to use <tt>!is_convertible&lt;Sseq, result_type&gt;::value</tt>
as minimum requirement instead of the originally proposed <tt>!is_scalar&lt;Sseq&gt;::value</tt>.
This would allow for a user-defined type <tt>BigNum</tt>, that is convertible to <tt>result_type</tt>,
to be used as argument for a seed instead of a seed sequence. The wording has been updated to 
reflect this suggestion.
]</i></p>


<p><i>[
2010 Batavia: There were some initial concerns regarding the portability and reproducibility of results 
when seeded with a negative signed value, but these concerns were allayed after discussion. Thus, after
reviewing the issue, the working group concurred with the issue's Proposed Resolution. 
]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
Add the following paragraph at the end of 26.5.3 [rand.eng]:
<blockquote>
<blockquote>
5 Each template specified in this section [rand.eng] requires one or more relationships, involving the value(s) of
its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.
</blockquote>

<blockquote>
<ins>? For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this sub-clause 
[rand.eng] and in sub-clause [rand.adapt]:</ins>
<ul>
<li><ins>If the constructor</ins>
<blockquote><pre><ins>template&lt;class Sseq&gt; explicit X(Sseq&amp; q);</ins>
</pre></blockquote>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor 
shall not participate in overload resolution.
</ins>
</li>
<li><ins>If the member function</ins>
<blockquote><pre><ins>template&lt;class Sseq&gt; void seed(Sseq&amp; q);</ins>
</pre></blockquote>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function 
shall not participate in overload resolution.
</ins>
</li>
</ul>
<ins>The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as seed sequence, if it is implicitly convertible
to <tt>X::result_type</tt>.</ins>
</blockquote>

</blockquote>





<hr>
<h3><a name="1437"></a>1437. [FCD] Mersenne twister meaningless for word sizes less than two</h3>
<p><b>Section:</b> 26.5.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-124</b></p>

The Mersenne twister algorithm is meaningless for word
sizes less than two, as there are then insufficient bits
available to be �twisted�.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
Insert the following among the relations that are required to hold: <tt>2u &lt; w</tt>.
</blockquote>

<p><i>[
2010 Batavia: The working group concurred with the issue's Proposed Resolution
]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
Change 26.5.3.2 [rand.eng.mers] p. 4 as indicated:
<p>
</p><blockquote>
4 The following relations shall hold: <tt>0 &lt; m</tt>, <tt>m &lt;= n</tt>, <ins><tt>2u &lt; w</tt>,</ins>
<tt>r &lt;= w</tt>, <tt>u &lt;= w</tt>, <tt>s &lt;= w</tt>, <tt>t &lt;= w</tt>, 
<tt>l &lt;= w</tt>, <tt>w &lt;= numeric_limits&lt;UIntType&gt;::digits</tt>, 
<tt>a &lt;= (1u&lt;&lt;w) - 1u</tt>, <tt>b &lt;= (1u&lt;&lt;w) - 1u</tt>, 
<tt>c &lt;= (1u&lt;&lt;w) - 1u</tt>, <tt>d &lt;= (1u&lt;&lt;w) - 1u</tt>, 
and <tt>f &lt;= (1u&lt;&lt;w) - 1u</tt>.
</blockquote>





<hr>
<h3><a name="1439"></a>1439. [FCD] Return from <tt>densities()</tt> functions?</h3>
<p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-134</b></p>

These two distributions have a member function called
<tt>densities()</tt> which returns a <tt>vector&lt;double&gt;</tt>. The
distribution is templated on <tt>RealType</tt>. The distribution
also has another member called <tt>intervals()</tt> which returns
a <tt>vector&lt;RealType&gt;</tt>. Why doesn't densities return
<tt>vector&lt;RealType&gt;</tt> as well? If <tt>RealType</tt> is <tt>long double</tt>,
the computed densities property isn't being computed to
the precision the client desires. If <tt>RealType</tt> is <tt>float</tt>, the
densities vector is taking up twice as much space as the client desires.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
Change the piecewise constant and linear
distributions to hold / return the densities in a
<tt>vector&lt;result_type&gt;</tt>.
<p>
If this is not done, at least correct 26.5.8.5.2 [rand.dist.samp.pconst] p. 13 which describes
the return of densities as a <tt>vector&lt;result_type&gt;</tt>.
</p></blockquote>

<p><i>[
Batavia 2010: After reviewing this issue, the working group concurred with the first of the 
suggestions proposed by the NB comment: "Change the piecewise constant and linear distributions 
to hold / return the densities in a vector. "
]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>Change 26.5.8.5.2 [rand.dist.samp.pconst] p. 2, class template <tt>piecewise_constant_distribution</tt> synopsis
and the prototype description 26.5.8.5.2 [rand.dist.samp.pconst] before p. 13 as indicated:
<blockquote><pre>vector&lt;<del>double</del><ins>result_type</ins>&gt; densities() const;
</pre></blockquote>
</li>

<li>Change 26.5.8.5.3 [rand.dist.samp.plinear] p. 2, class template <tt>piecewise_linear_distribution</tt> synopsis
and the prototype description 26.5.8.5.3 [rand.dist.samp.plinear] before p. 13 as indicated:
<blockquote><pre>vector&lt;<del>double</del><ins>result_type</ins>&gt; densities() const;
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="1440"></a>1440. [FCD] Incorrect specification for rand.dist.samp.plinear</h3>
<p><b>Section:</b> 26.5.8.5.3 [rand.dist.samp.plinear] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-135</b></p>

This paragraph says: Let bk = xmin+k�&#948; for k = 0,...,n,
and wk = fw(bk +&#948;) for k = 0,...,n.
However I believe that fw(bk) would be far more desirable.
I strongly suspect that this is nothing but a type-o.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
Change p. 10 to read:<br>
Let bk = xmin+k�&#948; for k = 0,...,n, and wk = fw(bk)
for k = 0,...,n.
</blockquote>

<p><i>[
2010-11-02 Daniel translates into a proposed resolution
]</i></p>


<p><i>[
2010 Batavia: The working group concurred with the issue's Proposed Resolution
]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
Change 26.5.8.5.3 [rand.dist.samp.plinear] p. 10 as indicated:
<blockquote>
10 <em>Effects</em>: Constructs a <tt>piecewise_linear_distribution</tt> object with parameters taken or calculated
from the following values: Let <tt><em>b<sub>k</sub></em> = xmin+<em>k</em>�&#948;</tt> for 
<tt><em>k</em> = 0, . . . , <em>n</em></tt>, and <tt><em>w<sub>k</sub></em> = fw(<em>b</em><sub><em>k</em></sub><del> +&#948;</del>)</tt> 
for <tt><em>k</em> = 0, . . . , <em>n</em></tt>.</blockquote>





<hr>
<h3><a name="1441"></a>1441. [FCD] Floating-point test functions are incorrectly specified</h3>
<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-04</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-136</b></p>

Floating-point test functions are incorrectly specified.

<p><i>[
Resolved in Rapperswil by a motion to directly apply the words from the ballot comment in N3102.
]</i></p>




<p><b>Proposed resolution:</b></p>
See Appendix 1 - Additional Details





<hr>
<h3><a name="1445"></a>1445. [FCD] Several iostreams member functions incorrectly specified</h3>
<p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS/PJ Plauger <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-137</b></p>

Several iostreams member functions are incorrectly
specified.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<p>
See Appendix 1 - Additional Details
</p>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a> would solve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a>.





<hr>
<h3><a name="1447"></a>1447. [FCD] Request to resolve issue LWG 1328</h3>
<p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-139</b></p>

Resolve issue LWG 1328 one way or the other, but
preferably in the direction outlined in the proposed
resolution, which, however, is not complete as-is: in any
case, the sentry must not set ok_ = false if is.good() ==
false, otherwise istream::seekg, being an unformatted
input function, does not take any action because the
sentry object returns false when converted to type bool.
Thus, it remains impossible to seek away from end of file.


<p><b>Proposed resolution:</b></p>
Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm">n3168</a>.





<hr>
<h3><a name="1449"></a>1449. [FCD] Incomplete specification of header <tt>&lt;cinttypes&gt;</tt></h3>
<p><b>Section:</b> 27.8.2 [istringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Canada <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses CA-4</b></p>

Subclause 27.9.2 [c.files] specifies that &lt;cinttypes&gt; has
declarations for abs() and div(); however, the signatures
are not present in this subclause. The signatures
proposed under TR1 ([tr.c99.inttypes]) are not present in
FCD (unless if intmax_t happened to be long long). It is
unclear as to which, if any of the abs() and div() functions
in [c.math] are meant to be declared by &lt;cinttypes&gt;. This
subclause mentions imaxabs() and imaxdiv(). These
functions, among other things, are not specified in FCD to
be the functions from Subclause 7.8 of the C Standard.
Finally, &lt;cinttypes&gt; is not specified in FCD to include
&lt;cstdint&gt; (whereas &lt;inttypes.h&gt; includes &lt;stdint.h&gt; in C).

<p><i>[
Post-Rapperswil, Daniel provides wording
]</i></p>


<p>
Subclause [c.files] specifies that <tt>&lt;cinttypes&gt;</tt> has declarations for <tt>abs()</tt> and <tt>div()</tt>; 
however, the signatures are not present in this subclause. The signatures proposed under TR1 ([tr.c99.inttypes]) are not 
present in FCD (unless if <tt>intmax_t</tt> happened to be <tt>long long</tt>). It is unclear as to which, if any of the 
<tt>abs()</tt> and <tt>div()</tt> functions in [c.math] are meant to be declared by <tt>&lt;cinttypes&gt;</tt>. This
subclause mentions <tt>imaxabs()</tt> and <tt>imaxdiv()</tt>. These functions, among other things, are not specified in 
FCD to be the functions from subclause 7.8 of the <tt>C</tt> Standard. Finally, <tt>&lt;cinttypes&gt;</tt> is not specified 
in FCD to include <tt>&lt;cstdint&gt;</tt> (whereas <tt>&lt;inttypes.h&gt;</tt> includes <tt>&lt;stdint.h&gt;</tt> in <tt>C</tt>).
</p>

<blockquote>
Moved to Tentatively Ready with proposed wording after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
<i>The wording refers to N3126.</i>
</p>
<ol>
<li>Add the following series of new paragraphs following [c.files] p.1:
<blockquote>
Table 132 describes header <tt>&lt;cinttypes&gt;</tt>. [<em>Note</em>: The macros defined by <tt>&lt;cinttypes&gt;</tt> are provided unconditionally.
In particular, the symbol <tt>__STDC_FORMAT_MACROS</tt>, mentioned in footnote 182 of the <tt>C</tt> standard, plays no role in <tt>C++</tt>. 
� <em>end note</em> ]
<p>
<ins>2 - The contents of header <tt>&lt;cinttypes&gt;</tt> are the same as the Standard <tt>C</tt> library header <tt>&lt;inttypes.h&gt;</tt>, 
with the following changes:</ins>
</p>
<p>
<ins>3 - The header <tt>&lt;cinttypes&gt;</tt> includes the header <tt>&lt;cstdint&gt;</tt> instead of <tt>&lt;stdint.h&gt;</tt>.</ins>
</p>
<p>
<ins>4 - If and only if the type <tt>intmax_t</tt> designates an extended integer type ([basic.fundamental]), the following function 
signatures are added:
</ins></p><blockquote><pre><ins>intmax_t abs(intmax_t);</ins>
<ins>imaxdiv_t div(intmax_t, intmax_t);</ins>
</pre></blockquote>
<ins>which shall have the same semantics as the function signatures <tt>intmax_t imaxabs(intmax_t)</tt> and 
<tt>imaxdiv_t imaxdiv(intmax_t, intmax_t)</tt>, respectively.</ins>

<p></p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="1453"></a>1453. [FCD] Default constructed match_results behavior for certain operations </h3>
<p><b>Section:</b> 28.10.4 [re.results.acc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results.acc">issues</a> in [re.results.acc].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-126</b></p>

It's unclear how match_results should behave if it has
been default-constructed. The sub_match objects
returned by operator[], prefix and suffix cannot point to the
end of the sequence that was searched if no search was
done. The iterators held by unmatched sub_match objects
might be singular.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>


<blockquote>
Add to match_results::operator[],
match_results::prefix and match_results::suffix:<br>
Requires: !empty()
</blockquote>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3158.html">n3158</a> would solve this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3158.html">n3158</a>.





<hr>
<h3><a name="1455"></a>1455. [FCD] C language compatibility for atomics</h3>
<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1454">1454</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses CH-22, GB-128</b></p>
<p>
WG14 currently plans to introduce atomic facilities that are
intended to be compatible with the facilities of clause 29.
They should be compatible.
</p>

<p><i>[
Resolution proposed by ballot comment
]</i></p>

<p>
Make sure the headers in clause 29 are defined in
a way that is compatible with the planned C
standard.
</p>

<p><i>[
2010 Batavia
]</i></p>

<p>
Resolved by adoption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
</p>


<p><b>Proposed resolution:</b></p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.





<hr>
<h3><a name="1462"></a>1462. [FCD] Ambiguous value assignment to <tt>atomic_bool</tt></h3>
<p><b>Section:</b> 29.5.1 [atomics.types.integral] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.integral">issues</a> in [atomics.types.integral].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1463">1463</a></p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-132, US-157</b></p>

The <tt>atomic_<em>itype</em></tt> types and <tt>atomic_address</tt> have two
overloads of <tt>operator=</tt>; one is <tt>volatile</tt> qualified, and the
other is not. <tt>atomic_bool</tt> only has the <tt>volatile</tt> qualified
version:
<pre><blockquote>
bool operator=(bool) volatile;
</blockquote></pre>
On a non-<tt>volatile</tt>-qualified object this is ambiguous with
the deleted copy-assignment operator
<pre><blockquote>
atomic_bool&amp; operator=(atomic_bool const&amp;) = delete;
</blockquote></pre>
due to the need for a single standard conversion in each
case when assigning a bool to an <tt>atomic_bool</tt> as in:
<pre><blockquote>
atomic_bool b;
b = true;
</blockquote></pre>
The conversions are: 
<pre><blockquote>
atomic_bool&amp; &#8594; atomic_bool volatile&amp;
</blockquote></pre>
 vs 
<pre><blockquote>
bool &#8594; atomic_bool
</blockquote></pre>

<p><i>[
Proposed resolution as of NB comment:
]</i></p>


<p>
Change 29.5.1 [atomics.types.integral] as indicated:

</p><blockquote><pre>namespace std {
  typedef struct atomic_bool {
    [..]
    bool operator=(bool) volatile;
    <ins>bool operator=(bool);</ins>
  } atomic_bool;
  [..]
}
</pre></blockquote>
<p></p>

<p><i>[
2010-10-27 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue
by replacing <tt>atomic_bool</tt> by <tt>atomic&lt;bool&gt;</tt>.
</blockquote>

<p><i>[
2010 Batavia
]</i></p>

<p>
Resolved by adoption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
</p>


<p><b>Proposed resolution:</b></p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.





<hr>
<h3><a name="1464"></a>1464. [FCD] Underspecified typedefs for atomic integral types</h3>
<p><b>Section:</b> 29.5.1 [atomics.types.integral] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.integral">issues</a> in [atomics.types.integral].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-160</b></p>

The last sentence of 29.5.1 [atomics.types.integral] p.1 says:
<blockquote><p>
Table 143 shows typedefs to atomic integral classes and the corresponding <tt>&lt;cstdint&gt;</tt> typedefs.
</p></blockquote>
That's nice, but nothing says these are supposed to be part of the implementation, and
they are not listed in the synopsis.

<p><i>[
Proposed resolution as of NB comment
]</i></p>


<p>
</p><ol>
<li>Remove Table 143 � Atomics for standard typedef types.
<p>
</p>
</li>
<li>Change 29.5.1 [atomics.types.integral] p.1 as indicated:
<blockquote><p>
1 The name <tt>atomic_<em>itype</em></tt> and the functions operating on it in the preceding synopsis are placeholders for a
set of classes and functions. Throughout the preceding synopsis, <tt>atomic_<em>itype</em></tt> should be replaced by each
of the class names in Table 142 and integral should be replaced by the integral type corresponding to the
class name. <del>Table 143 shows typedefs to atomic integral classes and the corresponding <tt>&lt;cstdint&gt;</tt> typedefs.</del>
</p></blockquote>
</li>
</ol>
<p></p>

<p><i>[
2010-10-27 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue.
</blockquote>

<p><i>[
2010-11 Batavia
]</i></p>

<p>
Resolved by adopting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
</p>



<p><b>Proposed resolution:</b></p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.





<hr>
<h3><a name="1465"></a>1465. [FCD] Missing arithmetic operators for <tt>atomic_address</tt></h3>
<p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-161</b></p>

<tt>atomic_address</tt> has <tt>operator+=</tt> and <tt>operator-=</tt>, but no
<tt>operator++</tt> or <tt>operator--</tt>. The template specialization
<tt>atomic&lt;Ty*&gt;</tt> has all of them.

<p><i>[
2010-10-27 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue by
replacing <tt>atomic_address</tt> by <tt>atomic&lt;void*&gt;</tt>.
</blockquote>

<p><i>[
Resolved in Batavia by accepting 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>Change 29.5.2 [atomics.types.address], class <tt>atomic_address</tt> synopsis, as indicated:
</p><blockquote><pre>namespace std {
  typedef struct atomic_address {
    [..]
    void* operator=(const void*) volatile;
    void* operator=(const void*);
    <ins>void* operator++(int) volatile;</ins>
    <ins>void* operator++(int);</ins>
    <ins>void* operator--(int) volatile;</ins>
    <ins>void* operator--(int);</ins>
    <ins>void* operator++() volatile;</ins>
    <ins>void* operator++();</ins>
    <ins>void* operator--() volatile;</ins>
    <ins>void* operator--();</ins>
    void* operator+=(ptrdiff_t) volatile;
    void* operator+=(ptrdiff_t);
    void* operator-=(ptrdiff_t) volatile;
    void* operator-=(ptrdiff_t);
  } atomic_address;
  [..]
}
</pre></blockquote>
<p></p>






<hr>
<h3><a name="1466"></a>1466. [FCD] Silent <tt>const</tt> breakage by <tt>compare_exchange_*</tt> member functions</h3>
<p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-162</b></p>

The <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> member functions that take
<tt>const void*</tt> arguments lead to a silent removal of <tt>const</tt>, because the <tt>load</tt> 
member function and other acessors return the stored value as a <tt>void*</tt>.

<p><i>[
Proposed resolution as of NB comment:
]</i></p>


<p>
Change 29.5.2 [atomics.types.address], class <tt>atomic_address</tt> synopsis, as indicated:

</p><blockquote><pre>namespace std {
  typedef struct atomic_address {
    [..]
    <del>bool compare_exchange_weak(const void*&amp;, const void*,
      memory_order, memory_order) volatile;</del>
    <del>bool compare_exchange_weak(const void*&amp;, const void*,
      memory_order, memory_order);</del>
    <del>bool compare_exchange_strong(const void*&amp;, const void*,
      memory_order, memory_order) volatile;</del>
    <del>bool compare_exchange_strong(const void*&amp;, const void*,
      memory_order, memory_order);</del>
    <del>bool compare_exchange_weak(const void*&amp;, const void*,
      memory_order = memory_order_seq_cst) volatile;</del>
    <del>bool compare_exchange_weak(const void*&amp;, const void*,
      memory_order = memory_order_seq_cst);</del>
    <del>bool compare_exchange_strong(const void*&amp;, const void*,
      memory_order = memory_order_seq_cst) volatile;</del>
    <del>bool compare_exchange_strong(const void*&amp;, const void*,
      memory_order = memory_order_seq_cst);</del>
    [..]
  } atomic_address;
  [..]
}
</pre></blockquote>

<p></p>

<p><i>[
2010-10-27 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> 
would solve this issue by replacing <tt>atomic_address</tt> by <tt>atomic&lt;void*&gt;</tt>.
</blockquote>

<p><i>[
Resolved in Batavia by accepting 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
]</i></p>




<p><b>Proposed resolution:</b></p>
Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.





<hr>
<h3><a name="1467"></a>1467. [FCD] Deriving <tt>atomic&lt;T*&gt;</tt> from <tt>atomic_address</tt> breaks type safety</h3>
<p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-163</b></p>

Requiring <tt>atomic&lt;T*&gt;</tt> to be derived from <tt>atomic_address</tt> breaks type safety:
<blockquote><pre>atomic&lt;double*&gt; ip;
char ch;
atomic_store(&amp;ip, &amp;ch);
*ip.load() = 3.14159;
</pre></blockquote>
The last line overwrites <tt>ch</tt> with a value of type <tt>double</tt>.

<p><i>[
2010-10-27 Daniel adds:
]</i></p>


<blockquote>
<p>
Resolving this issue will also solve <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1469">1469</a>
</p>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue by
removing <tt>atomic_address</tt>.
</blockquote>
<p><i>[
Resolved in Batavia by accepting 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
]</i></p>



<p><b>Proposed resolution:</b></p>
<ol>
<li>Change 29.5 [atomics.types.generic], class template specialization <tt>atomic&lt;T*&gt;</tt> synopsis, as indicated:
<blockquote><pre>namespace std {
  template &lt;class T&gt; struct atomic&lt;T*&gt; <del>: atomic_address</del> {
    [..]
  };
  [..]
}
</pre></blockquote>
</li>
<li>Change 29.5 [atomics.types.generic] p. 4 as indicated:
<p></p><blockquote>
4 There are pointer partial specializations on the <tt>atomic</tt> class template. <del>These specializations shall be publicly
derived from <tt>atomic_address</tt>.</del> The unit of addition/subtraction for these specializations shall be the size
of the referenced type. These specializations shall have trivial default constructors and trivial destructors.
</blockquote><p></p>
</li>
</ol>






<hr>
<h3><a name="1468"></a>1468. [FCD] <tt>atomic_address::compare_exchange_*</tt> member functions should match <tt>atomic_compare_exchange_*</tt> free functions</h3>
<p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.address">issues</a> in [atomics.types.address].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-164</b></p>

<tt>atomic_address</tt> has member functions <tt>compare_exchange_weak</tt> and
<tt>compare_exchange_strong</tt> that take arguments of type <tt>const void*</tt>, 
in addition to the <tt>void*</tt> versions. If these member functions survive, 
there should be corresponding free functions.

<p><i>[
2010-10-27 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue 
differently by removing the overloads with <tt>const void*</tt> arguments, because they break type-safety.
</blockquote>
<p><i>[
Resolved in Batavia by accepting 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
]</i></p>



<p><b>Proposed resolution:</b></p>
Extend the synopsis around <tt>atomic_address</tt> in 29.5.2 [atomics.types.address]
as indicated:
<blockquote><pre>namespace std {
  [..]
  bool atomic_compare_exchange_weak(volatile atomic_address*, void**, void*);
  bool atomic_compare_exchange_weak(atomic_address*, void**, void*);
  bool atomic_compare_exchange_strong(volatile atomic_address*, void**, void*);
  bool atomic_compare_exchange_strong(atomic_address*, void**, void*);
  bool atomic_compare_exchange_weak_explicit(volatile atomic_address*, void**, void*,
    memory_order, memory_order);
  bool atomic_compare_exchange_weak_explicit(atomic_address*, void**, void*,
    memory_order, memory_order);
  bool atomic_compare_exchange_strong_explicit(volatile atomic_address*, void**, void*,
    memory_order, memory_order);
  bool atomic_compare_exchange_strong_explicit(atomic_address*, void**, void*,
    memory_order, memory_order);
  <ins>bool atomic_compare_exchange_weak(volatile atomic_address*, const void**, const void*);</ins>
  <ins>bool atomic_compare_exchange_weak(atomic_address*, const void**, const void*);</ins>
  <ins>bool atomic_compare_exchange_strong(volatile atomic_address*, const void**, const void*);</ins>
  <ins>bool atomic_compare_exchange_strong(atomic_address*, const void**, const void*);</ins>
  <ins>bool atomic_compare_exchange_weak_explicit(volatile atomic_address*, const void**, const void*,
    memory_order, memory_order);</ins>
  <ins>bool atomic_compare_exchange_weak_explicit(atomic_address*, const void**, const void*,
    memory_order, memory_order);</ins>
  <ins>bool atomic_compare_exchange_strong_explicit(volatile atomic_address*, const void**, const void*,
    memory_order, memory_order);</ins>
  <ins>bool atomic_compare_exchange_strong_explicit(volatile atomic_address*, const void**, const void*,
    memory_order, memory_order);</ins>
  <ins>bool atomic_compare_exchange_strong_explicit(atomic_address*, const void**, const void*,
    memory_order, memory_order);</ins>
  [..]
}
</pre></blockquote>






<hr>
<h3><a name="1469"></a>1469. [FCD] <tt>atomic&lt;T*&gt;</tt> inheritance from <tt>atomic_address</tt> breaks type safety</h3>
<p><b>Section:</b> 29.5 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-133</b></p>

The free functions that operate on <tt>atomic_address</tt> can be
used to store a pointer to an unrelated type in an <tt>atomic&lt;T*&gt;</tt> 
without a cast. e.g.
<blockquote><pre>int i;
atomic&lt;int*&gt; ai(&amp;i);
string s;
atomic_store(&amp;ai,&amp;s);
</pre></blockquote>
Overload the <tt>atomic_store</tt>, <tt>atomic_exchange</tt> and
<tt>atomic_compare_exchange_[weak/strong]</tt> operations for 
<tt>atomic&lt;T*&gt;</tt> to allow storing only pointers to <tt>T</tt>.

<p><i>[
2010-10-27 Daniel adds:
]</i></p>


<blockquote>
<p>
Resolving this issue will also solve <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1467">1467</a>
</p>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3164.html">n3164</a> would solve this issue by
removing <tt>atomic_address</tt>.
</blockquote>

<p><i>[Resolved in Batavia by accepting
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">n3193</a>.
]</i></p>



<p><b>Proposed resolution:</b></p>
<p>Add the following overloads to 29.5 [atomics.types.generic], the synopsis around the specialization
<tt>atomic&lt;T*&gt;</tt>, as indicated:
</p><blockquote><pre>namespace std {
  [..]
  template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address {
    [..]
  };

  <ins>template&lt;typename T&gt;</ins>
  <ins>void atomic_store(atomic&lt;T*&gt;&amp;,T*);</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>void atomic_store(atomic&lt;T*&gt;&amp;,void*) = delete;</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>void atomic_store_explicit(atomic&lt;T*&gt;&amp;,T*,memory_order);</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>void atomic_store_explicit(atomic&lt;T*&gt;&amp;,void*,memory_order) = delete;</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_exchange(atomic&lt;T*&gt;&amp;,T*);</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_exchange(atomic&lt;T*&gt;&amp;,void*) = delete;</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_exchange_explicit(atomic&lt;T*&gt;&amp;,T*,memory_order);</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_exchange_explicit(atomic&lt;T*&gt;&amp;,void*,memory_order) = delete;</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_compare_exchange_weak(atomic&lt;T*&gt;&amp;,T**,T*);</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_compare_exchange_weak(atomic&lt;T*&gt;&amp;,void**,void*) = delete;</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_compare_exchange_weak_explicit(atomic&lt;T*&gt;&amp;,T**,T*,memory_order);</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_compare_exchange_weak_explicit(atomic&lt;T*&gt;&amp;,void**,void*,memory_order) = delete;</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_compare_exchange_strong(atomic&lt;T*&gt;&amp;,T**,T*);</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_compare_exchange_strong(atomic&lt;T*&gt;&amp;,void**,void*) = delete;</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_compare_exchange_strong_explicit(atomic&lt;T*&gt;&amp;,T**,T*,memory_order);</ins>
  <ins>template&lt;typename T&gt;</ins>
  <ins>T* atomic_compare_exchange_strong_explicit(atomic&lt;T*&gt;&amp;,void**,void*,memory_order) = delete;</ins>

}
</pre></blockquote>
<p></p>





<hr>
<h3><a name="1481"></a>1481. [FCD] Missing Lockable requirements</h3>
<p><b>Section:</b> 30.2 [thread.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-138</b></p>

The FCD combines the requirements for lockable objects
with those for the standard mutex objects. These should
be separate. This is LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1268">1268</a>.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
See attached Appendix 1 - Additional Details
</blockquote>

<p><i>[
2010-11-01 Daniel comments:
]</i></p>

<blockquote>
Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3130.html">n3130</a> addresses
this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3197.html">n3197</a>.





<hr>
<h3><a name="1482"></a>1482. [FCD] Timeout operations are under-specified</h3>
<p><b>Section:</b> 30.2.4 [thread.req.timing] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.req.timing">issues</a> in [thread.req.timing].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-181</b></p>

The timeout operations are under-specified.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>


<blockquote>
Define precise semantics for <tt>timeout_until</tt> and <tt>timeout_for</tt>. See 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3141.pdf">n3141</a> page 193 - Appendix 1 - Additional Details
</blockquote>

<p><i>[
2010-11-01 Daniel comments:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3128</a> would solve this issue.
</blockquote>


<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html">n3191</a>.





<hr>
<h3><a name="1490"></a>1490. [FCD] Mutex requirements too stringent</h3>
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses CH-27</b></p>

The mutex requirements force <tt>try_lock</tt> to be
<tt>noexcept(true)</tt>. However, where they are used by the
generic algorithms, those relax this requirement and say
that <tt>try_lock</tt> may throw. This means the requirement is
too stringent, also a non-throwing <tt>try_lock</tt> does not allow
for a diagnostic such as <tt>system_error</tt> that <tt>lock()</tt> 
will give us.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
delete p18, adjust 30.4.4 p1 and p4 accordingly
</blockquote>

<p><i>[
2010-11-01 Daniel comments:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3130.html">n3130</a> would solve this issue.
</blockquote>


<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3197.html">n3197</a>.





<hr>
<h3><a name="1491"></a>1491. [FCD] <tt>try_lock</tt> does not guarantee forward progress</h3>
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-186</b></p>

<tt>try_lock</tt> does not provide a guarantee of forward progress
because it is allowed to spuriously fail.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
The standard mutex types must not fail spuriously
in <tt>try_lock</tt>. See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3141.pdf">n3141</a> page 205 - Appendix 1 - Additional Details
</blockquote>

<p><i>[
2010-11-01 Daniel comments:
]</i></p>

<blockquote>
Paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3152.html">n3152</a> addresses
this issue.
</blockquote>



<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3209.html">n3209</a>.





<hr>
<h3><a name="1492"></a>1492. [FCD] Mutex requirements should not be bound to threads</h3>
<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-188</b></p>

Mutex requirements should not be bound to threads

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
See Appendix 1 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3141.pdf">n3141</a> - Additional Details, p. 208.
</blockquote>

<p><i>[
2010-10-24 Daniel adds:
]</i></p>


<blockquote>
Accepting <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3130.html">n3130</a> would solve this issue.
</blockquote>


<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3197.html">n3197</a>.





<hr>
<h3><a name="1498"></a>1498. [FCD] Unclear specification for [thread.condition]</h3>
<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-29</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses CH-29</b></p>

It is unclear if a spurious wake-up during the loop and reentering
of the blocked state due to a repeated execution
of the loop will adjust the timer of the blocking with the
respect to the previously specified rel_time value.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>


<blockquote>
Make it clear (e.g. by a note) that when reexecuting
the loop the waiting time when blocked
will be adjusted with respect to the elapsed time of
the previous loop executions.
</blockquote>

<p><i>[
2010-08-13 Peter Sommerlad comments and provides wording:
]</i></p>


<blockquote>
Problem: It is unclear if a spurious wake-up during the loop and re-entering of the blocked state due 
to a repeated execution of the loop will adjust the timer of the blocking with the respect to the 
previously specified <tt>rel_time</tt> value.
<p>
Proposed Resolution from CH29:
</p><p>
Make it clear (e.g. by a note) that when re-executing the loop the waiting time when blocked will be 
adjusted with respect to the elapsed time of the previous loop executions.
</p><p>
Discussion in Rapperswil:
</p><p>
Assuming the introduction of a mandatory <tt>steady_clock</tt> proposed by US-181 to the FCD the 
specification of <tt>condition_variable::wait_for</tt> can be defined in terms of <tt>wait_until</tt> 
using the <tt>steady_clock</tt>. This is also interleaving with US-181, because that touches the 
same paragraph (30.5.1 p 25, p34 and 30.5.2 p 20, p 28 in n3092.pdf)
</p><p>
(The "as if" in the proposed solutions should be confirmed by the standardization terminology experts)
</p></blockquote>

<p><i>[
2010-11 Batavia: Resolved by applying <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>
]</i></p>


<blockquote>
<ol>
<li>Change 30.5.1 [thread.condition.condvar] paragraph 25, <tt>wait_for</tt> <i>Effects</i> as indicated:
<blockquote><pre>template &lt;class Rep, class Period&gt;
cv_status wait_for(unique_lock&lt;mutex&gt;&amp; lock,
  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre></blockquote>
<blockquote>
[..]
<p>
25 <i>Effects</i>: <ins>as if</ins>
</p><blockquote><pre><ins>return wait_until(lock, chrono::steady_clock::now() + rel_time);</ins>
</pre></blockquote>
<ul>
<li><del>Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.</del>
</li>
<li><del>When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock), then returns.</del>
</li>
<li><del>The function will unblock when signaled by a call to <tt>notify_one()</tt> or a call to <tt>notify_all()</tt>,
by the elapsed time <tt>rel_time</tt> passing (30.2.4), or spuriously.</del>
</li>
<li><del>If the function exits via an exception, <tt>lock.lock()</tt> shall be called prior to exiting the function scope.</del>
</li>
</ul>
</blockquote>
</li>
<li>Change 30.5.1 [thread.condition.condvar] paragraph 34, <tt>wait_for</tt> with predicate <i>Effects</i> as indicated:
<blockquote><pre>template &lt;class Rep, class Period, class Predicate&gt;
bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
  Predicate pred);
</pre></blockquote>
<blockquote>
[..]
<p>
34 <i>Effects</i>: <ins>as if</ins>
</p><blockquote><pre><ins>return wait_until(lock, chrono::steady_clock::now() + rel_time, std::move(pred));</ins>
</pre></blockquote>
<ul>
<li><del>Executes a loop: Within the loop the function first evaluates <tt>pred()</tt> and exits the loop if the
result is <tt>true</tt>.
</del></li>

<li><del>Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
</del></li>

<li><del>When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
</del></li>

<li><del>The function will unblock when signaled by a call to <tt>notify_one()</tt> or a call to <tt>notify_all()</tt>,
by the elapsed time <tt>rel_time</tt> passing (30.2.4), or spuriously.
</del></li>

<li><del>If the function exits via an exception, <tt>lock.lock()</tt> shall be called prior to exiting the function
scope.
</del></li>

<li><del>The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time duration specified by <tt>rel_time</tt>
has elapsed.
</del></li>

</ul>
</blockquote>
</li>

<li>Change 30.5.2 [thread.condition.condvarany] paragraph 20, <tt>wait_for</tt> <i>Effects</i> as indicated:
<blockquote><pre>template &lt;class Lock, class Rep, class Period&gt;
cv_status wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
</pre></blockquote>
<blockquote>
20 <i>Effects</i>: <ins>as if</ins>
<blockquote><pre><ins>return wait_until(lock, chrono::steady_clock::now() + rel_time);</ins>
</pre></blockquote>
<ul>
<li><del>Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
</del></li>

<li><del>When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock), then returns.
</del></li>

<li><del>The function will unblock when signaled by a call to <tt>notify_one()</tt> or a call to <tt>notify_all()</tt>,
by the elapsed time <tt>rel_time</tt> passing (30.2.4), or spuriously.
</del></li>

<li><del>If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior to exiting the function
scope.
</del></li>
</ul>
</blockquote>
</li>

<li>Change 30.5.2 [thread.condition.condvarany] paragraph 28, <tt>wait_for</tt> with predicate <i>Effects</i> as indicated:
<blockquote><pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt;
bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
</pre></blockquote>
<blockquote>
28 <i>Effects</i>: <ins>as if</ins>
<blockquote><pre><ins>return wait_until(lock, chrono::steady_clock::now() + rel_time, std::move(pred));</ins>
</pre></blockquote>
<ul>
<li><del>Executes a loop: Within the loop the function first evaluates <tt>pred()</tt> and exits the loop if the
result is <tt>true</tt>.
</del></li>

<li><del>Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
</del></li>

<li><del>When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
</del></li>

<li><del>The function will unblock when signaled by a call to <tt>notify_one()</tt> or a call to <tt>notify_all()</tt>,
by the elapsed time <tt>rel_time</tt> passing (30.2.4), or spuriously.
</del></li>

<li><del>If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior to exiting the function
scope.
</del></li>

<li><del>The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time duration specified by <tt>rel_time</tt>
has elapsed.
</del></li>
</ul>
</blockquote>
</li>

</ol>

</blockquote>


<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">n3191</a>.





<hr>
<h3><a name="1501"></a>1501. [FCD] spec for managing associated asynchronous
state has problems</h3>
<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures">issues</a> in [futures].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-194</b></p>

The specification for managing associated asynchronous
state is confusing, sometimes omitted, and redundantly
specified.

<p><i>[
Resolution proposed by ballot comment:
]</i></p>


<blockquote>
Define terms-of-art for releasing, making ready,
and abandoning an associated asynchronous
state. Use those terms where appropriate. See
Appendix 1 - Additional Details
</blockquote>


<p><b>Proposed resolution:</b></p>
Resolved in Batavia by accepting
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3192.html">n3192</a>.





<hr>
<h3><a name="1508"></a>1508. [FCD] Rename <tt>packaged_task::operator bool()</tt></h3>
<p><b>Section:</b> 30.6.10 [futures.task] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> INCITS <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.task">issues</a> in [futures.task].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US-201</b></p>
<p>
<tt>packaged_task</tt> provides <tt>operator bool()</tt> to check whether
an object has an associated asynchronous state. The various <tt>future</tt> 
types provide a member function <tt>valid()</tt> that does the same thing. 
The names of these members should be the same.
</p>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<blockquote>
Replaced the name <tt>packaged_task::operator bool()</tt> with <tt>packaged_task::valid()</tt> in the synopsis
(30.6.10 [futures.task]/2) and the member function specification (before 30.6.10.1 [futures.task.members]/15).
</blockquote>

<p><i>[
2010-11-02 Daniel translates proposed wording changes into a proper proposed resolution
and verified that no other places implicitly take advantage of <tt>packaged_task</tt> 
conversion to bool.
]</i></p>


<p><i>[Resolved in Batavia by accepting
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3194.html">n3194</a>.
]</i></p>




<p><b>Proposed resolution:</b></p>
<ol>
<li>Change 30.6.10 [futures.task]/2, class template <tt>packaged_task</tt> synopsis as indicated:
<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
class packaged_task&lt;R(ArgTypes...)&gt; {
public:
  typedef R result_type;
  [..]
  <del>explicit operator</del> bool <ins>valid</ins>() const;
  [..]
};
</pre></blockquote>
</li>
<li>Change 30.6.10 [futures.task] before p. 15 as indicated:
<blockquote><pre><del>explicit operator</del> bool <ins>valid</ins>() const;
</pre><blockquote>
15 <em>Returns</em>: true only if <tt>*this</tt> has an associated asynchronous state.
<p>
16 <em>Throws</em>: nothing.
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="1513"></a>1513. [FCD] 'launch' enum too restrictive</h3>
<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures">issues</a> in [futures].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses CH-36</b></p>

Providing only three different possible values for the enum
<tt>launch</tt> and saying that <tt>launch::any</tt> means either
<tt>launch::sync</tt> or <tt>launch::async</tt> is very restricting. This
hinders future implementors to provide clever
infrastructures that can simply by used by a call to
<tt>async(launch::any,...)</tt>. Also there is no hook for an
implementation to provide additional alternatives to <tt>launch</tt>
enumeration and no useful means to combine those (i.e.
interpret them like flags). We believe something like
<tt>async(launch::sync | launch::async, ...)</tt> should be allowed
and can become especially useful if one could say also
something like <tt>async(launch::any &amp; ~launch::sync, ....)</tt>
respectively. This flexibility might limit the features usable
in the function called through <tt>async()</tt>, but it will allow a
path to effortless profit from improved hardware/software
without complicating the programming model when just
using <tt>async(launch::any,...)</tt>

<p><i>[
Resolution proposed by ballot comment:
]</i></p>

<p>
Change in 30.6.1 [futures.overview] 'enum class launch' to allow
further implementation defined values and provide
the following bit-operators on the launch values
(<tt>operator|</tt>, <tt>operator&amp;</tt>, <tt>operator~</tt> delivering a
<tt>launch</tt> value).
</p><p>
Note: a possible implementation might use an
unsigned value to represent the <tt>launch</tt> enums,
but we shouldn't limit the standard to just 32 or 64
available bits in that case and also should keep
the launch enums in their own enum namespace.
</p><p>
Change [future.async] p3 according to the
changes to <tt>enum launch</tt>. change --<tt>launch::any</tt> to
"the implementation may choose any of the
policies it provides." Note: this can mean that an
implementation may restrict the called function to
take all required information by copy in case it will
be called in a different address space, or even, on
a different processor type. To ensure that a call is
either performed like <tt>launch::async</tt> or
<tt>launch::sync</tt> describe one should call
<tt>async(launch::sync|launch::async,...)</tt>
</p>

<p><i>[
2010-11-02 Daniel comments:
]</i></p>


<blockquote>
The new paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3113.html">n3113</a> provides concrete wording.
</blockquote>


<p><b>Proposed resolution:</b></p>
Resolved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3188.html">n3188</a>.





<hr>
<h3><a name="1516"></a>1516. [FCD] No specification for which header contains <tt>auto_ptr</tt></h3>
<p><b>Section:</b> D.12 [depr.auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> BSI <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses GB-142</b></p>
<p>
<tt>auto_ptr</tt> does not appear in the <tt>&lt;memory&gt;</tt> synopsis and
[depr.auto.ptr] doesn't say which header declares it.
Conversely, the deprecated binders <tt>bind1st</tt> etc. are in the
<tt>&lt;functional&gt;</tt> synopsis, this is inconsistent
</p>
<p>
Either <tt>auto_ptr</tt> should be declared in the
<tt>&lt;memory&gt;</tt> synopsis, or the deprecated binders
should be removed from the <tt>&lt;functional&gt;</tt> synopsis
and appendix D should say which header declares
the binders and <tt>auto_ptr</tt>.
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>Add the following lines to the synopsis of header <tt>&lt;memory&gt;</tt>
in [memory]/1:<br></p>
<blockquote>
<pre><ins>// [depr.auto.ptr], Class auto_ptr (deprecated):
template &lt;class X&gt; class auto_ptr;<br></ins>
</pre></blockquote>





<hr>
<h3><a name="1517"></a>1517. default_delete's default constructor should be trivial</h3>
<p><b>Section:</b> 20.9.9.1.2 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-09-12 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.dltr.dflt">issues</a> in [unique.ptr.dltr.dflt].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current working draft does specify the default c'tor of <tt>default_delete</tt> in a manner
to guarantee static initialization for default-constructed objects of static storage duration
as a consequence of the acceptance of the proposal <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2976.html">n2976</a>
but this paper overlooked the fact that the suggested declaration does not ensure that the type 
will be a trivial type. The type <tt>default_delete</tt> was always considered as a simple wrapper for 
calling <tt>delete</tt> or <tt>delete[]</tt>, respectivly and should be a trivial type.
</p>
<p>
In agreement with the new settled core language rules this easy to realize by just changing the declaration to
</p><blockquote><pre>constexpr default_delete()<ins> = default</ins>;
</pre></blockquote><p></p>
<p>
This proposal also automatically solves the problem, that the semantics of the default constructor of the 
partial specialization <tt>default_delete&lt;T[]&gt;</tt> is not specified at all. By defaulting its default constructor 
as well, the semantics are well-defined.
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p><i>The following wording changes are against N3126.</i></p>

<ol>
<li>Change the synopsis of the primary template definition of <tt>default_delete</tt> in [unique.ptr.dltr.dflt] as indicated:
<blockquote><pre>namespace std {
  template &lt;class T&gt; struct default_delete {
    constexpr default_delete()<ins> = default</ins>;
    template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp;);
    void operator()(T*) const;
  };
}
</pre></blockquote>
</li>
<li>
Remove the prototype specification of the <tt>default_delete</tt> default constructor in [unique.ptr.dltr.dflt]/1. This
brings it in harmony with the style used in the partial specialization <tt>default_delete&lt;T[]&gt;</tt>. Since there are
neither implied nor explicit members, there is no possibility to misinterpret what the constructor does:
<blockquote><pre><del>constexpr default_delete();</del>
</pre><blockquote>
<del>1 <em>Effects</em>: Default constructs a <tt>default_delete</tt> object.</del>
</blockquote></blockquote>
</li>
<li>Change the synopsis of the partial specialization of <tt>default_delete</tt> in [unique.ptr.dltr.dflt1] as indicated:
<blockquote><pre>namespace std {
  template &lt;class T&gt; struct default_delete&lt;T[]&gt; {
    constexpr default_delete()<ins> = default</ins>;
    void operator()(T*) const;
    template &lt;class U&gt; void operator()(U*) const = delete;
  };
}</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="1518"></a>1518. Waiting for deferred functions</h3>
<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2010-09-14 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures">issues</a> in [futures].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>The current WP N3126 contains ambiguous statements about the
behaviour of functions <tt>wait_for</tt>/<tt>wait_until</tt> in
case the future refers to a deferred function. Moreover, I believe
it describes a disputable intent, different from the one contained
in the original async proposals, that may have been introduced
inadvertently during the "async cleanup" that occurred recently.
Consider the following case:</p>
<blockquote>
<pre>int f();  
future&lt;int&gt; x = async(launch::deferred, f);
future_status s = x.wait_for(chrono::milliseconds(100));
</pre></blockquote>
<p>This example raises two questions:</p>
<ol>
<li>is <tt>f</tt> invoked?</li>
<li>what is the value of <tt>s</tt>?</li>
</ol>
<p>According to the current WP, the answer to question 1 is yes,
because 30.6.9/3 says "The first call to a function waiting for the
associated asynchronous state created by this async call to become
ready shall invoke the deferred function in the thread that called
the waiting function". The answer to question 2, however, is not as
clear. According to 30.6.6/23, s should be
<tt>future_status::deferred</tt> because <tt>x</tt> refers to a
deferred function that is not running, but it should also be
<tt>future_status::ready</tt> because after executing <tt>f</tt>
(and we saw that <tt>f</tt> is always executed) the state becomes
ready. By the way, the expression "deferred function that is not
running" is very unfortunate in itself, because it may apply to
both the case where the function hasn't yet started, as well as the
case where it was executed and completed.</p>
<p>While we clearly have a defect in the WP answering to question
2, it is my opinion that the answer to question 1 is wrong, which
is even worse. Consider that the execution of the function
<tt>f</tt> can take an arbitrarily long time. Having
<tt>wait_for()</tt> invoke <tt>f</tt> is a potential violation of
the reasonable expectation that the execution of
<tt>x.wait_for(chrono::milliseconds(100))</tt> shall take <u>at most</u>
100 milliseconds plus a delay dependent on the quality of implementation
and the quality of management (as described in paper N3128).
In fact, previous versions of the WP
clearly specified that only function <tt>wait()</tt> is required to
execute the deferred function, while <tt>wait_for()</tt> and
<tt>wait_until()</tt> shouldn't.</p>
<p>The proposed resolution captures the intent that
<tt>wait_for()</tt> and <tt>wait_until()</tt> should never attempt
to invoke the deferred function. In other words, the P/R provides
the following answers to the two questions above:</p>
<ol>
<li>no</li>
<li><tt>future_status::deferred</tt></li>
</ol>
<p>In order to simplify the wording, the definition of <i>deferred
function</i> has been tweaked so that the function is no longer
considered deferred once its evaluation has started, as suggested
by Howard.</p>
<p>Discussions in the reflector questioned whether
<tt>wait_for()</tt> and <tt>wait_until()</tt> should return
immediately or actually wait hoping for a second thread to execute
the deferred function. I believe that waiting could be useful only
in a very specific scenario but detrimental in the general case and
would introduce another source of ambiguity: should
<tt>wait_for()</tt> return <tt>future_status::deferred</tt> or
<tt>future_status::timeout</tt> after the wait? Therefore the P/R
specifies that <tt>wait_for</tt>/<tt>wait_until</tt> shall return
immediately, which is simpler, easier to explain and more useful in
the general case.</p>

<p><i>[
Post-Rapperswil
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<p>The proposed wording changes are relative to the Final Committee Draft,
N3126.</p>
<p><b>Note to the editor:</b> the proposed wording is meant not be in conflict
with any change proposed by paper N3128 "C++ Timeout Specification".
Ellipsis are deliberately used to avoid any unintended overlapping.</p>
<ol>
<li>
<p>In [futures.unique_future] 30.6.6/22:</p>
<p>Effects: <ins>none if the associated asynchronous state contains
a deferred function (30.6.9), otherwise</ins> blocks until the
associated asynchronous state is ready or [...].</p>
</li>
<li>
<p>In [futures.unique_future] 30.6.6/23 first bullet:</p>
<p>� future_status::deferred if the associated asynchronous
state contains a deferred function <del>that is not
running</del>.</p>
</li>
<li>
<p>In [futures.unique_future] 30.6.6/25:</p>
<p>Effects: <ins>none if the associated asynchronous state contains
a deferred function (30.6.9), otherwise</ins> blocks until the
associated asynchronous state is ready or [...].</p>
</li>
<li>
<p>In [futures.unique_future] 30.6.6/26 first bullet:</p>
<p>� future_status::deferred if the associated asynchronous
state contains a deferred function <del>that is not
running</del>.</p>
</li>
<li>
<p>In [futures.shared_future] 30.6.7/27</p>
<p>Effects: <ins>none if the associated asynchronous state contains
a deferred function (30.6.9), otherwise</ins> blocks until the
associated asynchronous state is ready or [...].</p>
</li>
<li>
<p>In [futures.unique_future] 30.6.7/28 first bullet:</p>
<p>� future_status::deferred if the associated asynchronous
state contains a deferred function <del>that is not
running</del>.</p>
</li>
<li>
<p>In [futures.shared_future] 30.6.6/30:</p>
<p>Effects: <ins>none if the associated asynchronous state contains
a deferred function (30.6.9), otherwise</ins> blocks until the
associated asynchronous state is ready or [...].</p>
</li>
<li>
<p>In [futures.unique_future] 30.6.7/31 first bullet:</p>
<p>� future_status::deferred if the associated asynchronous
state contains a deferred function <del>that is not
running</del>.</p>
</li>
<li>
<p>In [futures.atomic_future] 30.6.8/23</p>
<p>Effects: <ins>none if the associated asynchronous state contains
a deferred function (30.6.9), otherwise</ins> blocks until the
associated asynchronous state is ready or [...].</p>
</li>
<li>
<p>In [futures.unique_future] 30.6.8/24 first bullet:</p>
<p>� future_status::deferred if the associated asynchronous
state contains a deferred function <del>that is not
running</del>.</p>
</li>
<li>
<p>In [futures.atomic_future] 30.6.8/27:</p>
<p>Effects: <ins>none if the associated asynchronous state contains
a deferred function (30.6.9), otherwise</ins> blocks until the
associated asynchronous state is ready or [...].</p>
</li>
<li>
<p>In [futures.unique_future] 30.6.8/28 first bullet:</p>
<p>� future_status::deferred if the associated asynchronous
state contains a deferred function <del>that is not
running</del>.</p>
</li>
<li>
<p>In [futures.async] 30.6.9/3 second bullet:</p>
<p>[...] The first call to a function
<del>waiting</del><ins>requiring a non-timed wait</ins> for the
associated asynchronous state created by this async call to become
ready shall invoke the deferred function in the thread that called
the waiting function; <ins>once evaluation of <tt><i>INVOKE</i>(g,
xyz)</tt> begins, the function is no longer considered
deferred</ins> <del>all other calls waiting for the same associated
asynchronous state to become ready shall block until the deferred
function has completed</del>.</p>
</li>
</ol>






<hr>
<h3><a name="1519"></a>1519. bucketsize() const only for unordered set</h3>
<p><b>Section:</b> 23.7.1 [unord.map], 23.7.2 [unord.multimap], 23.7.4 [unord.multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Nicolai Josuttis <b>Opened:</b> 2010-10-09 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.map">issues</a> in [unord.map].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
While <tt>bucket_size()</tt> is const for <tt>unordered_set</tt>, for all other unordered containers it is not defined as
constant member function.
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>The wording refers to N3126.</i></p>

<ol>
<li>Change 23.7.1 Class template unordered_map [unord.map]/3, as indicated:
<blockquote><pre>  namespace std {
    template &lt;class Key,
      class T,
      class Hash = hash&lt;Key&gt;,
      class Pred = std::equal_to&lt;Key&gt;,
      class Alloc = std::allocator&lt;std::pair&lt;const Key, T&gt; &gt; &gt;
    class unordered_map
    {
    public:
      [..]
      // bucket interface
      size_type bucket_count() const;
      size_type max_bucket_count() const;
      size_type bucket_size(size_type n) <ins>const</ins>;
      [..]
</pre></blockquote>
</li>
<li>Change 23.7.2 Class template unordered_multimap [unord.multimap]/3, as indicated:
<blockquote><pre>  namespace std {
    template &lt;class Key,
      class T,
      class Hash = hash&lt;Key&gt;,
      class Pred = std::equal_to&lt;Key&gt;,
      class Alloc = std::allocator&lt;std::pair&lt;const Key, T&gt; &gt; &gt;
    class unordered_multimap
    {
    public:
      [..]
      // bucket interface
      size_type bucket_count() const;
      size_type max_bucket_count() const;
      size_type bucket_size(size_type n) <ins>const</ins>;
      [..]
</pre></blockquote>
</li>
<li>Change 23.7.4 Class template unordered_multiset [unord.multiset]/3, as indicated:
<blockquote><pre>  namespace std {
    template &lt;class Key,
      class Hash = hash&lt;Key&gt;,
      class Pred = std::equal_to&lt;Key&gt;,
      class Alloc = std::allocator&lt;Key&gt; &gt;
    class unordered_multiset
    {
    public:
      [..]
      // bucket interface
      size_type bucket_count() const;
      size_type max_bucket_count() const;
      size_type bucket_size(size_type n) <ins>const</ins>;
      [..]
</pre></blockquote>
</li>
</ol>






<hr>
<h3><a name="1520"></a>1520. <tt>INVOKE</tt> on member data pointer with too many arguments</h3>
<p><b>Section:</b> 20.8.2 [func.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2010-10-10 <b>Last modified:</b> 2010-11-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.require">issues</a> in [func.require].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>

<p>
20.8.2 [func.require] p1 says:
</p>

<blockquote>
<p>
1 Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
</p>

<ul>
<li>
<tt>(t1.*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member function
of a class <tt>T</tt> and <tt>t1</tt> is an object of type <tt>T</tt> or a
reference to an object of type <tt>T</tt> or a reference to an object of a type
derived from <tt>T</tt>;
</li>
<li>
<tt>((*t1).*f)(t2, ..., tN)</tt> when <tt>f</tt> is a pointer to a member
function of a class <tt>T</tt> and <tt>t1</tt> is not one of the types described
in the previous item;
</li>
<li>
<tt>t1.*f</tt> when <tt>f</tt> is a pointer to member data of a class <tt>T</tt>
and <tt>t1</tt> is an object of type <tt>T</tt> or a reference to an object of
type <tt>T</tt> or a reference to an object of a type derived from <tt>T</tt>;
</li>
<li>
<tt>(*t1).*f</tt> when <tt>f</tt> is a pointer to member data of a class
<tt>T</tt> and <tt>t1</tt> is not one of the types described in the previous
item;
</li>
<li>
<tt>f(t1, t2, ..., tN)</tt> in all other cases.
</li>
</ul>
</blockquote>

<p>
The question is:  What happens in the 3<sup><i>rd</i></sup> and
4<sup><i>th</i></sup> bullets when <tt>N &gt; 1</tt>?
</p>

<p>
Does the presence of <tt>t2, ..., tN</tt> get ignored, or does it make the
<tt><i>INVOKE</i></tt> ill formed?
</p>

<p>
Here is sample code which presents the problem in a concrete example:
</p>

<blockquote><pre>#include &lt;functional&gt;
#include &lt;cassert&gt;

struct S {
   char data;
};

typedef char S::*PMD;

int main()
{
   S s;
   PMD pmd = &amp;S::data;
   std::reference_wrapper&lt;PMD&gt; r(pmd);
   r(s, 3.0) = 'a';  // well formed?
   assert(s.data == 'a');
}
</pre></blockquote>

<p>
Without the "<tt>3.0</tt>" the example is well formed.
</p>
<p>
[Note: Daniel provided wording to make it explicit that the above example is ill-formed. � end note ]
</p>

<p><i>[
Post-Rapperswil
]</i></p>


<blockquote>
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
</blockquote>

<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>

<p><i>The wording refers to N3126.</i></p>

<p>
Change 20.8.2 [func.require]/1 as indicated:
</p>
<blockquote>
<p>
1 Define <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> as follows:
</p>

<ul>
<li>
...
</li>
<li>
...
</li>
<li>
<tt>t1.*f</tt> when <ins><tt>N == 1</tt> and</ins> <tt>f</tt> is a pointer to
member data of a class <tt>T</tt> and <tt>t1</tt> is an object of type
<tt>T</tt> or a reference to an object of type <tt>T</tt> or a reference to an
object of a type derived from <tt>T</tt>;
</li>
<li>
<tt>(*t1).*f</tt> when <ins><tt>N == 1</tt> and</ins> <tt>f</tt> is a pointer to
member data of a class <tt>T</tt> and <tt>t1</tt> is not one of the types
described in the previous item;
</li>
<li>
...
</li>
</ul>
</blockquote>






<hr>
<h3><a name="1522"></a>1522. <tt>conj</tt> specification is now nonsense</h3>
<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2010-10-14 <b>Last modified:</b> 2010-11-24</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In Pittsburgh, we accepted the resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1137">1137</a>, to add
a sentence 3 to [cmplx.over]:
</p>
<blockquote>
All the specified overloads shall have a return type which is the nested
<tt>value_type</tt> of the effectively cast arguments.
</blockquote>
<p>
This was already true for four of the six functions except <tt>conj</tt> and
<tt>proj</tt>. It is not completely unreasonable to make <tt>proj</tt> return
the real value only, but the IEC specification does call for an imaginary part
of -0 in some circumstances. The people who care about these distinctions really
care, and it <em>is</em> required by an international standard.
</p>
<p>
Making <tt>conj</tt> return just the real part breaks it horribly, however. It is
well understood in mathematics that <tt>conj(re + i*im)</tt> is <tt>(re - i*im)</tt>,
and it is widely used. The accepted new definition makes <tt>conj</tt> useful only
for pure real operations. This botch <em>absolutely must</em> be fixed.
</p>

<p><i>[
2010 Batavia: The working group concurred with the issue's Proposed Resolution
]</i></p>


<p><i>[
Adopted at 2010-11 Batavia
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>
Remove the recently added paragraph 3 from [cmplx.over]:
</p>
<blockquote>
<del>3 All the specified overloads shall have a return type which is the nested 
<tt>value_type</tt> of the effectively cast arguments.</del>
</blockquote>





<hr>
<h3><a name="2002"></a>2002. Class template <tt>match_results</tt> does not specify the semantics of <tt>operator==</tt></h3>
<p><b>Section:</b> 28.10.8 [re.results.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2010-10-24 <b>Last modified:</b> 2010-11-26</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <em>Returns</em> element of <tt>operator==</tt> says:
</p>

<blockquote>
<tt>true</tt> only if the two objects refer to the same match
</blockquote>

<p>
It is not really clear what this means: The current specification would allow for an
implementation to return <tt>true</tt>, only if the address values of <tt>m1</tt> and
<tt>m2</tt> are the same. While this approach is unproblematic in terms of used operations 
this is also a bit unsatisfactory. With identity equality alone there seems to be no convincing
reason to provide this operator at all. It could for example also refer to an comparison based
on iterator values. In this case a user should better know that this will be done, because 
there is no guarantee at all that inter-container comparison of iterators 
is a feasible operation. This was a clear outcome of the resolution provided in 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html">N3066</a> 
for LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#446">446</a>.
It could also mean that a character-based comparison of the individual <tt>sub_match</tt>
elements should be done - this would be equivalent to applying <tt>operator==</tt> to
the subexpressions, prefix and suffix.
</p>



<p><b>Proposed resolution:</b></p>
Addressed by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3158.html">n3158</a>.







</body></html>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-08 15:09:15 +0000