Document number: | PL22.16 10/0214 = WG21 N3224 |
Date: | 2010-11-29 |
Reply to: |
William M. Miller Edison Design Group, Inc. wmm@edg.com Beman Dawes bdawes@acm.org |
This document summarizes the status of WG21 as of the conclusion of the November, 2010 (Batavia) meeting in addressing National Body comments on Final Committee Draft document N3092.
In total, 573 comments were received. To date, 300 have been accepted as proposed, 93 have been accepted with modifications, 101 have been rejected, and 79 remain to be addressed. The detailed breakdown:
Unresolved | Accepted | Modified | Rejected | Total | |
---|---|---|---|---|---|
CWG | 5 | 90 | 8 | 42 | 145 |
LWG | 51 | 38 | 75 | 38 | 202 |
editor | 19 | 168 | 10 | 20 | 217 |
This document consists of three tables. The first is a table of contents, listing each issue by National Body and comment number and giving its current status. The second is a list of all as-yet unresolved comments, sorted by the responsible party. The third is a comprehensive listing of all the comments received in the same order and with roughly the same organization as in document N3102; the “Disposition” field gives the response, as well as any explanatory comments provided by the responsible party.
In the following table, the “Date” field represents the date on which the Committee affirmed the listed disposition.
ID | Responsible | Disposition | Date | Issue | Document |
---|---|---|---|---|---|
CA 1 | LWG | 1461 | |||
CA 2 | |||||
CA 3 | CWG | ||||
CA 4 | LWG | modified | 2010-11-13 | 1449 | |
CA 5 | CWG | accepted | 1218 | ||
CA 6 | CWG | rejected | 1162 | ||
CA 7 | CWG | rejected | 1157 | ||
CA 8 | CWG | accepted | 2010-11-13 | N3196 | |
CA 9 | LWG | accepted | 2010-11-13 | 1442 | N3196 |
CA 10 | LWG | rejected | 2010-08-07 | ||
CA 11 | CWG | accepted | 2010-11-13 | N3196 | |
CA 12 | CWG | accepted | 1176 | ||
CA 13 | CWG | accepted | 2010-11-13 | N3196 | |
CA 14 | CWG | modified | 2010-11-13 | N3196 | |
CA 15 | CWG | accepted | 2010-11-13 | 1177 | N3196 |
CA 16 | editor | accepted | |||
CA 17 | editor | rejected | |||
CA 18 | CWG | accepted | 2010-11-13 | N3196 | |
CA 19 | CWG | accepted | 2010-11-13 | N3196 | |
CA 20 | CWG | accepted | 2010-11-13 | N3196 | |
CA 21 | LWG | 1459 | |||
CA 22 | CWG | rejected | 2010-11-13 | N3196 | |
CA 23 | LWG | modified | 2010-11-13 | N3193 | |
CA 24 | CWG | accepted | 2010-11-13 | 1105 | N3146 |
CH 1 | accepted | ||||
CH 2 | CWG | rejected | 2010-11-13 | N3196 | |
CH 3 | CWG | rejected | |||
CH 4 | CWG | accepted | 2010-11-13 | 1062 | |
CH 5 | editor | accepted | |||
CH 6 | CWG | rejected | |||
CH 7 | CWG | rejected | |||
CH 8 | editor | ||||
CH 9 | CWG | modified | 2010-11-13 | 1147 | N3204 |
CH 10 | CWG | rejected | |||
CH 11 | editor | rejected | |||
CH 12 | editor | accepted | |||
CH 13 | editor | accepted | |||
CH 14 | editor | accepted | |||
CH 15 | LWG | 1421, 1350 | |||
CH 16 | LWG | modified | 2010-11-13 | 1351 | N3148 |
CH 17 | LWG | modified | 2010-11-13 | 1352 | N3195 |
CH 18 | LWG | 1353 | |||
CH 19 | LWG | 1364 | |||
CH 20 | LWG | rejected | 2010-08-07 | ||
CH 21 | LWG | modified | 2010-11-13 | 1412 | N3191 |
CH 22 | LWG | modified | 2010-11-13 | 1455, 1454 | N3193 |
CH 23 | LWG | 1475 | |||
CH 24 | LWG | 1486 | |||
CH 25 | LWG | 1487 | |||
CH 26 | LWG | modified | 2010-11-13 | 1489 | N3197 |
CH 27 | LWG | modified | 2010-11-13 | 1490 | N3197 |
CH 28 | LWG | modified | 2010-11-13 | 1496 | N3191 |
CH 29 | LWG | modified | 2010-11-13 | 1498 | N3191 |
CH 30 | LWG | 1497 | |||
CH 31 | editor | rejected | |||
CH 32 | LWG | accepted | 2010-08-07 | 1500 | |
CH 33 | editor | accepted | |||
CH 34 | editor | accepted | |||
CH 35 | LWG | 1503 | |||
CH 36 | LWG | modified | 2010-11-13 | 1513 | N3188 |
DE 1 | accepted | ||||
DE 2 | CWG | rejected | |||
DE 3 | CWG | accepted | 2010-11-13 | 1106 | |
DE 4 | CWG | accepted | 2010-11-13 | 1113 | |
DE 5 | editor | accepted | |||
DE 7 | CWG | rejected | |||
DE 8 | CWG | accepted | 2010-11-13 | 1125 | N3218 |
DE 9 | CWG | rejected | 1110 | ||
DE 10 | CWG | accepted | 2010-11-13 | 1138 | |
DE 11 | CWG | accepted | 2010-11-13 | 1148 | |
DE 12 | CWG | accepted | 2010-11-13 | 1155 | |
DE 13 | CWG | accepted | 2010-11-13 | 1169 | |
DE 14 | LWG | modified | 2010-11-13 | 1366 | N3189 |
DE 15 | LWG | modified | 2010-11-13 | 1378 | N3140 |
DE 16 | LWG | modified | 2010-11-13 | 1380 | N3140 |
DE 17 | LWG | modified | 2010-11-13 | 1390 | N3142 |
DE 18 | LWG | modified | 2010-11-13 | 1391 | N3142 |
DE 19 | LWG | modified | 2010-08-07 | 1394 | N3047 |
DE 20 | LWG | modified | 2010-11-13 | 1411 | N3191 |
DE 21 | LWG | accepted | 2010-08-07 | 1416 | |
DE 22 | LWG | 1421 | |||
DE 23 | LWG | accepted | 2010-08-07 | 1483 | |
ES 1 | LWG | rejected | 2010-08-07 | ||
ES 2 | LWG | rejected | 2010-08-07 | ||
ES 3 | LWG | accepted | 2010-08-07 | ||
FI 1 | CWG | accepted | 1135 | ||
FI 2 | CWG | accepted | 1136 | ||
FI 3 | CWG | accepted | 1137 | ||
FI 4 | CWG | accepted | 1145 | ||
FI 5 | CWG | accepted | 1149 | ||
FI 6 | CWG | accepted | 2010-11-13 | 1012 | |
FI 7 | CWG | rejected | |||
FI 8 | CWG | rejected | |||
FI 9 | CWG | rejected | |||
FI 10 | CWG | accepted | 2010-08-07 | 924 | |
FI 11 | editor | ||||
FI 12 | LWG | rejected | 2010-08-07 | ||
FI 13 | editor | accepted | |||
FI 14 | editor | accepted | |||
FI 15 | CWG | rejected | |||
FI 16 | CWG | rejected | |||
FI 17 | CWG | modified | 2010-11-13 | 1123 | N3204 |
FI 18 | LWG | rejected | 2010-11-132010-08-07 | N3142 | |
FI 19 | CWG | rejected | 1118 | ||
GB 1 | editor | accepted | |||
GB 2 | editor | ||||
GB 3 | editor | accepted | |||
GB 4 | editor | accepted | |||
GB 5 | editor | accepted | |||
GB 6 | CWG | accepted | 2010-11-13 | 1102 | |
GB 7 | CWG | accepted | 2010-11-13 | 1173 | |
GB 8 | CWG | accepted | 2010-11-13 | N3196 | |
GB 9 | CWG | accepted | 1176 | ||
GB 10 | CWG | accepted | 2010-11-13 | N3196 | |
GB 11 | CWG | accepted | 2010-11-13 | N3196 | |
GB 12 | CWG | accepted | 2010-11-13 | N3196 | |
GB 13 | |||||
GB 14 | CWG | rejected | |||
GB 15 | CWG | rejected | 2010-11-13 | N3196 | |
GB 16 | editor | rejected | |||
GB 17 | editor | accepted | |||
GB 18 | CWG | accepted | 2010-11-13 | 1114 | |
GB 19 | editor | accepted | |||
GB 20 | editor | accepted | |||
GB 21 | CWG | rejected | |||
GB 22 | CWG | accepted | 1120 | ||
GB 23 | editor | accepted | |||
GB 24 | CWG | accepted | 2010-11-13 | 1122 | |
GB 25 | CWG | accepted | 2010-11-13 | 1126 | |
GB 26 | CWG | accepted | 1127 | ||
GB 27 | CWG | rejected | |||
GB 28 | editor | accepted | |||
GB 29 | CWG | modified | 2010-11-13 | 1129 | |
GB 30 | CWG | rejected | |||
GB 31 | CWG | accepted | 2010-11-13 | 1115 | N3190 |
GB 32 | CWG | rejected | 1132 | ||
GB 33 | CWG | modified | 1130 | ||
GB 34 | editor | accepted | |||
GB 35 | editor | accepted | |||
GB 36 | editor | accepted | |||
GB 37 | CWG | accepted | 2010-11-13 | 1138 | |
GB 38 | CWG | rejected | 675 | ||
GB 39 | CWG | accepted | 2010-11-13 | 1146 | |
GB 40 | CWG | modified | 2010-11-13 | 1147 | N3204 |
GB 41 | CWG | accepted | 2010-11-13 | 1146 | |
GB 42 | editor | accepted | |||
GB 43 | CWG | accepted | 2010-11-13 | 1160 | |
GB 44 | CWG | accepted | 2010-11-13 | 1161 | |
GB 45 | CWG | rejected | 1166 | ||
GB 46 | CWG | accepted | 1167 | ||
GB 47 | CWG | accepted | 2010-11-13 | 1168 | |
GB 48 | editor | accepted | |||
GB 49 | CWG | rejected | |||
GB 50 | LWG | modified | 2010-11-13 | 1355 | N3142 |
GB 51 | LWG | modified | 2010-11-13 | 1356 | N3142 |
GB 52 | LWG | modified | 2010-11-13 | 1354 | |
GB 53 | LWG | modified | 2010-11-13 | 1357 | N3110 |
GB 54 | editor | accepted | |||
GB 55 | LWG | 1358 | |||
GB 56 | LWG | rejected | 2010-11-13 | 1359 | |
GB 57 | LWG | accepted | 2010-08-07 | 1360 | |
GB 58 | LWG | rejected | 2010-11-13 | 1361 | |
GB 59 | editor | modified | |||
GB 60 | LWG | modified | 2010-11-13 | 1344 | N3148 |
GB 61 | LWG | 1345 | |||
GB 62 | LWG | modified | 2010-11-13 | 1346 | N3195 |
GB 63 | LWG | modified | 2010-11-13 | 1347 | N3155 |
GB 64 | LWG | 1348 | |||
GB 65 | LWG | 1349 | |||
GB 66 | editor | accepted | |||
GB 68 | LWG | accepted | 2010-08-07 | 1363 | |
GB 69 | editor | accepted | |||
GB 70 | LWG | rejected | |||
GB 71 | LWG | modified | 2010-11-13 | 1365 | N3189 |
GB 72 | LWG | accepted | 2010-08-07 | 1367 | |
GB 73 | LWG | modified | 2010-11-13 | 1368 | |
GB 74 | LWG | 1369 | |||
GB 75 | LWG | 1371 | |||
GB 76 | LWG | accepted | 2010-08-07 | 1372 | |
GB 77 | editor | accepted | |||
GB 78 | LWG | rejected | 2010-08-07 | ||
GB 79 | LWG | rejected | 2010-11-13 | 1373 | |
GB 80 | LWG | rejected | 2010-08-07 | ||
GB 81 | editor | accepted | |||
GB 82 | editor | accepted | |||
GB 84 | editor | accepted | |||
GB 85 | LWG | modified | 2010-08-07 | 1381 | |
GB 86 | LWG | rejected | 2010-08-07 | ||
GB 87 | LWG | accepted | 2010-08-07 | 1387 | |
GB 88 | LWG | 1385 | |||
GB 89 | LWG | modified | 2010-11-13 | 1389 | N3210 |
GB 90 | editor | rejected | |||
GB 91 | editor | rejected | 2010-11-13 | N3142 | |
GB 92 | LWG | modified | 2010-11-13 | 1393 | N3142 |
GB 93 | LWG | rejected | 2010-08-07 | ||
GB 94 | editor | ||||
GB 95 | LWG | modified | 2010-11-13 | 1397 | N3198 |
GB 96 | LWG | rejected | 2010-11-13 | 1398 | |
GB 97 | LWG | rejected | 2010-08-07 | ||
GB 98 | editor | ||||
GB 99 | LWG | 1401 | |||
GB 100 | LWG | accepted | 2010-08-07 | 1402 | |
GB 101 | editor | accepted | |||
GB 102 | editor | rejected | |||
GB 103 | LWG | 1408 | |||
GB 104 | editor | accepted | |||
GB 105 | editor | rejected | |||
GB 106 | LWG | rejected | 2010-08-07 | ||
GB 107 | LWG | modified | 2010-11-13 | 1410 | N3191 |
GB 108 | editor | ||||
GB 109 | LWG | modified | 2010-11-13 | 1414 | |
GB 110 | LWG | rejected | 2010-08-07 | ||
GB 111 | editor | ||||
GB 112 | LWG | accepted | 2010-08-07 | 1417 | |
GB 113 | LWG | 1418 | |||
GB 114 | editor | modified | |||
GB 115 | LWG | 1420 | |||
GB 116 | editor | accepted | |||
GB 117 | editor | ||||
GB 118 | LWG | rejected | 2010-11-13 | 1422 | |
GB 119 | LWG | modified | 2010-11-13 | 1433 | |
GB 120 | LWG | modified | 2010-11-13 | 1435 | |
GB 121 | LWG | modified | 2010-11-13 | 1436 | |
GB 122 | LWG | 1442, 1443 | |||
GB 123 | LWG | modified | 2010-11-13 | 1414, 1444 | |
GB 124 | LWG | 1448 | |||
GB 125 | LWG | 1452 | |||
GB 126 | LWG | modified | 2010-11-13 | 1453 | N3158 |
GB 127 | LWG | 1450 | |||
GB 128 | LWG | modified | 2010-11-13 | 1455, 1454 | N3193 |
GB 129 | LWG | 1456 | |||
GB 130 | LWG | 1457 | |||
GB 131 | LWG | 1458 | |||
GB 132 | LWG | modified | 2010-11-13 | 1462 | N3193 |
GB 133 | LWG | modified | 2010-11-13 | 1469 | N3193 |
GB 134 | editor | accepted | |||
GB 135 | LWG | 1477 | |||
GB 136 | LWG | 1478 | |||
GB 137 | LWG | 1480 | |||
GB 138 | LWG | modified | 2010-11-13 | 1481 | N3197 |
GB 139 | editor | accepted | |||
GB 140 | editor | accepted | |||
GB 141 | editor | accepted | |||
GB 142 | LWG | accepted | 2010-11-13 | 1516 | |
ITTF 1 | editor | accepted | |||
ITTF 2 | editor | accepted | |||
ITTF 3 | editor | accepted | |||
ITTF 4 | editor | accepted | |||
ITTF 5 | editor | accepted | |||
ITTF 6 | editor | accepted | |||
ITTF 7 | editor | ||||
JP 1 | CWG | accepted | 2010-11-13 | 1117 | |
JP 2 | CWG | rejected | 1124 | ||
JP 3 | LWG | accepted | 2010-08-07 | 1399 | |
JP 4 | LWG | accepted | 2010-08-07 | 1400 | |
JP 5 | LWG | rejected | 2010-11-13 | 1406 | |
JP 6 | LWG | accepted | 2010-08-07 | 1423 | |
JP 7 | LWG | accepted | 2010-08-07 | ||
JP 8 | LWG | accepted | 2010-08-07 | 1425 | |
JP 9 | LWG | accepted | 2010-08-07 | 1426 | |
JP 10 | LWG | accepted | 2010-08-07 | 1427 | |
JP 11 | LWG | accepted | 2010-08-07 | 1428 | |
JP 12 | LWG | accepted | 2010-08-07 | 1429 | |
JP 13 | LWG | accepted | 2010-08-07 | 1430 | |
JP 14 | LWG | rejected | 2010-08-07 | ||
JP 15 | editor | accepted | |||
JP 16 | editor | accepted | |||
JP 17 | editor | accepted | |||
JP 18 | editor | accepted | |||
JP 19 | editor | accepted | |||
JP 20 | editor | accepted | |||
JP 21 | editor | accepted | |||
JP 22 | editor | accepted | |||
JP 23 | editor | accepted | |||
JP 24 | editor | accepted | |||
JP 25 | editor | accepted | |||
JP 26 | editor | accepted | |||
JP 27 | editor | accepted | |||
JP 28 | editor | modified | |||
JP 29 | editor | modified | |||
JP 30 | editor | accepted | |||
JP 31 | editor | accepted | |||
JP 32 | LWG | accepted | 2010-11-13 | 1395 | |
JP 33 | editor | accepted | |||
JP 34 | editor | accepted | |||
JP 35 | editor | accepted | |||
JP 36 | editor | accepted | |||
JP 37 | editor | accepted | |||
JP 38 | editor | accepted | |||
JP 39 | editor | accepted | |||
JP 40 | editor | accepted | |||
JP 41 | editor | accepted | |||
JP 42 | editor | accepted | |||
JP 43 | editor | accepted | |||
JP 44 | editor | accepted | |||
JP 45 | editor | accepted | |||
JP 46 | editor | accepted | |||
JP 47 | editor | accepted | |||
JP 48 | editor | accepted | |||
JP 49 | editor | accepted | |||
JP 50 | editor | accepted | |||
JP 51 | editor | accepted | |||
JP 52 | editor | accepted | |||
JP 53 | editor | accepted | |||
JP 54 | editor | accepted | |||
JP 55 | editor | accepted | |||
JP 56 | editor | accepted | |||
JP 57 | editor | accepted | |||
JP 58 | editor | accepted | |||
JP 59 | editor | accepted | |||
JP 60 | editor | accepted | |||
JP 61 | editor | accepted | |||
JP 62 | editor | accepted | |||
JP 63 | editor | accepted | |||
JP 64 | editor | accepted | |||
JP 65 | editor | accepted | |||
JP 67 | editor | rejected | |||
JP 68 | editor | modified | |||
JP 69 | editor | accepted | |||
JP 70 | editor | accepted | |||
JP 71 | editor | accepted | |||
JP 72 | editor | accepted | |||
JP 73 | editor | accepted | |||
JP 74 | editor | accepted | |||
JP 75 | editor | accepted | |||
JP 76 | editor | accepted | |||
JP 77 | editor | accepted | |||
JP 78 | editor | accepted | |||
JP 79 | editor | accepted | |||
JP 80 | editor | accepted | |||
JP 81 | editor | accepted | |||
JP 82 | editor | accepted | |||
JP 83 | editor | accepted | |||
JP 84 | editor | accepted | |||
JP 85 | LWG | accepted | 2010-08-07 | 1403 | |
JP 86 | editor | accepted | |||
JP 87 | editor | accepted | |||
JP 88 | editor | accepted | |||
JP 89 | editor | accepted | |||
JP 90 | editor | accepted | |||
JP 91 | editor | modified | |||
JP 92 | editor | accepted | |||
JP 93 | editor | accepted | |||
JP 94 | editor | accepted | |||
JP 95 | editor | accepted | |||
JP 96 | editor | accepted | |||
JP 97 | editor | accepted | |||
JP 98 | editor | accepted | |||
JP 99 | editor | accepted | |||
JP 100 | editor | accepted | |||
JP 101 | editor | accepted | |||
JP 102 | editor | accepted | |||
JP 103 | editor | accepted | |||
JP 104 | editor | accepted | |||
JP 105 | editor | accepted | |||
JP 106 | editor | accepted | |||
JP 107 | editor | accepted | |||
JP 108 | editor | accepted | |||
JP 109 | editor | accepted | |||
JP 110 | editor | accepted | |||
RU 1 | editor | accepted | |||
RU 2 | editor | accepted | |||
RU 3 | editor | accepted | |||
RU 4 | editor | accepted | |||
RU 5 | editor | accepted | |||
US 1 | |||||
US 2 | accepted | ||||
US 3 | CWG | accepted | 2010-11-13 | N3209 | |
US 4 | editor | accepted | |||
US 5 | editor | rejected | |||
US 6 | editor | accepted | |||
US 7 | editor | ||||
US 8 | CWG | rejected | |||
US 9 | CWG | accepted | 2010-11-13 | N3196 | |
US 10 | CWG | rejected | 2010-11-13 | N3196 | |
US 11 | CWG | accepted | 2010-11-13 | N3196 | |
US 12 | CWG | accepted | 2010-11-13 | N3196 | |
US 13 | CWG | accepted | 2010-11-13 | 1103 | |
US 14 | CWG | accepted | 2010-11-13 | 1103 | |
US 15 | CWG | accepted | 2010-11-13 | 1104 | |
US 16 | CWG | accepted | |||
US 17 | CWG | accepted | 2010-11-13 | 1107 | |
US 18 | CWG | 1108 | |||
US 19 | CWG | accepted | 2010-11-13 | 1109 | N3214 |
US 20 | editor | accepted | |||
US 21 | editor | accepted | |||
US 22 | CWG | rejected | 1110 | ||
US 23 | CWG | accepted | 1111 | ||
US 24 | CWG | accepted | 2010-11-13 | 1112 | |
US 25 | CWG | accepted | 1115 | ||
US 26 | CWG | rejected | |||
US 27 | CWG | accepted | 1116 | ||
US 28 | CWG | rejected | |||
US 29 | CWG | rejected | 974 | ||
US 30 | CWG | rejected | 975 | ||
US 31 | CWG | accepted | 1022 | ||
US 32 | CWG | accepted | 2010-11-13 | 1119 | |
US 33 | CWG | accepted | 2010-11-13 | 1121 | |
US 34 | |||||
US 35 | CWG | accepted | |||
US 36 | CWG | rejected | |||
US 37 | CWG | rejected | |||
US 38 | CWG | accepted | 2010-11-13 | N3196 | |
US 39 | CWG | accepted | 2010-11-13 | 1128 | |
US 40 | CWG | accepted | 2010-11-13 | 1130 | |
US 41 | CWG | accepted | 2010-11-13 | 1131 | |
US 42 | CWG | rejected | |||
US 43 | editor | accepted | |||
US 44 | CWG | accepted | 2010-11-13 | 1133 | N3206 |
US 45 | editor | accepted | |||
US 46 | CWG | rejected | |||
US 47 | CWG | modified | 2010-11-13 | 1134 | |
US 48 | CWG | accepted | 2010-11-13 | 1138 | |
US 49 | CWG | accepted | 2010-11-13 | 1139 | |
US 50 | CWG | accepted | 1140 | ||
US 51 | CWG | 1141 | |||
US 52 | CWG | accepted | 2010-11-13 | 1142 | |
US 53 | CWG | 1143 | |||
US 54 | CWG | accepted | |||
US 55 | CWG | rejected | |||
US 56 | CWG | accepted | 2010-11-13 | 1144 | |
US 57 | CWG | accepted | |||
US 58 | editor | rejected | |||
US 59 | CWG | accepted | |||
US 60 | CWG | accepted | |||
US 61 | editor | accepted | |||
US 62 | CWG | accepted | 2010-11-13 | 1051 | |
US 63 | CWG | accepted | 2010-11-13 | 1064 | |
US 64 | CWG | accepted | 2010-11-13 | 1066 | |
US 65 | CWG | 1150 | |||
US 66 | CWG | accepted | 1151 | ||
US 67 | CWG | modified | 2010-11-13 | 1152 | |
US 68 | CWG | accepted | 2010-11-13 | 1153 | |
US 69 | CWG | accepted | 2010-11-13 | 1154 | |
US 70 | CWG | accepted | 2010-11-13 | 1156 | |
US 71 | accepted | ||||
US 72 | CWG | accepted | |||
US 73 | CWG | accepted | 2010-11-13 | 1158 | |
US 74 | CWG | accepted | 2010-11-13 | 1159 | |
US 75 | CWG | rejected | |||
US 76 | CWG | rejected | 1163 | ||
US 77 | CWG | accepted | 2010-11-13 | 1164 | |
US 78 | CWG | accepted | 2010-11-13 | 1165 | |
US 79 | CWG | rejected | |||
US 80 | LWG | modified | 2010-11-13 | 1347 | N3155 |
US 81 | editor | modified | |||
US 82 | LWG | modified | 2010-11-13 | 1362 | |
US 83 | editor | accepted | |||
US 84 | LWG | modified | 2010-11-13 | 1370 | |
US 85 | LWG | 1374 | |||
US 86 | editor | accepted | |||
US 87 | LWG | 1375 | |||
US 88 | LWG | rejected | 2010-11-13 | 1376 | |
US 89 | editor | accepted | |||
US 90 | LWG | modified | 2010-11-13 | 1377 | N3143 |
US 91 | LWG | modified | 2010-11-13 | 1377 | N3143 |
US 92 | LWG | rejected | 2010-08-07 | ||
US 93 | rejected | 2010-08-07 | |||
US 94 | editor | accepted | |||
US 95 | LWG | modified | 2010-11-13 | 1379 | N3140 |
US 96 | LWG | modified | 2010-11-13 | 1382 | N3140 |
US 97 | LWG | modified | 2010-11-13 | 1383 | N3140 |
US 98 | LWG | accepted | 2010-08-07 | 1384 | |
US 99 | LWG | accepted | 2010-08-07 | 1386 | |
US 100 | LWG | accepted | 2010-08-07 | 1388 | |
US 101 | LWG | rejected | 2010-08-07 | ||
US 102 | LWG | modified | 2010-11-13 | 1392 | N3123 |
US 103 | LWG | rejected | 2010-08-07 | ||
US 104 | LWG | 1396 | |||
US 105 | LWG | rejected | 2010-08-07 | ||
US 106 | LWG | modified | 2010-11-13 | 1404 | |
US 107 | LWG | accepted | 2010-08-07 | 1405 | |
US 108 | LWG | modified | 2010-08-07 | 1407 | N3109 |
US 109 | editor | accepted | |||
US 110 | LWG | rejected | 2010-08-07 | ||
US 111 | LWG | modified | 2010-11-13 | 1409 | N3191 |
US 112 | LWG | 1413 | |||
US 113 | LWG | rejected | 2010-08-07 | ||
US 114 | LWG | modified | 2010-08-07 | N3108 | |
US 115 | editor | modified | 2010-11-13 | N3173 | |
US 116 | editor | rejected | |||
US 117 | LWG | accepted | 2010-08-07 | 1419 | |
US 118 | LWG | rejected | 2010-08-07 | ||
US 119 | LWG | rejected | 2010-08-07 | ||
US 120 | LWG | accepted | 2010-08-07 | 1431 | |
US 121 | LWG | modified | 2010-11-13 | 1432 | |
US 122 | LWG | modified | 2010-08-07 | 1434 | N3106 |
US 123 | editor | ||||
US 124 | LWG | accepted | 2010-11-13 | 1437 | |
US 125 | editor | ||||
US 126 | LWG | 1438 | |||
US 127 | editor | ||||
US 128 | editor | ||||
US 129 | editor | ||||
US 130 | editor | ||||
US 131 | editor | ||||
US 132 | editor | ||||
US 133 | editor | ||||
US 134 | LWG | accepted | 2010-11-13 | 1439 | |
US 135 | LWG | accepted | 2010-11-13 | 1440 | |
US 136 | LWG | accepted | 2010-08-07 | 1441 | |
US 137 | LWG | modified | 2010-11-13 | 1445 | N3168 |
US 138 | LWG | rejected | 2010-11-13 | 1446 | N3179 |
US 139 | LWG | modified | 2010-11-13 | 1447 | N3168 |
US 140 | LWG | rejected | 2010-08-07 | ||
US 141 | LWG | 1451 | |||
US 142 | editor | accepted | |||
US 143 | editor | accepted | |||
US 144 | editor | accepted | |||
US 145 | editor | accepted | |||
US 146 | editor | accepted | |||
US 147 | editor | accepted | |||
US 148 | editor | rejected | |||
US 149 | editor | accepted | |||
US 150 | editor | accepted | |||
US 151 | editor | accepted | |||
US 152 | editor | rejected | |||
US 153 | editor | rejected | |||
US 154 | LWG | 1460 | |||
US 155 | editor | accepted | |||
US 156 | editor | accepted | |||
US 157 | LWG | modified | 2010-11-13 | 1463 | N3193 |
US 158 | editor | accepted | |||
US 159 | editor | accepted | |||
US 160 | LWG | modified | 2010-11-13 | 1464 | N3193 |
US 161 | LWG | modified | 2010-11-13 | 1465 | N3193 |
US 162 | LWG | modified | 2010-11-13 | 1466 | N3193 |
US 163 | LWG | modified | 2010-11-13 | 1467 | N3193 |
US 164 | LWG | modified | 2010-11-13 | 1468 | N3193 |
US 165 | LWG | 1470 | |||
US 166 | editor | accepted | |||
US 167 | editor | rejected | |||
US 168 | LWG | accepted | 2010-11-13 | 1471 | N3196 |
US 169 | editor | rejected | |||
US 170 | editor | rejected | |||
US 171 | LWG | accepted | 2010-11-13 | 1472 | N3196 |
US 172 | LWG | rejected | 2010-11-13 | 1473 | |
US 173 | editor | accepted | |||
US 174 | editor | rejected | |||
US 175 | LWG | 1474 | |||
US 176 | editor | rejected | |||
US 177 | LWG | 1476 | |||
US 178 | editor | modified | |||
US 179 | LWG | 1479 | |||
US 180 | editor | accepted | |||
US 181 | LWG | modified | 2010-11-13 | 1482 | N3191 |
US 182 | LWG | rejected | 2010-08-07 | ||
US 183 | LWG | rejected | 2010-11-13 | 1484 | |
US 184 | LWG | 1485 | |||
US 185 | LWG | rejected | 2010-11-13 | 1488 | |
US 186 | LWG | modified | 2010-11-13 | 1491 | N3209 |
US 187 | editor | modified | |||
US 188 | LWG | modified | 2010-11-13 | 1492 | N3197 |
US 189 | LWG | rejected | 2010-11-13 | 1493 | |
US 190 | LWG | 1494 | |||
US 191 | LWG | modified | 2010-11-13 | 1495 | N3191 |
US 192 | editor | accepted | |||
US 193 | LWG | rejected | 2010-11-13 | 1499 | |
US 194 | LWG | modified | 2010-11-13 | 1501 | N3192 |
US 195 | LWG | 1502 | |||
US 196 | LWG | 1504 | |||
US 197 | LWG | 1505 | |||
US 198 | LWG | accepted | 2010-08-07 | 1506 | |
US 199 | LWG | 1507 | |||
US 200 | editor | accepted | |||
US 201 | LWG | modified | 2010-11-13 | 1508 | N3194 |
US 202 | LWG | modified | 2010-11-13 | 1509 | N3194 |
US 203 | LWG | modified | 2010-11-13 | 1510 | N3194 |
US 204 | LWG | modified | 2010-11-13 | 1511 | N3194 |
US 205 | LWG | modified | 2010-11-13 | 1512 | N3194 |
US 206 | editor | accepted | |||
US 207 | LWG | 1514 | |||
US 208 | LWG | 1515 |
The following table lists the comments for which no resolution has yet been proposed.
ID | Ref | Comment | Proposed Resolution | Owner | Issue | Disposition |
---|---|---|---|---|---|---|
ITTF 1 | General | The ISO/IEC headers and footers should appear at the top and bottom of every page. | Insert the ISO/IEC headers and footers at the top and bottom of every page. | editor | ACCEPTED | |
US 1 | 1-30 | It appears that the C committee could possibly make some changes for C1X that we may still want to follow for C++0X to avoid gratuitous incompatibilities. | Make any appropriate changes to avoid unnecessary incompatibilities with C1X resulting from changes to the WG14 C standard draft. | |||
US 2 | 1-30 | The active issues identified in the CWG and LWG issues lists as if the date that the FCD was published (N3083 and N3087) must be addressed and appropriate action taken. | Appropriate action would include making changes to the FCD, identifying an issue as not requiring a change to the FCD, or deferring an issue to a later draft or a later standard. | ACCEPTED | ||
DE 1 | 1 through 15 | Consider applying the resolutions of the active core issues in Ready status (see WG21 N3083). | ACCEPTED | |||
CH 1 | all | The issues on the issues lists (WG21 N3083 and N3087) shall be addressed before the standard becomes final. | ACCEPTED | |||
US 3 | 1 - 29 | The threading model does not make basic guarantees needed to write correct programs. We should not repeat the error that POSIX made in early standards (and later corrected). | Add requirements that all no-blocked threads will (however slowly) make progress and that all visible side effects will (eventually) be seen by other threads. Possibly use the word “should” if an absolute requirement is impossible. | CWG |
ACCEPTED
See paper N3209 |
|
US 4 | all ¶ all | Many identifiers are hyphenated and broken across line boundaries. As a consequence, searching for the identifier fails. | Protect all identifiers against hyphenation. | editor | ACCEPTED | |
US 5 | all ¶ all | The word "object" often copies as "ob ject". | editor |
REJECTED
Some PDF viewers do this. Don't know why, or how to avoid it. |
||
US 6 | various ¶ various | ~ (U+007E) is sometimes replaced with ∼ (U+223C), causing cut and paste from the standard to fail, notably in 2.14.5. | Use U+007E consistently | editor | ACCEPTED | |
US 7 | various ¶ various | ' (U+0027) is consistently replaced with ’ (U+2019), causing cut and paste to fail. This is also an issue with the 1998 standard. | Use U+0027 consistently in code samples (i.e. monospace font) | editor | ||
GB 1 | 1.1 ¶ 2 | The C99 standard supports inline functions, so this should not be listed as a distinguishing feature of C++. | strike "inline functions" from the list of C++ 'additional facilities' | editor | ACCEPTED | |
GB 2 | 1.2 | In [intro.refs] the spec references ISO/IEC 9945:2003 even though a later revision, ISO/IEC 9945:2008 has already been released: http://www.iso.org/iso/catalogue_detail.htm?csnumber=50 516 |
The section should be updated to reference the
latest version. In addition, since POSIX is a registered trademark of the IEEE, the spec should use the registered trademark (R) symbol wherever it references it. Alternatively, it can refer to ISO/IEC 9945. |
editor | ||
ITTF 2 | 1.2 | The introductory text to the Normative references is not correct. |
Delete the current introductory text to the
Normative references and replace with the
following: “The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.” |
editor | ACCEPTED | |
ITTF 3 | 1.3 | The title to the subclause does not accurately reflect the content. | Change the title to “Terms and definitions”. | editor | ACCEPTED | |
ITTF 4 | 1.3 | 3.1 of the ISO/IEC Directives, Part 2, states that the following introductory wording shall be used where all terms and definitions are given the document itself: “For the purposes of this document, the following terms and definitions apply.” |
Change the introductory text to: “For the purposes of this document, the following terms and definitions apply.” |
editor | ACCEPTED | |
ITTF 5 | 1.3 | D.1.5.3 of the ISO/IEC Directives, Part 2 states that the form of a definition shall be such that it can replace the term in context. |
Delete the definite or indefinite article at the
beginning of each definition. Redraft definitions 1.3.11 and 1.3.13 so that they can replace the term in context (i.e. they should not be more than one sentence). |
editor | ACCEPTED | |
ITTF 6 | 1.3 | D.3.1 of the ISO/IEC Directives, Part 2, states that the definition shall not be followed by a full stop. | Remove the full stops at the end of the definitions. | editor | ACCEPTED | |
ITTF 7 | 1.3 | D.3.9 of the ISO/IEC Directives, Part 2, provides examples on how to present examples and notes to terms and definitions. The examples and notes to the terms and definitions are not presented in accordance with D.3.9 of the ISO/IEC Directives, Part 2. | Redraft the notes and examples to the terms and definitions in accordance with D.3.9 of the ISO/IEC Directives, Part 2. | editor | ||
GB 3 | 1.3 ¶ 1 | The library stretches out to clause 30 now, and the terms in 17.3 should cover them too. | Update reference to clause 27 to say clause 30. | editor | ACCEPTED | |
JP 15 | 1.3 ¶ 1 | There is a description, "17.3 defines additional terms that are used only in Clauses 17 through 27 and Annex D.", but the terms defined in 17.3 are also used in Clauses 28 through 30, which are added recently. So the scope should be expanded to include them. | 17.3 defines additional terms that are used only in Clauses 17 through 30 and Annex D. | editor | ACCEPTED | |
GB 4 | 1.3.10 | The phrase "catch clause" in the 2003 standard has become "catch Clause" | Change back the "catch clause" | editor | ACCEPTED | |
RU 1 | 1.7 ¶ p.5, line 5 from end | Reference missed | Insert reference "(2.3)" after "basic execution character set" | editor | ACCEPTED | |
GB 5 | 1.9 ¶ 3 | The evaluation of function arguments are now indeterminately sequenced, rather than left completely unspecified, as part of the new language describing the memory model. A clearer example of unspecified behavior should be used here. | [Need to identify a better example to propose] | editor | ACCEPTED | |
GB 6 | 1.9 ¶ 4 | There are core issues surrounding the undefined behavior of dereferencing a null pointer. It appears the intent is that dereferencing *is* well defined, but using the result of the dereference will yield undefined behavior. This topic is too confused to be the reference example of undefined behavior, or should be stated more precisely if it is to be retained. | [Identify a better example of undefined behavior to propose] | CWG | 1102 | ACCEPTED |
CH 2 | 1.9 and 1.10 | It's not clear whether relaxed atomic operations are observable behaviour. | Clarify it. | CWG |
REJECTED
Normatively, the behavior is well-defined by 1.9p8. If the atomic object is volatile, then all operations on it are observable, otherwise not. Note that “observable” means “observable outside of the program.” See paper N3196 |
|
GB 7 | 1.9.6 ¶ p6 | From a naive, first-time reader's point of view, 1.9.6 made me double take, as it seemed it could imply any signal would leave the program in an unspecified state after completing. I believe I understand the intent, but to clarify it, I'd change it to make it clear that the unspecified state applies only for the duration of the signal handler. |
Change: 6 When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects which are neither of type volatile std::sig_atomic_t nor lock-free atomic objects (29.4) are unspecified, and the value of any object not in either of these two categories that is modified by the handler becomes undefined. to: 6 When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects which are neither of type volatile std::sig_atomic_t nor lock-free atomic objects (29.4) are unspecified for the duration of the signal handler, and the value of any object not in either of these two categories that is modified by the handler becomes undefined. |
CWG | 1173 |
ACCEPTED
The reference should be 1.9 paragraph 6, not 1.9.6 (which does not exist). |
US 8 | 1.9 ¶ footnote 7 | The footnote "Overloaded operators are never assumed to be associative or commutative." is either meaningless or overly restrictive. | Change the footnote to "Overloaded operators are assumed to be non-associative and noncommutative until proven otherwise.". | CWG |
REJECTED
The statement involved is non-normative and is, in general, correct. An implementation can treat overloaded operators as associative or commutative only under the “as-if” rule, so the statement is clear enough. |
|
CA 23 | 1.10, 29 ¶ 1.10, 29 | C1x has added new atomics C1x has added new atomics syntax, and in some cases new semantics and operations. C++0x needs to consider aligning with the new C1x atomics | Add back compatibility between C++0x and C1x atomics | LWG |
ACCEPTED with MODIFICATIONS
See paper N3193 |
|
CA 14 | 1.10p4 ¶ 1.10p4 |
Initialisation of atomics
Add the following to 1.10p4:
[ Note: There may be non-atomic writes to atomic
objects, for example on initialization and reinitialization.
- end note]
Rationale: We believe the intent is that for any atomic
there is a distinguished initialisation write, but that this
need not happens-before all the other operations on that
atomic - specifically so that the initialisation write might be
non-atomic and hence give rise to a data race, and hence
undefined behaviour, in examples such as this (from
Hans):
atomic< atomic<int> * > p f() | { atomic<int>x; | W_na x p.store(&x,mo_rlx); | W_rlx p=&x } |(where na is nonatomic and rlx is relaxed). We suspect also that no other mixed atomic/nonatomic access to the same location is intended to be permitted. The possibility of non-atomic writes on atomic objects is not mentioned in 1.10, and (before talking with Hans) we didn't realise it was intended, so we suggest adding the note above to clarify things. |
Add the following to 1.10p4: [ Note: There may be non-atomic writes to atomic objects, for example on initialization and renitialization. - end note] |
CWG |
ACCEPTED with MODIFICATIONS
The suggested update from US 168 was adopted. See paper N3196 |
|
CA 12 | 1.10p6 ¶ 1.10p6 |
The use of maximal in the definition of release sequence
(proposed edit seems reasonable to Clark) We suggest that 1.10p6 be changed to: A release sequence from a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A, and every subsequent operation - is performed by the same thread that performed the release, or - is an atomic read-modify-write operation. Rationale: The current wording of the standard suggests that release sequences are maximal with respect to sequence inclusion, i.e. that if there are two release operations in the modification order, mod mod rel1----->rel2----->wthen [rel1;rel2;w] is the only release sequence, as the other candidate [rel2;w] is included in it. This interpretation precludes synchronizing with releases which have other releases sequenced-before them. We believe that the intention is actually to define the maximal release sequence from a particular release operation, which would admit both [rel1;rel2;w] and [rel2;w]. |
We suggest that 1.10p6 be changed to: A release sequence from a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A, and every subsequent operation - is performed by the same thread that performed the release, or - is an atomic read-modify-write operation. |
CWG | 1176 | ACCEPTED |
US 9 | 1.10 ¶ para 4 | The "operations on locks" do not provide synchronization, as locks are defined in Clause 30. | Change "operations on locks" to "locking operations". | CWG |
ACCEPTED
See paper N3196 |
|
CA 20 | 1.10p1 ¶ 1.10p1 |
Reading from the last element in a vsse?
Paul wrote: > If every element in a vsse happens-before a given value > computation, then that value computation must return > the value stored by the last element in the vsse. We wrote: We're not sure about that. Consider the following, with two relaxed writes to x on one thread that are not sequencedbefore related to each other (eg in different arguments to the same function), but are followed by a release/acquire on a different variable y to another thread that then reads x. We think the final read (e) could read from either (a) or (b), regardless of how (a) and (b) are related in modification order. a:Wrlx x=1 b:Wrlx x=2 \ / sb\ /sb \ / c:Wrel y----------- \sw \ d:Racq y | |sb | e:Rrlx x=?| Paul> In that case IIRC, the standard does not specify Paul> the order, but the code will be generated in some Paul> order, and that arbitrary choice on the part of the Paul> compiler will determine the modification order. We agree that in a normal implementation (eg where the argument evaluations are not spawned off to new threads - is that intended to be forbidden?), the two writes will indeed be ordered according to the generated-code order (and before the release fence), and hardware coherence will ensure that (e) reads the later one. But in the draft standard as written, that execution is allowed - the draft doesn't currently impose that aspect of coherence. To make the example more concrete, if there were another thread with c --sw--> f:Racq y --sb--> g:Rrlx xthen e and g could read different values. Paul notes: > But 1.10p1 says: > > A thread of execution (also known as a thread) is a > single flow of control within a program, including > the initial invocation of a specific top-level > function, and recursively including every function > invocation subsequently executed by the thread. > > This excludes the possibility of the implementation > spawing off a new thread -unless- the implementation > can make things appear as if there was only one thread. > From this viewpoint, your example shows just how > careful an implementation must be if it is to fully > comply with this as-if rule. We replied >ok, thanks to this, but in fact the situation is still unclear. 1.10p1 does indeed rule out the hypothetical implementation that we mentioned, but even if (a) and (b) would be ordered by any reasonable implementation, in terms of the concepts of the standard, that doesn't introduce a sequenced-before edge between (a) and (b). It seems that Paul is assuming the individual memory accesses in function arguments are indeterminately sequenced rather than unsequenced? |
Please clarify. | CWG |
ACCEPTED
See paper N3196 |
|
CA 19 | 1.10p5 1.10p13 ¶ 1.10p5 1.10p13 |
Alternative definition of the value read by an atomic
operation Here's an interesting example involving a release/consume pair. We believe that in a direct implementation on hardware, this would be forbidden by coherence, but that the current text allows it. We don't know whether it should be allowed or not. hb do rf Wx_release ----> Rx_consume ^ | \ |sb,hb mo \ v --- Wx_releasePaul claims this is forbidden by 1.10p5, but we don't see how that can be the case. We don't see much room in 1.10p5 for any other interpretation - it says: - "All modifications to a particular atomic object M occur in some particular total order, called the modification order of M" - "If A and B are modifications of an atomic object M and A happens before (as defined below) B, then A shall precede B in the modification order of M, which is defined below." Both of which seem very clear. The only wiggle room is in the Note - "[Note: This states that the modification orders must respect the "happens before" relationship]" We took that "must respect" to be a gloss rather than to add any additional constraint. Earlier we suggested a change, to the constraint on the value read by an atomic operation, that would forbid this example: The standard introduces visible side effects, which are used first to define the values read by non-atomic operations. They are then re-used to constrain the value read by atomic operations: 1.10p13 says that an atomic operation must read from somewhere in "the" visible sequence of side effects, which must start from *a* visible side effect, i.e. a side effect that (a) happens before the read, and (b) is not happens-before-hidden. We suspect that this re-use of the notion of visible side effect may be a drafting artifact, in which case one might remove the requirement that there is a vse for atomics, and replacing the first two sentences of 1.10p13 by "An atomic operation must read from somewhere in the modification order that is not happens-before-hidden and does not follow (in modification order) any side effect that happens-after the read."BR/> Now we're not sure how this would fit in with initialisation and reading of indeterminate values; we need to think about it more. |
Please clarify. | CWG |
ACCEPTED
See paper N3196 |
|
CA 22 | 1.10p8 ¶ 1.10p8 |
Control dependencies for atomics Given the examples of compilers interchanging data and control dependencies, and that control dependencies are architecturally respected on Power/ARM for load->store (and on Power for load->load with a relatively cheap isync), we're not sure why carries-a-dependency-to does not include control dependencies between atomics. |
Please clarify. | CWG |
REJECTED
At the time that the memory model was formulated, there was considerable uncertainty as to what architectures respect control dependencies, and to what extent. It appears that this uncertainty is being cleared up, and our hope is that it will be ripe for standardization in a later TR. See paper N3196 |
|
CA 15 | 1.10p9 ¶ 1.10p9 |
Intra-thread dependency-ordered-before The current draft has release/acquire synchronize-with edges only between a release on one thread and an acquire on a *different* thread, whereas the definition of dependency-ordered-before permits the release and consume to be on the same thread; it seems odd to permit the latter. (At the moment function arguments can't race or sync with each other, but they can be dependency ordered before each other.) We don't currently have an example in which this makes a real difference, but for symmetry could suggest changing the definition of dependency-ordered-before in 1.10p9 to the following: An evaluation A is dependency-ordered before an evaluation B if - A performs a release operation on an atomic object M, and on another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, or - for some evaluation X, A is dependency-ordered before X and X carries a dependency to B. |
We suggest changing the definition of
dependency-ordered-before in 1.10p9 to the
following: An evaluation A is dependency-ordered before an evaluation B if - A performs a release operation on an atomic object M, and on another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, or - for some evaluation X, A is dependency-ordered before X and X carries a dependency to B. |
CWG | 1177 |
ACCEPTED
See paper N3196 |
CA 11 | 1.10p12 ¶ 1.10p12 |
"Subsequent" in vsse definition Remove the word "subsequent" from the definition of visible sequence of side effects in 1.10p12. (as suggested by Hans) Rationale: if every element in a vsse happens-before a read, the read should not take the value of the visible side effect. |
Remove the word "subsequent" from the definition of visible sequence of side effects in 1.10p12. | CWG |
ACCEPTED
See paper N3196 |
|
CA 17 | 1.10p12 ¶ 1.10p12 |
1.10p12 phrasing 1.10p12 last note: "...as defined here..." should be "...as defined below...". |
1.10p12 last note: "...as defined here..." should be "...as defined below...". |
editor |
REJECTED
The reference really should be to "data races as defined in this International Standard", because the note compares this definition with the generally-understood meaning of data races in sequentially-consistent executions. That's far too stilted, and "as defined here" seems like a reasonable way to phrase it in the less formal context of a note. |
|
CA 13 | 1.10p13 ¶ 1.10p13 |
Wording of the read-read coherence condition In 1.10p13 a coherence condition is stated on the values of atomic reads: "Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and the value computed by A corresponds to the value stored by side effect X, then the value computed by B shall either equal the value computed by A, or be the value stored by side effect Y, where Y follows X in the modification order of M." We suggest that this be replaced with the following: "Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from the side effect X, then the value computed by B shall either be the value stored by X, or the value stored by a side effect Y, where Y follows X in the modification order of M." Rationale: The words "corresponds to" are not used elsewhere in the standard, as far as we can see, and it is unclear whether they have a special meaning here. In addition taking the value of the read B from the value read by A seems unnecessarily indirect. B could take its value from X instead. |
In 1.10p13 a coherence condition is stated on the
values of atomic reads: "Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and the value computed by A corresponds to the value stored by side effect X, then the value computed by B shall either equal the value computed by A, or be the value stored by side effect Y, where Y follows X in the modification order of M." We suggest that this be replaced with the following: "Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from the side effect X, then the value computed by B shall either be the value stored by X, or the value stored by a side effect Y, where Y follows X in the modification order of M." |
CWG |
ACCEPTED
See paper N3196 |
|
CA 18 | 1.10p13 ¶ 1.10p13 |
Non-unique visible sequences of side effects and
happens-before ordering In 1.10p13, replace "The visible sequence of side effects on..." by "A visible sequence of side effects on..." and "in the visible sequence of M with respect to B" by "in a visible sequence of M with respect to B" Rationale: the current standard allows multiple visible sequences of side effects (vsse's) for a given read (despite the use of "The" at the start of 1.10p13). We demonstrate this by constructing an execution with two vsse's. The following execution has five memory operations, four of which are read modify writes (RMW's). There are two threads, one with four operations each ordered by sequenced before (sb), the other with a single RMW release. RMW1 +---RMW3_release | / |sb do/ v / R_consume<---+ | |sb v RMW2 | |sb v RMW4The modification order in this example is as follows: mod mod mod RMW1----->RMW2----->RMW3_release----->RMW4With the modification order we give above, the happens-before relation has exactly these edges, according to 1.10p10: From sequenced-before: RMW1 -> R_consume, RMW2, RMW4 R_consume -> RMW2, RMW4 RMW2 -> RMW4 From ithb: From dependency-ordered-before: RMW3_release -> R_consumeIn particular, there are no edges RMW3_release -> RMW2 or RMW4.As we understand it, this is the intended absence of transitivity from dependency-orderedbefore to sequenced-before. 1.10p5 says that if A happens-before B then A precedes B in the modification order, which is true for all the happensbefore edges and the modification order above. RMW1 and RMW3_release are visible side effects RMW2 and RMW4 follow R_consume in happens-before, so cannot be in a visible sequence of side effects. Hence the two visible sequences of side effects are [RMW1] and [RMW3]. The R_consume here must read from the later vsse in modification order for the dependency_ordered edge to exist. The existence of two vsse's relies on the lack of transitivity of happens before (which only occurs in the presence of consume operations). |
In 1.10p13, replace "The visible sequence of side effects on..." by "A visible sequence of side effects on..." and "in the visible sequence of M with respect to B" by "in a visible sequence of M with respect to B" |
CWG |
ACCEPTED
See paper N3196 |
|
US 10 | 1.10 ¶ Paragraph 14 | The definition of a data race does not take into account two overlapping atomic operations |
Augment the first sentence: The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic (or both are atomic and operate on overlapping, but not-identical, memory locations), and neither happens before the other. |
CWG |
REJECTED
The premise is incorrect; atomic objects may not overlap. The type argument to the atomic template must be a trivially-copyable type (29.5.3p1) and atomic objects are not trivially copyable. The atomic types provide no means to obtain a reference to internal members; all atomic operations are copy-in/copy-out. In short, any attempt to generate a pair of atomic variables whose memory overlaps results in undefined behavior. See paper N3196 |
|
US 11 | 1.10 ¶ para7 | There is some confusion between locks and mutexes. | Change "lock" when used as a noun to "mutex". | CWG |
ACCEPTED
See paper N3196 |
|
US 12 | 1.10 ¶ P4,p14, p6,p12,p13 |
Adapt N3074: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3074.html |
Proposed change in N3074: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3074.html | CWG |
ACCEPTED
See paper N3196 |
|
CA 2 | various ¶ various | Canada agrees with US 12, 14, 142, 145, 159 | Resolve as suggested in these comments | |||
GB 8 | 1.10 ¶ 4, 7 | The text says that the library "provides ... operations on locks". It should say "operations on mutexes", since it is the mutexes that provide the synchronization. A lock is just an abstract concept (though the library types unique_lock and lock_guard model ownership of locks) and as such cannot have operations performed on it. This mistake is carried through in the notes in that paragraph and in 1.10p7 |
Change 1.10p4 as follows: "The library defines a number of atomic operations (Clause 29) and operations on mutexes (Clause 30) that are specially identified as synchronization operations. These operations play a special role in making assignments in one thread visible to another. A synchronization operation on one or more memory locations is either a consume operation, an acquire operation, a release operation, or both an acquire and release operation. A synchronization operation without an associated memory location is a fence and can be either an acquire fence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomic operations, which are not synchronization operations, and atomic read-modify-write operations, which have special characteristics. [ Note: For example, a call that acquires a lock on a mutex will perform an acquire operation on the locations comprising the mutex. Correspondingly, a call that releases the same lock will perform a release operation on those same locations. Informally, performing a release operation on A forces prior side effects on other memory locations to become visible to other threads that later perform a consume or an acquire operation on A. “Relaxed” atomic operations are not synchronization operations even though, like synchronization operations, they cannot contribute to data races. end note ]" Change 1.10p7 as follows: "Certain library calls synchronize with other library calls performed by another thread. In particular, an atomic operation A that performs a release operation on an atomic object M synchronizes with an atomic operation B that performs an acquire operation on M and reads a value written by any side effect in the release sequence headed by A. [ Note: Except in the specified cases, reading a later value does not necessarily ensure visibility as described below. Such a requirement would sometimes interfere with efficient implementation. end note ] [ Note: The specifications of the synchronization operations define when one reads the value written by another. For atomic objects, the definition is clear. All operations on a given mutex occur in a single total order. Each lock acquisition “reads the value written” by the last lock release on the same mutex. —end note ]" |
CWG |
ACCEPTED
See paper N3196 |
|
GB 9 | 1.10 ¶ 6 | See (B) in attachment Appendix 1 - Additional Details | Request the concurrency working group to determine if changes are needed | CWG | 1176 | ACCEPTED |
GB 10 | 1.10 ¶ 10 |
See (C) in attachment Appendix 1 - Additional Details The GB would like WG21 to confirm there is no issue related to this. GB adds: We agree that if the read from x reads the value written by the write to x the write to x inter-thread-happens-before the write to y. However, the read from y is sequenced before the write to x, so if the read from x reads the value written by the write to x, then the read from y also inter-thread-happens-before the write to y. Consequently, the read from y cannot see the value written by the write to y. The reciprocal ordering also applies, but they cannot both apply in the same execution since if the write to x happens-before the read from x then the read from y happens-before the write to y, and vice-versa. There is thus no contradiction. [see comment below for proper formatting] |
Request the concurrency working group to determine if changes are needed | CWG |
ACCEPTED
See paper N3196 |
|
CA 8 | 1.10p10 ¶ 1.10p10 |
Rationale: Without this the standard
permits executions with a cyclic
happens-before relation that it seems
clear should be forbidden, e.g.
Rx_consume<--+ +-->Ry_consume | rf\ /rf | |sb X |sb v / \ v Wy_release---+ +---Wx_releaseOne could instead impose acyclicity on happens-before; that would be equivalent. |
1.10p10, before the Note, add: "The inter-thread happens-before relation of an execution must be acyclic" |
CWG |
ACCEPTED
See paper N3196 |
|
GB 11 | 1.10 ¶ 12 |
See (E) in attachment Appendix 1 - Additional Details
The GB would like WG21 to confirm there is no issue
related to this. GB adds: [see comment below for proper formatting] The variable in question has a single modification order, which is any of (a) RMW3, RMW1, RMW2, RMW4. (b) RMW1, RMW3, RMW2, RMW4. (c) RMW1, RMW2, RMW3, RMW4. (d) RMW1, RMW2, RMW4, RMW3. since RMW1, RMW2 and RMW4 occur in a single thread in that sequence, and RMW3 occurs in a separate thread with no other ordering constraints. Since the R_consume lies between RMW1 and RMW2 in that thread, it must either read the value written by RMW1 (which could happen if it immediately follows RMW1 in any of the sequences), or RMW3 (which could happen with sequence (b)). The visible sequence of side effects for R_consume is thus either RMW3, RMW1 (from (a)), RMW1 (from (b), (c) or (d)), or RMW1, RMW3 (from (b)). Which sequence applies in practice may vary from execution to execution. There is however only a single sequence on any given execution. |
Request the concurrency working group to determine if changes are needed | CWG |
ACCEPTED
See paper N3196 |
|
GB 12 | 1.10 ¶ 13 |
See (F) in attachment Appendix 1 - Additional Details The GB would like WG21 to confirm there is no issue related to this. GB adds: The cycle given is clearly forbidden by the current text. The read is sequenced-before the write in the same thread. If the read sees the value written by the other thread then that write is dependency-ordered-before the read, and thus happens-before the read, and happens-before the write from the reading thread. The write from the left-hand thread thus must occur before the write from the right-hand thread in the modification order of the object by 1.10p5. |
Request the concurrency working group to determine if changes are needed | CWG |
ACCEPTED
See paper N3196 |
|
GB 13 | 1.10 ¶ 13 |
See (G) in attachment Appendix 1 - Additional Details GB suggests alternative wording to that in the attached paper: "Furthermore, if a value computation A of an atomic object M happens before a value computation B of M, and A uses the value of M from the side effect X, then the value computed by B shall either be the value stored by X, or the value stored by a side effect Y, where Y follows X in the modification order of M." |
Request the concurrency working group to determine if changes are needed | |||
GB 14 | 1.10 ¶ 8 |
See (I) in attachment Appendix 1 - Additional Details GB adds: If an implementation can't guarantee the ordering it should refrain from performing the optimisation |
Request the concurrency working group to determine if changes are needed. | CWG |
REJECTED
We agree that the implementation needs to address this, and it can. |
|
GB 15 | 1.10 | See (J) in attachment Appendix 1 - Additional Details | Request the concurrency working group to determine if changes are needed. | CWG |
REJECTED
At the time that the memory model was formulated, there was considerable uncertainty as to what architectures respect control dependencies, and to what extent. It appears that this uncertainty is being cleared up, and our hope is that it will be ripe for standardization in a later TR. See paper N3196 |
|
GB 16 | 1.10 ¶ 12 | See (L) in attachment Appendix 1 - Additional Details | "...as defined here..." should be "...as defined below...". | editor |
REJECTED
"As defined here" refers to this standard, which is the intention. If it were normative text the correct phrase would be "in this International Standard", but for a note, the text as written is sufficient. |
|
US 13 | 2.2 ¶ 1 | “Raw” strings are still only Pittsburgh-rare strings: the reversion in phase 3 only applies to an r-char-sequence. | Make the reversion apply to the entire raw-string. | CWG | 1103 | ACCEPTED |
US 14 | 2.2 2.3 2.5 2.14.5 ¶ P1 |
Precedence of reversal and tokenization The current paper implies that determination of the characters forming an r-char-sequence occurs while the transformations done in phase 1 and phase 2 are still in effect. Consider these cases:
Escape sequences and universal-character-names in non-raw string literals have the same meaning as in character literals .... should be reflected in [lex.phases] paragraph 1, phase 5 (CD2 wording): Each source character set member and universal-character-name in a character literal or a string literal, as well as each escape sequence in a character literal or a non-raw string literal, is converted to the corresponding member of the execution character set (2.14.3, 2.14.5); if there is no corresponding member, it is converted to an implementation-defined member other than the null (wide) character and [lex.charset] paragraph 2 (CD2 wording): Additionally, if the hexadecimal value for a universal-character-name outside the c-char-sequence, s-char-sequence, or r-char-sequence of a character or string literal corresponds to a control character (in either of the ranges 0x00-0x1F or 0x7F-0x9F, both inclusive) or to a character in the basic source character set, the program is ill-formed. UCNs simply do not occur in the grammar for r-char-sequence anyway. |
In 2.14.5 [lex.string] paragraph 2: Remove
footnote 24: In 2.2 [lex.phases] paragraph 1, phase 1; insert exception: Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary. The set of physical source file characters accepted is implementation-defined. Trigraph sequences (2.4) are replaced by corresponding single-character internal representations. Any source file character not in the basic source character set (2.3) is replaced by the universal-character-name that designates that character. (An implementation may use any internal encoding, so long as an actual extended character encountered in the source file, and the same extended character expressed in the source file as a universal-character-name (i.e., using the \uXXXX notation), are handled equivalently except where this replacement is reverted.) In 2.2 [lex.phases] paragraph 1, phase 3: The source file is decomposed into preprocessing tokens (2.5) and sequences of white-space characters (including comments). A source file shall not end in a partial preprocessing token or in a partial comment. Each comment is replaced by one space character. New-line characters are retained. Whether each nonempty sequence of white-space characters other than newline is retained or replaced by one space character is unspecified. The process of dividing a source file's characters into preprocessing tokens is contextdependent. [ Example: see the handling of < within a #include preprocessing directive. —end example ] In 2.2 [lex.phases] paragraph 1, phase 5: Each source character set member in a character literal or a string literal, as well as each escape sequence and universal-character-name in a character literal or a non-raw string literal, is converted to the corresponding member of the execution character set (2.14.3, 2.14.5); if there is no corresponding member, it is converted to an implementation-defined member other than the null (wide) character. In 2.3 [lex.charset] paragraph 2: .... Additionally, if the hexadecimal value for a universal-character-name outside the c-char-sequence or s-char-sequence of a character or string literal corresponds to a control character (in either of the ranges 0x000x1F or 0x7F 0x9F, both inclusive) or to a character in the basic source character set, the program is ill-formed. [ Footnote: A sequence of characters resembling a universal-character-name in an r-char-sequence (2.14.5 [lex.string]) does not form a universal-character-name. ] In 2.5 [lex.pptoken] paragraph 3: If the input stream has been parsed into preprocessing tokens up to a given character:
|
CWG | 1103 | ACCEPTED |
US 15 | 2.6 ¶ para 2 | The <: digraph causes problem with users unfamiliar with digraphs when passing global objects as template arguments. | Add a special hack for <:: much like the special hack for >>. | CWG | 1104 | ACCEPTED |
CA 24 | 2.11 ¶ Various |
A list of issues related TR 10176:2003 1) "Combining characters should not appear as the first character of an identifier." Reference: ISO/IEC TR 10176:2003 (Annex A) This is not reflected in FCD. 2) Restrictions on the first character of an identifier are not observed as recommended in TR 10176:2003. The inclusion of digits (outside of those in the basic character set) under identifer-nondigit is implied by FCD. 3) It is implied that only the "main listing" from Annex A is included for C++. That is, the list ends with the Special Characters section. This is not made explicit in FCD. Existing practice in C++03 as well as WG 14 (C, as of N1425) and WG 4 (COBOL, as of N4315) is to include a list in a normative Annex. 4) Specify width sensitivity as implied by C++03: \uFF21 is not the same as A Case sensitivity is already stated in [lex.name]. |
Please clarify. | CWG | 1105 |
ACCEPTED
See paper N3146 |
GB 17 | 2.14.2 ¶ Table 5 | [lex.icon] 2.14.2/2 Table 5 - 'Types of integer constants' In the penultimate row for this table (for suffix `ll or LL') it gives the `Octal or hexadecimal constant' in the third column as one of: long long int unsigned long int Unless I am misunderstanding something fundamental, this second should be: unsigned long long int | Replace the entry for "ll or LL" and "Octal or hexadecimal constant" in table 5 with "long long int unsigned long long int" | editor | ACCEPTED | |
JP 16 | 2.14.3 ¶ 2 Note | Typo, "wide-charater" should be "wide-character". |
Correct typo. [ Note: the type wchar_t is able to represent all members of the execution wide-character set (see 3.9.1). |
editor | ACCEPTED | |
RU 2 | 2.14.3 ¶ p.23, par.3, line 1 | Reference missed | Insert reference "(3.9.1)" after "extended integer type" | editor | ACCEPTED | |
DE 2 | 2.14.4 | C++ does not support hexadecimal floating-point literals, although they are useful to specify exact floating-point constants. | Consider supporting the C99 syntax for hexadecimal floating-point literals. | CWG |
REJECTED
There was no consensus to adopt this feature at this point in the standardization process. |
|
US 16 | 2.14.5 [lex.string] | Raw string literals have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N2146 from the working paper prior the FDIS. | CWG |
ACCEPTED
The feature has been implemented. |
|
DE 3 | 2.14.7 | It is not sufficiently clear that std::nullptr_t is a distinct type and neither a pointer type nor a pointer-to-member type. | Add a note in 2.14.7 stating that, preferably with cross-references to the normative statements in 3.9. | CWG | 1106 | ACCEPTED |
RU 5 | 2.14.7 ¶ p. 28 | Page layout bug | Move footnote 24 from page 28 to page 27 | editor | ACCEPTED | |
US 17 | 2.14.8 ¶ 6 |
In general, the parameter type of a literal operator must be
the same as the argument passed to it. That is not the
case for a user-defined-character-literal, where the
argument could inadvertently match a literal operator
intended for use with user-defined-integer-literals:
typedef unsigned long long ULL; int operator "" X(ULL); int i = 'c'X; // operator"" X(ULL('c')) |
Add the following phrase to the description in
paragraph 6: S shall contain a literal operator whose parameter type is the same as the type of ch. |
CWG | 1107 | ACCEPTED |
JP 17 | 2.14.8 ¶ 3 |
Typo, missing ",". If S contains a raw literal operator the literal L is treated as |
Correct typo. If S contains a raw literal operator, the literal L is treated as |
editor | ACCEPTED | |
JP 18 | 2.14.8 ¶ 4 |
Typo, missing ",". If S contains a raw literal operator the literal L is treated as |
Correct typo. If S contains a raw literal operator, the literal L is treated as |
editor | ACCEPTED | |
US 18 | 2.24.8 [lex.ext] | User-defined literals have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N2750 from the working paper prior the FDIS. | CWG | 1108 | (Reference should be to 2.14.8, not 2.24.8.) |
US 19 | 3 ¶ 4 | It is not always clear when the term "use" is intended as a reference to the definition in 3.2 and when it has its normal English meaning. For example, 3 paragraph 4 reads, "A name is a use of an identifier..." | Replace all occurrences of the word "use" that are not intended as references to 3.2 with some other term, such as "occurrence" or "appearance" or "reference to". | CWG | 1109 |
ACCEPTED
See paper N3214 |
US 20 | 3.1 ¶ para 1 bullet 4 | Grammatical number mismatch in "an assignment expressions". | editor | ACCEPTED | ||
US 21 | 3.1 ¶ 2 | using N::d; does not declare N::d. | using N::d; // declares d | editor | ACCEPTED | |
US 22 | 3.2 ¶ 4 | The type of the expression of a decltype-specifier is apparently required to be complete. | Make an exception so that a template specialization type is not instantiated merely because it's the type of the expression in decltype( expression ) | CWG | 1110 |
REJECTED
The premise is incorrect: it is the function call, not decltype, that requires a complete type. As described in core language issue 1110, failing to instantiate the return type of a function could prevent plausible uses of SFINAE. |
JP 19 | 3.2 ¶ 4 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(10)" to "(Clause 10)". | editor | ACCEPTED | |
JP 20 | 3.3.2 ¶ 7 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(9)" to "(Clause 9)". | editor | ACCEPTED | |
US 23 | 3.4.5 ¶ para 1 | Global class templates should not hide member templates. | Strike the end of para 1 starting with "If the lookup in the class of the object expression finds a template,". See Appendix 1 - Additional Details | CWG | 1111 | ACCEPTED |
US 24 | 3.5 ¶ 3 | One of the critieria for giving a name internal linkage is "a variable that is explicitly declared const and neither explicitly declared extern nor previously declared to have external linkage." This should presumably apply to variables declared constexpr as well. | Add parallel wording for the constexpr specifier. | CWG | 1112 | ACCEPTED |
DE 4 | 3.5 |
It is odd that "N" has no linkage and "g" has external
linkage in this example:
namespace { namespace N // has no linkage { void g(); // has external linkage } } |
CWG | 1113 | ACCEPTED | |
DE 5 | 3.7.3 | The term "local" was changed globally to "block-scope", but this section still contains the term "local" (see also core issue 642). | Change "local" to "block-scope" in the first paragraph. | editor | ACCEPTED | |
RU 3 | 3.7.4.3 ¶ p.65, line 7 | Reference missed | Insert reference "(5.7)" after "well-define pointer arithmetic" | editor | ACCEPTED | |
RU 4 | 3.7.4.3 ¶ p. 65, line 8 | Reference missed | Insert references "(4.10, 5.4)" after "well-define pointer conversion" | editor | ACCEPTED | |
GB 18 | 3.8 ¶ 9 | It isn't clear that the comment in the example actually reflects the result of the placement new. If the intended placement operator new is supposed to be the one given by the standard library ,by including , the example is ill-formed as the placement-new expression &b is const B* which doesn't implicitly convert to void*. |
Replace: new (&b) const B; With: new (const_cast<B*>(&b)) const B; |
CWG | 1114 | ACCEPTED |
US 25 | 3.11 | C/C++ compatibility problems defined in WG21/N3093. | Make the changes proposed in WG21/N3093 | CWG | 1115 | ACCEPTED |
US 26 | 3.7.4, 5.3.5, 12.5, 17.6.3.6, 18.6 | Programmers may define a static member function operator delete that takes a size parameter indicating the size of the object to be deleted. The equivalent global operator delete is not available. This omission has unfortunate performance consequences. | Permit implementations and programmers to define sized versions of the global operator delete for use in preference to the unsized version. See Appendix 1 - Additional Details | CWG |
REJECTED
There was no consensus for making the suggested change at this point in the standardization process. |
|
US 27 | 3.8 ¶ 4 |
Related to core issue 1027, consider:
int f() { union U { double d; } u1, u2; (int&)u1.d = 1; u2 = u1; return (int&)u2.d; }Does this involve undefined behavior? 3.8/4 seems to say that it's OK to clobber u1 with an int object. Then union assignment copies the object representation, possibly creating an int object in u2 and making the return statement well-defined. If this is well-defined, compilers are significantly limited in the assumptions they can make about type aliasing. On the other hand, the variant where U has an array of unsigned char member must be well-defined in order to support std::aligned_storage. |
Clarify that this testcase is undefined, but that adding an array of unsigned char to union U would make it well-defined--if a storage location is allocated with a particular type, it should be undefined to create an object in that storage if it would be undefined to access the stored value of the object through the allocated type. | CWG | 1116 | ACCEPTED |
US 28 | 4.4 ¶ para 3 | A const member function pointer could safely be applied to a non-const object without violating const correctness. | Add an implicit conversion. See Appendix 1 - Additional Details | CWG |
REJECTED
There was no consensus for adding this feature at this point in the standardization process. |
|
FI 7 | 4.11 [conv.mem], 5.2.9 [expr.static.cast] | The CD1 comment CH1 should be reconsidered. The request for being able to cast a pointer to member to a pointer to a base class (or any other implicitly convertible type) of the member is a bugfix rather than an extension. It's a safe conversion, thus it should be allowed. There are valid use cases for such conversions that are currently forbidden. | The standard should allow implicit conversions from “pointer to member of T of type cv D” to 'pointer to member of T of type cv B', where D is of class type and B is a public base of D, It should allow explicit conversion the other way around. | CWG |
REJECTED
There was no consensus for making this change at this point in the standardization process. |
|
CH 3 | 4.11 and 5.2.9 | With respect to the target type, pointer to members should behave like normal pointers. The current situation creates an inconsistency in the C++ type system and is therefore a defect in the Standard. | The standard should allow implicit conversions from ``pointer to member of T of type cv D'' to ``pointer to member of T of type cv B'', where D is of class type and B is a public base of D. It should allow explicit conversion in the other direction. | CWG |
REJECTED
There was no consensus for making this change at this point in the standardization process. |
|
JP 21 | 4.13 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(5)" to "(Clause 5)". | editor | ACCEPTED | |
JP 1 | 5 ¶ Paragraph 6 | The first half of the Note(before "In general") indicates that the expression "E1.E2" produces xvalue if E1 is xvalue regardless of E2's type. It will be true even if E2 is of reference type. On the other hand, according to 5.2.5 paragraph 4, if E2 is of reference type, the result of "E1.E2" is lvalue regardless of E1's type. These two descriptions contradict each other. As 5.2.5 paragraph 4 seems correct, 5 paragraph 6 should be corrected. | Modify 5 paragraph 6 so that the result of E1.E2 is lvalue instead of xvalue when E2 is of reference type. | CWG | 1117 | ACCEPTED |
FI 8 | 5.1.2 [expr.prim.lambda] | As requested in JP 9 on CD, capturing by moving should be allowed for lambdas. Roshan Naik presents a very compelling use case in the Core Reflector message c++std-core-16341. | Allow specifying capture by move. | CWG |
REJECTED
There was no consensus for making the suggested change at this point in the standardization process. |
|
CH 4 | 5.1.2 ¶ p1 | Document N3067 changed the position of attribute specifiers in various places. However, it left out lambda expressions as an oversight, so that the position of attribute-specifier opt in a lambda-declarator is inconsistent with a function declarator |
change the rule for lambda-declarator to lambda-declarator: ( parameter-declaration-clause ) mutableopt exception-specificationopt attribute-specifieropt trailing-return-typeopt |
CWG | 1062 | ACCEPTED |
CH 5 | 5.1.2 ¶ p4 first bullet | typo | Change second 'if' to 'is'. | editor | ACCEPTED | |
US 29 | 5.1.2 ¶ 5 | default arguments should be allowed in lambdas (core issue 974) | See Appendix 1 - Additional Details | CWG | 974 |
REJECTED
There was no consensus for making the suggested change at this point in the standardization process. However, core language issue 974 remains open for consideration in a future revision. |
US 30 | 5.1.2 ¶ 4 | lambda return type deduction should allow arbitrary function structure (core issue 975) | See Appendix 1 - Additional Details | CWG | 975 |
REJECTED
There was no consensus for making the suggested change at this point in the standardization process. However, core language issue 975 remains open for consideration in a future revision. |
JP 22 | 5.1.2 ¶ 7 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(5)" to "(Clause 5)". | editor | ACCEPTED | |
CH 6 | 5.1.2 ¶ p8 and p10 | The current capturing rules seem too restrictive. | Consider to make those rules less restrictive. | CWG |
REJECTED
The comment made no specific suggestions for change. |
|
GB 19 | 5.1.2 ¶ 16 | [expr.prim.lambda] 5.1.2/16 has text which begins "If a lambda-expression m1 captures an entity and that entity is captured by an immediately enclosing lambda expression m2..." - that is, it describes a situation with m2 enclosing m1, and then describes the capture transformation in these terms. The example given to support this, however, turns this all around and shows m1 enclosing m2. This doesn't make either the text or the example incorrect in any sense, but I would suggest that it adds a level of confusion that is easily avoided. | All references to m1 from the beginning of 5.1.2/16 up to the last occurrence before '[Example ' to be replaced by m2, and vice versa. Rationale for suggested wording: all other examples that use the 'mN' notation for lambda expressions and which involve nesting apply increasing N (by 1, from 1) to indicate increasing nesting depth. | editor | ACCEPTED | |
GB 20 | 5.1.2 ¶ 12 | [expr.prim.lambda] 5.1.2/12. In the example code given the local struct s1 has a member function with signature int s1::work(int n) whose definition does not include an appropriate return statement; neither does it include the conventional "// ..." to indicate that the example is intended to be incomplete. | Suggested change: change the signature of this member function to void s1::work(int n), as the return of int does not contribute to the example. | editor | ACCEPTED | |
GB 21 | 5.1.2 | A lambda-capture can be &, which indicates it captures everything by reference (unless otherwise specified), or & /identifier/, which indicates it captures the /identifier/ by reference. It can also be =, to capture everything by value, or /identifier/, for a single thing. Why is = /identifier/ not allowed, for consistency? | Add "= identifier" to the grammar in 5.1.2p1. (The wording already covers the semantics of this, since it refers to captures that "are preceded by &" or "do not contain &") | CWG |
REJECTED
There was no consensus for making the suggested change. |
|
FI 19 | 5.1.2 [expr.prim.lambda] ¶ 21 | “When the lambda-expression is evaluated, the entities that are captured by copy are used to direct-initialize each corresponding non-static data member of the resulting closure object.” This apparently means that if the capture-default is to copy, entities captured by default, implicitly, are copied even in cases where the copy constructors of such entities are explicit. | Don't implicitly copy entities that have explicit copy constructors declared. Require that such entities be captured explicitly, by enumerating them in the capture list. This seems related to Core Issue 1020, so I'd like that issue to be resolved as well. See Appendix 1 - Additional Details | CWG | 1118 |
REJECTED
There was no consensus for the suggested change. |
GB 23 | 5.2.2 ¶ 4 | Order of initialization of arguments in a function is fundamental to the memory model of C++, and the obvious place to look for the definition is in the clause defining function call operators - which currently says nothing. The rules covering this are buried in paragraph 15 of [1.9]. A cross-reference to these words would be most helpful. In particular, it should be made clear that such initialization is indeterminately sequenced (and not unsequenced.) | Add a non-normative note with cross-reference after the first sentance of paragraph 4: "[Note - such initializations are indeterminately sequenced with respect to each other [1.9] - end note]" | editor | ACCEPTED | |
US 31 | 5.2.9;7.2 ¶ 10 | it is unclear from the text in 7.2 and 5.2.9 that the "values of the enumeration" term does not exclude a prvalue of an enumeration type from having other values representable in its underlying type (c++std-core-15652). |
clarify this. "The value is unchanged if it is in the
range of enumeration values of the enumeration
type; otherwise the resulting |
CWG | 1022 | ACCEPTED |
US 32 | 5.2.5 ¶ 5 |
The description of ambiguity ("...if the class of which E2 is
directly a member is an ambiguous base (10.2) of the
naming class (11.2) of E2") does not cover the following
case:
struct A { int i; }; struct B: A { }; struct C: A, B { }; void f(C* p) { p->i; // Should be ambiguous } |
Change the wording to apply also to the case when the naming class is an ambiguous base of the class of the object expression. | CWG | 1119 | ACCEPTED |
JP 64 | 5.2.8 ¶ 5 |
In some code examples, ellipsis(...) is used in ill-formed.
In these cases, "..." represents omission of some codes
like this: class A { /* ... */ } ; But in some cases, it is used without commented-out as below: class A { ... } ; It is an inconsistent usage. They all should be enclosed in a comment. |
Change to: class D { /* ... */ }; |
editor | ACCEPTED | |
GB 22 | 5.2.10 | It is not legal to use reinterpret_cast<> with pointers to void. |
Here's an additional paragraph to add to 5.2.10
that would fix this: * A pointer to an object type can be explicitly converted to a pointer to void, and vice versa.[1] The result of such a pointer conversion will have the same result as the standard pointer conversion described in 4.10. A value of type “pointer to object” converted to “pointer to void” and back, possibly with different cv-qualification, shall have its original value. [1] The types may have different cv-qualifiers, subject to the overall restriction that a reinterpret_cast cannot cast away constness. |
CWG | 1120 | ACCEPTED |
US 33 | 5.3.1 ¶ 3 | The resolution of issue 983 added an error for finding the named member in an ambiguous base. This is an unnecessary special case, since the value of the expression is pointer to member of base. If this value is then converted to pointer to member of derived, an error will be given at that point. | Revert the change for issue 983 (and in the issues list, add a link to issue 203). | CWG | 1121 | ACCEPTED |
GB 24 | 5.3.3 ¶ 6 | The return type of the sizeof operator is defined as being of type std::size_t, defined in library clause 18.2. This, in turn, says that size_t is defined in the C standard, which in turn says that size_t is defined as the type of the result of the sizeof operator! The C definition of sizeof returns an implementation-defined unsigned integer type, recommended not to have "an integer conversion rank greater than signed long int, unless the implementation supports objects large enough to make this necessary." | The result type of the sizeof operator should explicitly be implementation defined in clause 5.3.3. | CWG | 1122 | ACCEPTED |
US 34 | 5.3.4, 5.3.5 | Allocations functions are missing happens-before requirements and guarantees. | Add requirements. See Appendix 1 - Additional Details | |||
US 35 | 5.3.7 ¶ [expr.unary.noexcept], 15.4 [except.spec] | noexcept has no implementation experience. | Either demonstrate a complete implementation of this feature or remove N3050 from the working paper prior the FDIS. | CWG |
ACCEPTED
The feature has been implemented. |
|
FI 17 | 5.3.7 [expr.unary.noexcept] | Destructors should by default be noexcept. Such a rule should, I think, be obeyed even for cases where a destructor is defaulted. Then a throwing destructor would need to be declared noexcept(false), and I think the resulting code breakage is acceptable. | Clarify the implicit generation rules and defaulting rules so that destructors are noexcept unless explicitly declared noexcept(false). | CWG | 1123 |
ACCEPTED with MODIFICATIONS
The rule that was adopted makes destructors noexcept if all the base and member destructors are. See paper N3204 |
JP 2 | 5.5 ¶ 6 | Should be corrected because it contradicts with rules in 5.2.5 paragraph 4. | Add the condition that a type of e2 is not a reference type | CWG | 1124 |
REJECTED
There are no pointers to members of reference type (8.3.3p3). |
US 36 | 5.19 [expr.const] | Generalized constant expressions have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N2235 from the working paper prior the FDIS. | CWG |
REJECTED
An implementation is in progress and is expected to be complete before the publication of the FDIS. Also, this feature is needed in the Standard library and thus should not be removed. |
|
DE 7 | 5.19 ¶ 4, note | The note in paragraph 4 alludes to the possibility that compile-time and run-time evaluations of floating-point expressions might yield different results. There is no clear normative statement (other than the absence of a restriction) that gives such permission. | Move the second sentence of the note into normative text. | CWG |
REJECTED
The possibility of differing results of calculations is implicit in the absence of normative statements constraining their accuracy, so no normative change is needed; the existing note is sufficient to point out this implication. |
|
DE 8 | 5.19 ¶ 6 |
In the definition of "potential constant expression" in
paragraph 6, it is unclear how "arbitrary" the substitution
of the function parameters is. Does it mean "there exists a
value for which the result is a constant expression" or
does it mean "for all possible values, the result needs to
be a constant expression"? Example:
constexpr int f(int x){return x + 1; }is a constant expression under the first interpretation, but not under the second (because overflow occurs for x == INT_MAX, cf. 5.19p2 bullet 5). The answer also affects expressions such as: constexpr int f2(bool v) { return v ? throw 0 : 0; } constexpr int f3(bool v) { return v && (throw 0, 0); } |
CWG | 1125 |
ACCEPTED
See paper N3218 |
|
GB 25 | 5.19 |
In trying to pin down the behaviour of constexpr functions,
it became apparent that there is disagreement over
whether or not the following example is well-formed.
constexpr int f() { return 42 + 84; } const int sz = f(); int a[sz];This should have the same effect as const int sz = 42 + 84; int a[sz];otherwise constexpr functions are broken. |
Update the wording in 5.19 to make it clear that both the examples are valid. | CWG | 1126 | ACCEPTED |
GB 26 | 5.19 |
It is not clear how overload resolution applies within a
constexpr function. In particular, if an expression in the
function body yields an integral value of 0 for some
parameter values, and not for others, is it usable as a null
pointer constant when evaluated as a constant
expression.
typedef char (&One)[1]; typedef char (&Two)[2]; One f(void*); // #1 Two f(...); // #2 constexpr int test(int n) { return sizeof f(n); } constexpr int test2(int n) { return sizeof f(n*0); } int q = 0; #include int main() { char a[test(0)]; std::cout << sizeof(a) << std::endl; // #3 std::cout << test(q) << std::endl; // #4 char b[test2(0)]; std::cout << sizeof(b) << std::endl; // #5 std::cout << test2(q) << std::endl; // #6 }#3 and #4 should print 2, since n is not an integral constant expression with value 0 in the body of test() --- though it is a constant expression when test() is evaluated as a constant expression, it's value is dependent on the invocation. Permitting different results of overload resolution within the same function body in different calling contexts would violate ODR. On the other hand, in test2(), the answer is no longer dependent on the value of n, since "n*0" always evaluates to 0. However, it is not clear from the FCD whether "n*0" is thus a constant expression (and therefore a valid null pointer constant) inside the body of test2. Either way both #5 and #6 should print the same value; it would violate ODR for #5 to print "1" (indicating that "n*0" was a valid null pointer constant when test2() is evaluated in a constant expression context) whilst #6 prints "2" (since n*0 is not a constant expression if n is not constant). #5 and #6 should thus both print "1", or both print "2". |
Updated 5.19 to make it clear that overload resolution in a constexpr function is not dependent on the context of use, or the value of the arguments. | CWG | 1127 | ACCEPTED |
US 37 | 6.5 |
"for (auto e : range)" creates copies of elements. This
seems like a gotcha for new users. Not only are copies
inefficient for reading, but writing to copies won't modify
the original elements. Permitting "for ( identifier : expression )" and giving it the same meaning as "for ( auto& identifier : expression )" would make the range-based for statement easier to teach and to use, and should be trivial to specify and to implement. |
Permit "for ( identifier : expression )" or similar, with the same meaning as "for ( auto& identifier : expression )". | CWG |
REJECTED
There was no consensus for making the suggested change at this point in the standardization process. |
|
CA 3 | Various ¶ various | Canada agrees with US 37, 44, 47, 85, 77, 92, 97, 102, 105, 109 | Resolve as suggested in these comments | CWG | ||
US 38 | 6.5 5 | The statement that certain infinite loops may be assumed to terminate should also apply to go-to loops and possibly infinite recursion. We expect that compiler analyses that would take advantage of this can often no longer identify the origin of such a loop. |
As a strawman, replace the paragraph with "The implementation may assume that any program will eventually do one of the following: - terminate, - make a call to a library I/O function, - access or modify a volatile object, or - perform a synchronization operation (1.10) or atomic operation (Clause 29)." Possibly move this and the attached note to section 1.9, after p8. |
CWG |
ACCEPTED
See paper N3196 |
|
JP 69 | 6.35.1 ¶ 2 | Constant width font should be used for 3 "while"s in the paragraph as described in Syntax notation (1.6). | Change the font for "while" to constant width type. When the condition of a while statement is a declaration, the scope of the variable that is declared extends from its point of declaration (3.3.2) to the end of the while statement. A while statement of the form | editor | ACCEPTED | |
GB 27 | 6.5.4p1 |
6.5.4/1 requires that range-based for loops behave as if
they had "{ auto&& __range = (expression); for (auto
__begin = begin_expr, __end = end_expr; ..." which
implies that __begin and __end must have the same type.
However, this prevents stateful iterators with an end
sentinel of a different type. Since range-based for loops'
equivalent code already introduces a block (for the
__range variable), could __begin and __end be placed
there, as "auto __begin = begin_expr; auto __end =
end_expr;"? Example of what this change would allow, only the relevant details shown with ctors, op*, op++, etc. omitted: (apologies if the formatting is lost) struct End {}; struct Counter { Counter& begin() { return *this; } // used by begin_expr End end() { return End(); } // used by end_expr bool operator!=(End) const { return _current != _end; } Counter(int begin, int end) : _current(begin), _end(end) {} int _current, _end; }; void use_example() { for (auto n : Counter(0, 10)) { // n takes values from 0..9 } } |
Change the "as if" for a range-based for-loop in
6.5.4p1 to move the initialization of __begin and
__end outside the loop into the enclosing block:
{ auto&& __range = (expression); auto __begin = begin_expr; auto __end = end_expr; for (; ... |
CWG |
REJECTED
There was no consensus for making the suggested change. Use of iterators of different types is incompatible with the Standard library containers and with the earlier concepts-based specification. |
|
CH 7 | 6.5.4 ¶ p1 | The phrasing "is equivalent to" is too restrictive and might constrain future improvements. | Make clear that the specification is not necessarily the implementation, i.e. that the expressions in the specification are not necessarily called at all and that the order in which the statement is executed for different values of for-range-declaration is not necessarily the same as if the for loop would have been written the way in the specification. | CWG |
REJECTED
There was no consensus for making the suggested change. The Standard needs to specify the meaning of the statement; removing the “equivalent to” phrasing would leave the feature underspecified. Implementations have a good deal of latitude under the “as-if” rule. |
|
GB 28 | 7 ¶ 1 | "Attributes" is misspelled | Replace "Atrributes" with "Attributes" | editor | ACCEPTED | |
US 39 | 7.1 ¶ 1 | The current wording is, "The optional attribute-specifier in a decl-specifier-seq appertains to the type determined by the decl-specifier-seq." However, the rule for decl-specifier-seq in the grammar is recursive, and the intent is for the attribute-specifier to appertain to the top decl-specifier-seq, not the one in which the attribute-specifier directly appears. | Change the wording to indicate that the complete or outermost decl-specifier-seq is intended. | CWG | 1128 | ACCEPTED |
GB 29 | 7.1.5 | A constexpr function is not permitted to return via an exception. This should be recognised, and a function declared 'constexpr' without an explicit exception specification should be treated as if declared 'noexcept(true)' rather than the usual 'noexcept(false)'. For a function template declared constexpr without an explicit exception specification, it should be considered 'noexcept(true)' if and only if the constexpr keyword is respected on a given instantiation. | Give constexpr functions an implicit non-throwing exception specification. | CWG | 1129 |
ACCEPTED with MODIFICATIONS
The premise is not correct: an exception is forbidden only when a constexpr function is invoked in a context that requires a constant expression. Used as an ordinary function, it can throw. Instead of changing the default exception specification, the result of the noexcept operator was changed, based on whether the invocation of the function is a constant expression or not. |
US 40 | 7.1.6.2 ¶ 4 |
The description of decltype does not specify whether the
type of a parameter is the declared type or the type as
adjusted in 8.3.5p5:
auto f(int a[])->decltype(a); // ill-formed or int*? auto g(const int i)->decltype(i); // int or const int? |
Clarify the wording to indicate that the type of a parameter is after the array- and function-to-pointer decay but before the removal of cv-qualification. | CWG | 1130 | ACCEPTED |
DE 9 | 7.1.6.2 ¶ p4 | decltype applied to a function call expression requires a complete type (5.2.2 paragraph 3 and 3.2 paragraph 4), even though decltype's result might be used in a way that does not actually require a complete type. This might cause undesired and excessive template instantiations. | When immediately applying decltype, do not require a complete type, for example for the return type of a function call. | CWG | 1110 |
REJECTED
As described in core language issue 1110, failing to instantiate the return type of a function could prevent plausible uses of SFINAE. |
US 41 | 7.1.6.3 ¶ 2 |
The current wording disallows use of typedef-names in
elaborated-type-specifiers. This prohibition should also
apply to template aliases:
struct A { }; template<typename T> using X = A; struct X<int>* p2; // ill-formed |
Add the necessary wording to prohibit a specialization of a template alias in an elaborated-type-specifier. | CWG | 1131 | ACCEPTED |
US 42 | 7.1.6.4 | The overloaded meaning of the auto specifier is confusing and prevents possible future language enhancements. | Choose another keyword to indicate a late-specified return type. The identifiers lateret and postret have no Google code search hits. The identifiers late, latetype, and posttype have 30-40 hits. | CWG |
REJECTED
There was no consensus to make the suggested change. |
|
US 43 | 7.6 ¶ 4 | The contexts in which an attribute-specifier can appear include statements, described in clause 6, but the crossreferences to clauses describing those contexts do not include clause 6. | Add clause 6 to the list of cross-references in the first sentence. | editor | ACCEPTED | |
GB 30 | 7.6.1 ¶ 6 | Making the use of [[ illegal except where introducing an attribute specifier is just reintroducing the problem we had with >> for closing nested templates, albeit in a minor and less common form. As Jason Merrill commented in c++std-core-16046, there is no ambiguity in practice because code couldn't actually be well-formed under interpretation as both an attribute specifier and a lambda introducer. A small amount of lookahead would be required to differentiate the cases, but this should not be a problem. This restriction also means that lambdas in macros must be enclosed in parentheses to avoid accidental interpretation as an illegal attribute specifier if used as an array index. | Delete 7.6.1 paragraph 6. | CWG |
REJECTED
There was no consensus for reconsidering the previous explicit decision of the Committee on this issue. |
|
JP 23 | 7.6.1 ¶ 4 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(clause 7, clause 8)" to "(Clause 7, Clause 8)". | editor | ACCEPTED | |
GB 31 | 7.6.2 | After reviewing the case for attributes, wg14 has opted not to adopt this feature, and is instead using keywords for the few important cases identified in the attributes proposal. For compatibility with C, the change of the 'alignas' keyword to the '[[align]]' attribute should be reversed. | Revert the changes in the initial alignment proposal that changed the 'alignas' keyword into an attribute. | CWG | 1115 |
ACCEPTED
See paper N3190 |
GB 32 | 7.6.3 | C has rejected the notion of attributes, and introduced the noreturn facility as a keyword. To continue writing clean, portable code we should replace the [[noreturn]] attribute with a 'noreturn' keyword, following the usual convention that while C obfuscates new keywords with _Capital and adds a macro to map to the comfortable spelling, C++ simply adopts the all-lowercase spelling. | Replace the [[noreturn]] attribute with a new keyword, 'noreturn', with identical semantics. Note that this implies the keyword will not be something that a function can be overloaded upon. | CWG | 1132 |
REJECTED
There was no consensus to make the suggested change. |
US 44 | 7.6.5 |
Even if attributes continue to be standardized over
continued objections from both of the two vendors who
are cited as the principal prior art, we can live with them
with the exception of the virtual override controls. This
result is just awful, as already shown in the example in
7.6.5 (excerpted):
class D [[base_check]] : public B { void sone_func [[override]] (); virtual void h [[ hiding]] (char*); };Here we have six keywords (not counting void and char) three normal keywords, and three [[decorated]] keywords. There has already been public ridicule of C++0x about this ugliness. This is just a poor language design, even in the face of backward compatibility concerns (e.g., that some existing code may already use those words as identifiers) because those concerns have already been resolved in other ways in existing practice (see below) More importantly, this is exactly the abuse of attributes as disguised keywords that was objected to and was explicitly promised not to happen in order to get this proposal passed. The use of attributes for the virtual control keywords is the most egregious abuse of the attribute syntax, and at least that use of attributes must be fixed by replacing them with non-attribute syntax. These virtual override controls are language features, not annotations. It is possible to have nice names and no conflicts with existing code by using contextual keywords, such as recognizing the word as having the special meaning when it appears in a grammar position where no user identifier can appear, as demonstrated in C++/CLI which has five years of actual field experience with a large number of customers (and exactly no name conflict or programmer confusion problems reported in the field during the five years this has been available): class D : public B { void sone_func() override; // same meaning as [[override]] - explicit override virtual void h (char*) new; // same meaning as [[hiding]] - a new function, not an override }; int override = 42; // ok, override is not a reserved keywordThe above forms are implementable, have been implemented, have years of practical field experience, and work. Developers love them. Whether the answer is to follow this existing practice or something else, there needs to be a more natural replacement for the currently [[attributed]] keywords for virtual override control which is an ugly novelty that has no field experience and that developers have already ridiculed. |
Change the syntax for virtual override control to not use attributes. | CWG | 1133 |
ACCEPTED
See paper N3206 |
US 45 | 7.6.5 ¶ 6 |
The example includes a line reading
class D [[base_check]] : public B {However, the current syntax in 9p1 places the attribute-specifier before the class name. |
Change the example to read
class [[base_check]] D : public B { |
editor | ACCEPTED | |
CH 8 | 8.1 ¶ p1 (syntax) | 'noptr-abstract-declarator:' rule misses 'opt' subscript from the constant expression within the array brackets. This seems to be an editorial oversight |
change: "noptr-abstract-declaratoropt [ constant-expression
] attribute-specifieropt" to "noptrabstract-declaratoropt [ constant-expressionopt ] attribute-specifieropt" |
editor | ||
US 46 | 8.3.2 20.7.6.2 ¶ all Table 49 | There is no way to create a prvalue of array type, so there ought to be no way create a (nonsensical) rvalue reference to array type. |
In [dcl.ref]/2, disallow declarations of T (&&A)[]. In [dec.ref]/6 add a sentence: If a typedef, a type template-parameter, or a decltype-specifier denotes a type A that is an array type (of known or unknown size), an attempt to create the type “rvalue reference to cv A” creates the type A&. In [meta.trans.ref]/Table 49 change the third row as follows: If T names an array type, then the member typedef type shall name T&, otherwise if T names an object or function type... |
CWG |
REJECTED
It is possible to create an array prvalue: an array member of a class prvalue is an array prvalue. |
|
GB 33 | 8.3.5 ¶ 5 | The register keyword is deprecated, so does not make for a good example. Suggest substituting the new storage class specifier, 'thread_local', instead. | Use 'thread_local' in place of 'register' in the following sentance: "[ Example: register char* becomes char* end example ]" | CWG | 1130 |
ACCEPTED with MODIFICATIONS
thread_local cannot be used for a parameter. However, storage class specifiers do not affect the type, so mentioning storage class specifiers was incorrect and has been removed. |
US 47 | 8.4.2 | 8.4.2 [dcl.fct.def.default]/4 says: "A special member function is user-provided if it is user-declared and not explicitly defaulted on its first declaration. A user-provided explicitly-defaulted function is..." The second sentence here should say "A user-declared explicitly-defaulted function is...". |
Change "A user-provided explicitly-defaulted function is..." to "A user-declared explicitly-defaulted function is...". |
CWG | 1134 | ACCEPTED with MODIFICATIONS |
GB 34 | 8.4.2 ¶ p2 | It is confusing when a normative paragraph starts with a note. The note starting this paragraph, with its reference to 'this' relating to the previous paragraph and not the content that follows, should be moved into the first paragraph, or the rest of this paragraph after the note should start a new numbered paragraph. | The note starting this paragraph should be moved into the first paragraph, or the rest of this paragraph after the note should start a new numbered paragraph. | editor | ACCEPTED | |
FI 1 | 8.4.2 [dcl.fct.def.default] ¶ Paragraph 2 | It should be allowed to explicitly default a non-public special member function on its first declaration. It is very likely that users will want to default protected/private constructors and copy constructors without having to write such defaulting outside the class. | Strike the “it shall be public” bullet. | CWG | 1135 | ACCEPTED |
FI 2 | 8.4.2 [dcl.fct.def.default] ¶ Paragraph 2 | It should be allowed to explicitly default an explicit special member function on its first declaration. It is very likely that users will want to default explicit copy constructors without having to write such defaulting outside of the class. | Strike the “it shall not be explicit” bullet. See Appendix 1 - Additional Details | CWG | 1136 | ACCEPTED |
FI 3 | 8.4.2 [dcl.fct.def.default] ¶ Paragraph 2 | It should be allowed to explicitly default a virtual special member function on its first declaration. It is very likely that users will want to default virtual copy assignment operators and destructors without having to write such defaulting outside of the class. | Strike the “it shall not be virtual” bullet. See Appendix 1 - Additional Details | CWG | 1137 | ACCEPTED |
GB 35 | 8.5.1 ¶ 7 | With the removal of the deprecated string-literal-to-nonconst-char* conversion, member 'b' of struct S should be declared as a 'const' char *. | Fix struct S as: "struct S { int a; const char* b; int c; };" | editor | ACCEPTED | |
JP 71 | 8.5.1 ¶ 7 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
struct S { int a; const char* b; int c; }; S ss = { 1, "asdf" }; |
editor | ACCEPTED | |
JP 72 | 8.5.1 ¶ 15 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
union u { int a; const char* b; }; u a = { 1 }; u b = a; u c = 1; // error u d = { 0, "asdf" }; // error u e = { "asdf" }; // error |
editor | ACCEPTED | |
GB 36 | 8.5.1 ¶ 17 | The 'b' member of union u should be declared const char * to better illustrate the expected cause of failures. | Update union u as: "union u { int a; const char* b; };" | editor | ACCEPTED | |
US 48 | 8.5.3 ¶ 5 |
The rule "...or the reference shall be an rvalue reference
and the initializer expression shall be an rvalue or have a
function type" is stated in terms of the rvalue-ness of the
expression rather than the eventual target of the
reference; this leads to some undesirable results, such as
struct A { }; struct B { operator A&(); }; A&& aref = B(); // binds to lvalue(c++std-core-16305) |
Correct the formulation to deal with the rvalueness of the initializer after conversion to the appropriate type. | CWG | 1138 | ACCEPTED |
US 49 | 8.5.3 ¶ 5 |
The FCD does not specify direct binding for this example:
int i; int main() { int&& ir = static_cast<int&&>(i); ir = 42; return (i != 42); }(c++std-core-16181) |
See Appendix 1 - Additional Details | CWG | 1139 | ACCEPTED |
GB 37 | 8.5.3 |
It seems that lvalues of any sort don't bind to non-const
rvalue ref args, even if an intermediate temporary would
be created.
See the discussion at
http://stackoverflow.com/questions/2748866/c0x-rvalue-references-and-temporaries. I'll summarise that here: Assume that std::vector has push_back overloads declared as follows, with SFINAE omitted for clarity: void push_back(const T &); //Copies the const T & into the vector's storage void push_back(T &&); //Moves the T && into the vector's storageThen this code appears to behave as commented, as of N3090: const char * cchar = "Hello, world"; std::vector<std::string> v; v.push_back(cchar); //makes a temporary string, copies the string into vector storage using push_back(const T&) v.push_back(std::string(cchar)); //makes a temporary string, moves the string into vector storage using push_back(T&&) v.push_back(std::move(cchar)); //makes a temporary string, moves the string into the vector using push_back(T&&)Johannes Schaub (litb) convincingly argued that the reason for this is clause 8.5.3/5 describing reference binding - it allows direct binding of lvalues, bindings that require conversion sequences to const lvalue refs, and rvalues to rvalue refs. But it doesn't allow for lvalues to ever bind to rvalue refs, even if an intermediate temporary would otherwise need to be created. This isn't what I (as a user of std::vector) expect to happen. I expect all of these push_back calls to do the same thing, namely, select the push_back(T&&) overload, create a temporary string object from 'cchar', bind the temporary string to the argument, and hence move (not copy) the temporary string into vector's storage. It seems particularly strange that v.push_back(cchar) "requires" an extra copy, but v.push_back(std::move(cchar)) does not. It almost seems like indicating that 'cchar' is potentially-movable (by casting it to an rvalue ref using std::move) allows moving from a completely different object - the temporary string. I suggest extending the rules for initializing const lvalue refs via implicit conversions (8.5.3/5), to also apply to rvalue refs. This also raises an additional question of whether lvalues of _copyable_ types should be copied into a temporary object so that they may bind to an rvalue ref. Allowing this would not affect const T&/T&& overload pairs. But it could be potentially useful when writing functions that wish to accept a number of rvalue refs to copyable-but-not-movable types (such as all C++03 classes with user-defined copy constructors), or when writing functions that "take apart" a number their arguments in a way that is different from a straightforward move (perhaps some tree operations would want to do this). Conversely, it might seem odd that declarations such as: string && s = string_lvalue; string && s = string_rvalue_ref_variable; //mistake, std::move(string_rvalue_ref_variable) was intended...would both silently copy their arguments and bind to the copy, instead of being invalid as they are now. We believe this is core issue 953 |
Possible wording: amend the second list
item in 8.5.3/5: Otherwise, the reference shall be an lvalue reference to a non-volatile const type (i.e., cv1 shall be const), or the reference shall be an rvalue reference [deleted the rest of the sentence]. [The last example would also need to be deleted.] |
CWG | 1138 | ACCEPTED |
DE 10 | 8.5.3 ¶ te |
Reference binding rules for rvalue references should
consider temporaries generated from lvalues by implicit
conversions. Consider to postpone the lvalue/rvalue
analysis of an expression to after the implicit conversion
chain has been deduced. Example:
void f(std::string&&); void g() { f(std::string("hello")); // #1, ok f("hello"); // #2, error, // but should be the same as #1 } |
CWG | 1138 | ACCEPTED | |
US 50 | 9 ¶ 9 | the class "struct A { const int i; };" was a POD in C++98, but is not a POD under the FCD rules because it does not have a trivial default constructor; I believe that C++0x POD was intended to be a superset of C++98 POD. | change POD to be standard layout and trivially copyable? | CWG | 1140 | ACCEPTED |
FI 16 | 9 9 9 3.9 ¶ 5 trivial 6 std-layout 9 POD 10 literal type | There are definitions for these types in the text, yet it is left unclear what use these classifications have. The types are very close to each other, which makes them confusing. If the reader must rely on external references, then these references should be specified (which is undesirable, or even disallowed by ISO(?)). As it stands, there is an example for using standard-layout classes (with other programming languages). There are also uses specified for literal types. One can imagine many uses for these four/five types, so it is important to have a clear specification of the intent as to where each of these types is expected to be used. | It is necessary to have detailed information on the expected uses of standard-layout, trivial, trivially copyable, literal and POD types. | CWG |
REJECTED
The current wording is clear enough. |
|
JP 81 | 9 ¶ 9 | Missing description of acronym "POD", which existed in C++03: The acronym POD stands for "plain old data." | Add "The acronym POD stands for "plain old data." as an annotation. | editor | ACCEPTED | |
US 51 | 9.2 [class.mem] | Non-static data member initializers have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N2756 from the working paper prior the FDIS. | CWG | 1141 | C++/CLI has a very similar feature that has been implemented. |
US 52 | 9.3 ¶ 7 | The current wording allows friend declarations to name member functions "after their class has been defined." This appears to prohibit a friend declaration in a nested class defined inside its containing class that names a member function of the containing class, because the containing class is still considered to be incomplete at that point. | Change the wording to allow a friend declaration of a "previously-declared member function." | CWG | 1142 | ACCEPTED |
US 53 | 9.3.1 [class.mfct.non-static] | Move semantics for *this have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N1821 from the working paper prior the FDIS. | CWG | 1143 | |
JP 73 | 9.3.1 ¶ 3 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
struct tnode { char tword[20]; int count; tnode *left; tnode *right; void set(const char*, tnode* l, tnode* r); }; void tnode::set(const char* w, tnode* l, tnode* r) { count = strlen(w)+1; if (sizeof(tword)<=count) perror("tnode string too long"); strcpy(tword,w); left = l; right = r; } void f(tnode n1, tnode n2) { n1.set("abc",&n2,0); n2.set("def",0,0); } |
editor | ACCEPTED | |
US 54 | 9.5 [class.union] | Unrestricted unions have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N2544 from the working paper prior the FDIS. | CWG |
ACCEPTED
The feature has been implemented |
|
JP 74 | 9.5 ¶ 6 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
void f() { union { int a; const char* p; }; a = 1; p = "Jennifer"; } |
editor | ACCEPTED | |
GB 38 | 9.6 |
The signedness of bit-fields is the only time when 'signed
int' is any different to just 'int'. In C it is possible to remember whether a typedef uses 'signed' but in C++ it doesn't make sense and will result in ODR violations if A<long> and A<signed long> are not exactly equivalent. This also causes portability problems because it is not specified whether typedefs such as int32_t are defined with 'signed' so using the <cstdint> types in bitfields is problematic. It is common to want to guarantee a bit-field has a minimum number of bits, for which the <cstdint> types are useful, except that the signedness of a bit-field using int32_t might depend on both unspecified and implementation-defined behaviour. |
'signed int' should always be equivalent to 'int' in
all contexts. A possible alternative would be to specify that signed types in <cstdint> are declared with 'signed' so that using them for bit-fields has predictable results, but this doesn't address the ODR issue with A<long> and A<signed long> |
CWG | 675 |
REJECTED
Resolving this question was not deemed essential for this revision of the Standard, but core language issue 675 remains open for possible consideration in a future revision. |
US 55 | 10.3 ¶ Paragraph 5 |
The following code not only does not compile on the
compilers I've tested, but cannot be fixed through any
combinations of forward references
class B { public: virtual B *f() = 0; }; class D1 : public B { public: virtual D2 *f(); }; class D2 : public B { public: virtual D1 *f(); }; |
In the core mailing list, Daniel Krugler points out
that the current wording is ambiguous as to
whether this is legal (although an editorial
example suggests otherwise), and observes that it
should be OK as long as D2 is complete at the
point of definition of D1::f. The standard should
resolve the ambiguity by saying that D2 only
needs to be complete at the point of definition of
D1::f. The core mailing list message text is below: I would be happy, if the standard would just allow this, but IMO the current wording seems to be readable in different ways (e.g. Comeau rejects the code). I think the reason is that [class.virtual]/5 just says: "The return type of an overriding function shall be either identical to the return type of the overridden function or covariant with the classes of the functions.[..]" This restriction is IMO only necessary for the *definition* of D::f. Secondly p. 6 says: "If the return type of D::f differs from the return type of B::f, the class type in the return type of D::f shall be complete at the point of declaration of D::f or shall be the class type D.[..]" and shows the following example that explicitly forbids that (simplified): struct Base { virtual B* vf5(); }; class A; struct Derived : public Base { A* vf5(); // error: returns pointer to incomplete class }; |
CWG |
REJECTED
It is necessary to be able to calculate the offsets applied to covariant return values when only the class definition is available. |
|
US 56 | 11.3 [class.access.decl] | Access declarations were deprecated in the 1998 standard and have no benefits over using declarations. | Remove access declarations from the working paper. | CWG | 1144 | ACCEPTED |
FI 4 | 12.1 [class.ctor] ¶ Paragraph 5 |
What effect does defaulting have on triviality? Related to
FI 1, non-public special members defaulted on their first
declaration should retain triviality, because they shouldn't
be considered user-provided. Related to FI 3, defaulted
member functions that are virtual should not be
considered trivial, but there's no reason why non-virtuals
could not be. Furthermore, a class with a non-public explicitly-defaulted constructor isn't ever trivially constructible under the current rules. If such a class is used as a subobject, the constructor of the aggregating class should be trivial if it can access the non-public explicitly defaulted constructor of a subobject. |
Change the triviality rules so that a class can have
a trivial default constructor if the class has access
to the default constructors of its subobjects and
the default constructors of the subobjects are
explicitly defaulted on first declaration, even if said
defaulted constructors are non-public. See Appendix 1 - Additional Details |
CWG | 1145 | ACCEPTED |
FI 15 | 12.3.1 ¶ 2 |
12.3.1. 2: "A default constructor may be an explicit
constructor; such a constructor will be used to perform
default-initialization or value-initialization (8.5)." 12.3. 1 also says that an explicit ctor is different from a non-explicit ctor in that it is only invoked when direct-initialization (T a(1); T a{1}. presumably also T a;) or casting is used. What are the scenarios for the default ctor where explicit actually matters? Temporaries, arrays, ??? When, if ever, is an explicit default ctor different from a non-explicit ctor? |
The difference between a no argument default constructor and an explicit no argument default constructor should be explained in the standard. If there is no difference, this should be explicitly specified. | CWG |
REJECTED
The current wording is clear enough. |
|
US 57 | 12.3.2 [class.conv.fct] | Explicit conversion operators have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N2437 from the working paper prior the FDIS. | CWG |
ACCEPTED
The feature has been implemented. |
|
GB 39 | 12.4 ¶ 4 | Contradiction between the note and normative language describing when defaulted function definitions might have an exception specification. (See 8.4.2p2 for requirement to provide the exception specification) | Either strike the second sentance of this note, or update it to reflect under which conditions a defaulted definition might have an exception specification. | CWG | 1146 | ACCEPTED |
GB 40 | 12.4 | It is very difficult to write correct programs that do not call 'terminate' in the presence of destructors that can throw exceptions, and this practice has long been discouraged. Many implicitly declared destructors already carry noexcept declarations (mostly types with trivial destructors) and it is anticipated it will become common practice to want a user-declared destructor to be declared noexcept. This becomes important evaluating the noexcept operator, where any of the unevaluated subexpressions may produce a temporary object. As this is expected to be the overwhelmingly common case, a user-declared destructor that does not supply an exception specification should be considered as if declared noexcept(true) rather than noexcept(false), the default for every other function. | a user-declared destructor that does not supply an exception specification should be considered as if declared noexcept(true) rather than noexcept(false), the default for every other function | CWG | 1147 |
ACCEPTED with MODIFICATIONS
The rule that was adopted makes destructors noexcept if all the base and member destructors are. See paper N3204 |
CH 9 | 12.4 and 15.4 | Destructors should generally not throw exceptions. Consider giving an explicit rule for this. | Add in 12.4 or 15.4 a paragraph to the effect that all destructors not having an exception soecification are considered noexcept(true). | CWG | 1147 |
ACCEPTED with MODIFICATIONS
The rule that was adopted makes destructors noexcept if all the base and member destructors are. See paper N3204 |
US 58 | 12.5 ¶ foot 117 | Missing comma in "is not virtual the size might". | Add the comma. | editor |
REJECTED
Because of the comma later in the sentence, a comma here would be wrong. |
|
US 59 | 12.6.2 [class.base.init] | Delegating constructors have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N1986 from the working paper prior the FDIS. | CWG |
ACCEPTED
The feature has been implemented. |
|
US 60 | 12.8 [class.copy] | Implicitly-defined move constructors and move assignment operators have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N3053 from the working paper prior the FDIS. | CWG |
ACCEPTED
The feature has been implemented. |
|
DE 11 | 12.8 | It is unclear whether copy elision can or cannot apply to a case like C f(C c) { return c; }, i.e. where a parameter of class type is returned. Furthermore, if copy elision cannot apply there, it should still be possible to move (instead of copy) the return value. | Amend paragraph 34 to explicitly exclude function parameters from copy elision. Amend paragraph 35 to include function parameters as eligible for move-construction. | CWG | 1148 | ACCEPTED |
FI 5 | 12.8 [class.copy] ¶ Paragraph 13, paragraph 27 |
Same as FI 4, the parts involving copy constructors and
copy assignment operators. A class with a non-public explicitly-defaulted copy constructor isn't ever trivially copyable under the current rules. If such a class is used as a subobject, the copy constructor of the aggregating class should be trivial if it can access the non-public explicitly defaulted copy constructor of a subobject. |
Change the triviality rules so that a class can have a trivial copy constructor if the class has access to the copy constructors of its subobjects and the copy constructors of the subobjects are explicitly defaulted on first declaration, even if said defaulted copy constructors are non-public. See Appendix 1 - Additional Details | CWG | 1149 | ACCEPTED |
GB 41 | 12.8 ¶ 15, 29 | Contradiction between the notes claiming that defaulted definitions to not have exception specifications, and the normative language in 8.4.2 which declares that they might. | Either strike the second sentance of each note, or update it to reflect under which conditions a defaulted definition might have an exception specification. | CWG | 1146 | ACCEPTED |
US 61 | 12.8;20.2.5 ¶ 17,31;table 42 | static_cast is broken across two lines | do not hyphenate static_cast | editor | ACCEPTED | |
US 62 | 12.8 ¶ 16 | The new wording describing generated copy constructors does not describe the initialization of members of reference type. (Core issue 1051 in N3083.) | Add the required description. | CWG | 1051 | ACCEPTED |
US 63 | 12.8 ¶ 16-18 | The new wording specifies the behavior of an implicitlydefined copy constructor for a non-union class (p16), an implicitly-defined move constructor for a non-union class (p17), and an implicitly-defined copy constructor for a union (p18), but not an implicitly-defined move constructor for a union. (Core issue 1064 in N3083.) | Add the required description. | CWG | 1064 | ACCEPTED |
US 64 | 12.8 ¶ 28 | The current wording reads, "A copy/move assignment operator that is defaulted and not defined as deleted is implicitly defined when an object of its class type is assigned a value of its class type or a value of a class type derived from its class type or when it is explicitly defaulted after its first declaration." This sounds as if any assignment to a class object, regardless of whether it is a copy or a move assignment, defines both the copy and move operators. Presumably an assignment should only define the assignment operator chosen by overload resolution for the operation. (Compare the corresponding wording in p14 for the copy/move constructors: "...implicitly defined if it is used to initialize an object of its class type..." (Core issue 1066 in N3083.) | Clarify the wording so that only the operator needed for the operation is implicitly defined. | CWG | 1066 | ACCEPTED |
US 65 | 12.9 [class.inhctor] | Inheriting constructors have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N2540 from the working paper prior the FDIS. | CWG | 1150 | |
JP 65 | 13.1 ¶ 3 |
In some code examples, ellipsis(...) is used in ill-formed.
In these cases, "..." represents omission of some codes
like this: class A { /* ... */ } ; But in some cases, it is used without commented-out as below: class A { ... } ; It is an inconsistent usage. They all should be enclosed in a comment. |
Change to:int f (int) { /* ... */ } // definition of f(int) int f (cInt) { /* ... */ } // error: redefinition of f(int) |
editor | ACCEPTED | |
US 66 | 13.3.1.7 ¶ 1 | overload resolution should first look for a viable list constructor, then look for a non-list constructor if no list constructor is viable | See Appendix 1 - Additional Details | CWG | 1151 | ACCEPTED |
US 67 | 13.3.2 ¶ 3 | To determine whether there is an ICS, 13.3.2 uses 13.3.3.1 instead of just saying “there is an ICS if-and-only-if a copy init would be well-formed.” Apparently this is desired, but to a casual reader or an implementor reading these rules for the first time for a new implementation, it's not clear why that's desired. | Insert a note or annex explaining why 13.3.2 does things as it does. | CWG | 1152 |
ACCEPTED with MODIFICATIONS
The resolution for core language issue 1152 fixes a related problem, but a rationale was not deemed necessary at this time. |
JP 75 | 13.2 ¶ 1 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
struct B { int f(int); }; struct D : B { int f(const char*); }; |
editor | ACCEPTED | |
JP 76 | 13.2 ¶ 2 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
void f(const char*); void g() { extern void f(int); f("asdf"); // error: f(int) hides f(const char*) // so there is no f(const char*) in this scope } |
editor | ACCEPTED | |
JP 77 | 13.3.1.2 ¶ 1 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
struct String { String (const String&); String (const char*); operator char* (); }; String operator + (const String&, const String&); void f(void) { char* p= "one" + "two"; // ill-formed because neither // operand has user-defined type int I = 1 + 1; // Always evaluates to 2 even if // user-defined types exist which // would perform the operation. } |
editor | ACCEPTED | |
US 68 | 13.4 ¶ 1 |
Overload resolution within the operand of a unary &
operator is done by selecting the function "whose type
matches the target type required in the context." The
criterion for determining whether the types match,
however, is not defined. At least three possibilities
suggest themselves: 1. The types are identical. 2. The source type can be implicitly converted to the target type. 3. The expression would be well-formed if the function under consideration were not overloaded. This question arises for pointer-to-member types, where there is an implicit conversion from a pointer-to-base-member to a pointer-to-derived-member, as well as when the context is an explicit type conversion (which allows for static_cast a conversion from pointer-to-derived-member to a pointer-to-base-member and, in the reinterpret_cast interpretation of functional and old-style casts, essentially any conversion). |
Specify the intended criterion for determining whether the types match. | CWG | 1153 | ACCEPTED |
JP 82 | 13.5.8 ¶ 8 |
Typo, "lteral" should be "literal". // error: invalid lteral suffix identifier |
Correct typo. // error: invalid literal suffix identifier |
editor | ACCEPTED | |
US 69 | 14.3.2 ¶ para 1 | The standard permits the address of thread_local variable as a non-type template parameter. The addresses of these variables are not constant, however. | Require static storage duration for non-type parameters. | CWG | 1154 | ACCEPTED |
DE 12 | 14.3.2 | Now that local classes can be used as template arguments, it seems odd that there are "external linkage" restrictions on non-type template parameters. | Permit addresses of objects and functions with internal linkage as arguments for non-type template parameters. | CWG | 1155 | ACCEPTED |
JP 78 | 14.3.2 ¶ 2 |
"char*" should be "const char *".
If not corrected, type mismatch is another cause of error in
the example below, which is not appropriate for an
example here.
template<class T, char* p> class X { X(); X(const char* q) { / ... / } }; X<int, "Studebaker"> x1; // error: string literal as templateargument char p[] = "Vivisectionist"; X<int,p> x2; // OK |
template<class T, const char* p> class X { | editor | ACCEPTED | |
JP 83 | 14.3.2 ¶ 2 |
Constructors in template declaration are not essential for
this example to explain string literal error use.
template<class T, char* p> class X { X(); X(const char* q) { /* ... */ } }; X<int, "Studebaker"> x1; // error: string literal as templateargument char p[] = "Vivisectionist"; X<int,p> x2; // OK |
Delete two constructors in template declaration as
follows.
template<class T, const char* p> class X { /* ... */ }; X<int, "Studebaker"> x1; // error: string literal as template-argument char p[] = "Vivisectionist"; X<int,p> x2; // OK |
editor | ACCEPTED | |
GB 42 | 14.5.3 ¶ 1 | The name "eror" should probably be "error". |
Replace: Tuple<0> eror; With: Tuple<0> error; |
editor | ACCEPTED | |
JP 24 | 14.5.3 ¶ 4 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(10)" to "(Clause 10)". | editor | ACCEPTED | |
US 70 | 14.5.6.2 ¶ 2, 4 | 14.8.2.4p3 specifies that the deduction used in partial ordering in a non-call context is based on the complete function type of the function templates. The wording in 14.5.6.2p2 (and echoed in p4) reflects an earlier specification, however, saying that the deduction uses only "the function parameter types, or in the case of a conversion function the return type." This is a contradiction. | Update the wording in 14.5.6.2 to say only that deduction is performed as described in 14.8.2.4 and not to specify which types are used. | CWG | 1156 | ACCEPTED |
US 71 | unused ¶ unused | ACCEPTED | ||||
CA 7 | 14.5.6.2p3 ¶ P3 |
r country In FCD sub-clause 14.5.6.2 [temp.func.order]
paragraph 3, we are told to synthesize, "for each type,
non-type, or template template parameter... a unique type,
value, or class template respectively."
These are then substituted for each occurrence of the
respective parameter in the function type of the function
template.
It is not specified what the properties of said synthetics
are, for example, members of a dependent type referred
to in non-deduced contexts are not specified to exist,
although the transformed function type would be invalid if
they do not exist.
We may assume, for example, that each synthetic will be
given minimal properties such that the transformed
function type is valid at the point of definition of the
template. Example 1: template <typename T, typename U> struct A; template <typename T> void foo(A<T, typename T::u> *) { } // #1 // synthetic T1 has member T1::u template <typename T> void foo(A<T, typename T::u::v> *) { } // #2 // synthetic T2 has member T2::u and member T2::u::v // T in #1 deduces to synthetic T2 in partial ordering; // deduced A for the parameter is A<T2, T2::u> *--this is not necessarily compatible // with A<T2, T2::u::v> * and it does not need to be. See Note 1. The effect is that // (in the call below) the compatibility of B::u and B::u::v is respected. // T in #2 cannot be successfully deduced in partial ordering from A<T1, T1::u> *; // invalid type T1::u::v will be formed when T1 is substituted into non-deduced contexts. struct B { struct u { typedef u v; }; }; int main() { foo((A<B, B::u> *)0); // calls #2 } *Note 1: Template argument deduction is an attempt to match a P and to a deduced A; however, template argument deduction is not specified to fail if the P and the deduced A are incompatible. This may occur in the presence of non-deduced contexts. Notwithstanding the parenthetical statement in [temp.deduct.partial] paragraph 9, template argument deduction may succeed in determining a template argument for every template parameter while producing a deduced A that is not compatible with the corresponding P. Example 2: template <typename T, typename U, typename V> struct A; template <typename T> void foo(A<T, struct T::u, struct T::u::u> *); #2.1 // synthetic T1 has member non-union class T1::u template <typename T, typename U> void foo(A<T, U , U> *); #2.2 // synthetic T2 and U2 has no required properties // T in #2.1 cannot be deduced in partial ordering from A<T2, U2, U2> *;// invalid types T2::u and T2::u::u will be formed when T2 is substituted in nondeduced contexts. // T and U in #2.2 deduces to, respectively, T1 and T1::u from A<T1, T1::u, struct T1::u::u> * unless // struct T1::u::u does not refer to the injected-class-name of the class T1::u (if that is possible). struct B { struct u { }; }; int main() { foo((A<B, B::u, struct B::u::u> *)0); // calls #2.1 } It is however unclear to what extent an implementation will have to go to determine these minimal properties. |
This is a test of the interpretation of the resolution to Issue 214. In particular, we would like for the committee to spell out how properties of the synthetics produced for partial ordering are determined | CWG | 1157 |
REJECTED
Resolving this issue was not deemed essential for this revision of the Standard. Core language issue 1157 was opened, however, to allow for possible consideration for a future revision. |
US 72 | 14.5.7 [temp.alias] | Template aliases have no implementation experience. | Either demonstrate a complete implementation of this feature or remove N2258 from the working paper prior the FDIS. | CWG |
ACCEPTED
The feature has been implemented. |
|
US 73 | 14.5.7 ¶ 1 |
The current wording of 7.1.3p2 requires that the identifier
in an alias-declaration "...shall not appear in the type-id."
With template aliases, however, the name of the alias can
be used indirectly:
template<typename T> struct A; template<typename T> using B=typename A<T>::U; template<typename T> struct A { typedef B<T> U; }; B<short> b;Here the instantiation of B<short> causes the instantiation of A<short>, and the typedef in A<short> ends up attempting to use B<short>, which is still in the process of being instantiated. |
Add wording to indicate that such usages in template aliases are ill-formed. | CWG | 1158 | ACCEPTED |
US 74 | 14.5.7 ¶ 1 |
An alias-declaration allows a class or enumeration type to
be defined in its type-id (7.1.6p3). However, it's not clear
that this is desirable when the alias-declaration is part of a
template alias:
template<typename T> using A = struct { void f(T) { } }; |
Either prohibit the definition of classes and enumerations in template aliases, or prohibit the use of template parameters in such definitions, or add an example illustrating this usage. | CWG | 1159 |
ACCEPTED
Definition of a class or enumeration is now prohibited in a template alias. |
FI 10 | 14.5.7 [temp.alias] | Can template aliases be declared in class scope? | Allow declaring template aliases in class scope, if not allowed by the current grammar. | CWG | 924 | ACCEPTED |
FI 11 | 14.5.7 [temp.alias] | We have class templates and function templates, shouldn't we call template aliases alias templates for consistency? | Change “template alias” -> “alias template” everywhere. | editor | ||
JP 25 | 14.5.7 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(clause 7)" to "(Clause 7)". | editor | ACCEPTED | |
JP 26 | 14.6.2.1 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(9)" to "(Clause 9)". | editor | ACCEPTED | |
GB 43 | 14.6.2.1p3 |
If I'm not missing something, 14.6.2.1/3 says that in the
definition of a class template or member of a class
template, the injected-class-name refers to the current
instantiation. The template name followed by the
argument list enclosed in “<..>” also refers to the current
instantiation, but only in the definition of a primary class
template. That results in an odd situation: template<typename T> struct A { typedef int type; void f(type); }; // here we are outside the definition of 'A' template<typename T> void A::f(A::type) { } // OK: 'A' is the injected-class-name template<typename T> void A::f(A<T>::type) { } // ill-formed: 'A<T>' is not the injected-class-name. Needs 'typename '! If you would define the member-function within the primary class template, bullet 2 would apply: template<typename T> struct A { typedef int type; void f(A<T>::type) { } // OK: name of A followed by arguments enclosed in <..> }; I think that this state of affairs isn't any good. -> Suggested solution: Change 14.6.2.1/1 bullet2 to apply also to members of the primary class template. The same for bullet4 talking about partial specializations. Since partial specializations are also class templates, i wonder whether one could also smelt together bullet2 and bullet4 and only talk about “class template”. |
Updated 14.6.2.1 [temp.dep.type] p1 bullet 2: " in the definition of a primary class template or a member of a class template, the name of the class template followed by the template argument list of the primary template (as described below) enclosed in <>," | CWG | 1160 | ACCEPTED |
GB 44 | 14.6p5 |
C++0x does not allow this code
template<typename T> struct id { typedef T type; }; template<typename T> void f() { int id<T>::type::*p = 0; } struct A { }; int main() { f<A>(); }The reason is that it requires “typename” before “id<T>::type”, but “typename” is not allowed at that place by the syntax. Ultimately, current compilers accept this. |
Change 14.6/5 to A qualified name used as the name in a mem-initializer-id, a base-specifier, an elaborated-type-specifier or the nested-name-specifier of a pointer-to-member declarator is implicitly assumed to name a type, without the use of the typename keyword. |
CWG | 1161 | ACCEPTED |
CA 6 | 14.6p5 ¶ P5 |
Given the change in N1376=02-0034 to [temp.res], found
in FCD in [temp.res] paragraph 5: A qualified name used as the name in a mem-initializer-id, a base-specifier, or an elaborated-type-specifier is implicitly assumed to name a type, without the use of the typename keyword the following appears to be well-formed, with templates foo() being distinct since any type T will produce an invalid type for the second parameter for at least one foo() when T is replaced within the non-deduced context: template <typename T> bool *foo(T *, enum T::u_type * = 0) { return 0; } template <typename T> char *foo(T *, struct T::u_type * = 0) { return 0; } struct A { enum u_type { I }; }; int main(void) { foo((A*)0); }In particular, while determining the signature (1.3.11 [defns.signature]) for the function templates foo(), an elaborated-type-specifier qualifies as part of the decl-specifier-seq under 8.3.5 [dcl.fct] paragraph 5 in determining the type of a parameter in the parameter-type-list (absent additional wording). Also, the return type is included in the signature of a function template. A portion of the GCC 4.5.0 output: Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See < http://gcc.gnu.org/bugs.html > for instructions. Implementations do not appear to support this case and the ability to do so brings little value since type traits such as is_enum and is_class cannot be defined using this and equivalent functionality can be achieved using the aforementioned type traits. template <typename T> struct MY_is_enum : std::false_type { }; template <typename T> struct MY_is_enum<enum T> : std::true_type { }; // ill-formed,elaborated-type-specifier resolves to typedef-name |
Please clarify as the following case appears to be expensive to implement with little functional value to the language. | CWG | 1162 |
REJECTED
The specification is as intended; compilers should handle cases like these. |
US 75 | 14.7 | As described in c++std-core-16425 and its followup messages, writing metaprograms is needlessly hard because specializing template members inside a class is (inadvertently?) not permitted. In addition, this surprising restriction makes C++ less simple and more arbitrary-seeming. | Accept the code like that in c++std-core-16425, like Visual C++ does already | CWG |
REJECTED
There was no consensus for making the suggested change. |
|
JP 79 | 14.7.1 ¶ 10 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing constness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
namespace N { template<class T> class List { public: T* get(); }; } template<class K, class V> class Map { public: N::List<V> lt; V get(K); }; void g(Map<const char*,int>& m) { int i = m.get("Nicholas"); }a call of lt.get() from Map<const char*,int>::get() would place List<int>::get() in the namespace N rather than in the global namespace. —end example ] |
editor | ACCEPTED | |
FI 9 | 14.7.3 [temp.expl.spec] ¶ Paragraph 2 | Explicit specializations in class scope inside class templates should be allowed. It's weird, confusing and inconsistent that they can be declared/defined in some scopes but not in others. | Allow explicit specialization of member templates inside class templates. | CWG |
REJECTED
There was no consensus for making the suggested change. |
|
JP 80 | 14.8.1 ¶ 5 |
"char*" should be "const char *". The special rule to convert character literal to pointer has been removed from "4.2 Array-to-pointer conversion [conv.array]". char * p1 = "..." ; // ill-formed.(removing const'ness) char const *p2 = "..." ;// well-formed.There are many code fragments depending on the removed rule. They are ill-formed. |
Change to:
template<class X, class Y, class Z> X f(Y,Z); template<class ... Args> void f2(); void g() { f<int,const char*,double>("aa",3.0); f<int,const char*>("aa",3.0); // Z is deduced to be double f<int>("aa",3.0); // Y is deduced to be const char*, and // Z is deduced to be double f("aa",3.0); // error: X cannot be deduced f2<char, short, int, long>(); // OK } |
editor | ACCEPTED | |
US 76 | 14.8.2 ¶ para 9 | "extern template" prevents inlining functions not marked inline. | Remove wording about "suppressing the implicit instantiation". See Appendix 1 - Additional Details | CWG | 1163 |
REJECTED
Section reference should be 14.7.2. The suggested change could result in a silent change of meaning between implementations if speculative instantiation for inlining is allowed. |
US 77 | 14.8.2.1 |
Core Issue 1014 claims that calling f(const T&) and f(T&&)
with a const int lvalue is ambiguous. It's unambiguous
because the partial ordering rules consider f(const T&) to
be more specialized than f(T&&), for the same reasons
that they consider h(const T&) to be more specialized than
h(T&). However, calling z(T&) and z(T&&) with an int lvalue is ambiguous. Because z(T&) accepts a strict subset of the things that z(T&&) accepts, it seems that the partial ordering rules should be modified to consider z(T&) to be more specialized than z(T&&). There may be additional subtleties. |
Modify the partial ordering rules to consider z(T&) to be more specialized than z(T&&). | CWG | 1164 | ACCEPTED |
US 78 | 15.2 ¶ 2 |
This paragraph says that "An object that is... partially
destroyed will have destructors executed... for subobjects
for which the principal constructor (12.6.2) has completed
execution and the destructor has not yet begun
execution." This would presumably apply to an example
like
struct S { ~S(); } s[10];If the destructor for s[5] throws an exception, elements 0-4 should still be destroyed. However, the wording specifically refers to "fully constructed base classes and non-variant members," even though array elements are subobjects of the array (1.8p2). This is presumably the effect of stack unwinding (p1), which applies to "all automatic objects constructed since the try block was entered," but whether that should also be expected for arrays of static, thread, and dynamic storage duration is not clear. |
Clarify the intent with respect to array elements and storage duration. | CWG | 1165 | ACCEPTED |
GB 45 | 15.3 ¶ 16 | The phrasing of this clause suggests all exception-declarations produce objects. There should be some additional wording to clarify that exception-declarations that declare references bind to the exception object by appropriate initialization, and *are* allowed to be references to abstract classes. Likewise, the elipsis form does not initialize any object or temporary. | Distinguish between initializing objects, initializing references, and initializing nothing in the case of an elipsis. | CWG | 1166 |
REJECTED
Resolving this issue was not deemed essential for this revision of the Standard. However, issue 1166 was opened for possible consideration in a future revision. |
CA 5 | 15.3p8, 15.1p7 ¶ P8, p7 |
There is an issue with the definition of "currently handled
exception" in 15.3 [except.handle] paragraph 8: The exception with the most recently activated handler that is still active is called the currently handled exception. This wording implies that the currently handled exception may be changed by another thread. Thus, by 15.1 [except.throw] paragraph 7, A throw-expression with no operand rethrows the currently handled exception (15.3). the following may throw an exception that is not of type int. try { throw 0; } catch (...) { throw; } Any solution should also specify what the currently handled exception will be for a thread that is spawned during the handling of an exception by its parent. |
Clarify and fix as suggested. | CWG | 1218 | ACCEPTED |
US 79 | 15.4 ¶ p1 | Because C has no exception mechanism, functions having "C" language linkage should implicitly be declared noexcept. |
Insert a sentence such as: Any function declared to have "C" linkage shall be treated as if declared noexcept even if the declaration lacks the noexcept keyword. |
CWG |
REJECTED
There was no consensus for making the suggested change. |
|
GB 46 | 15.4 | It is not entirely clear that a function-try-block on a destructor will catch exceptions for a base or member destructor destructor; whether such exceptions might be swallowed with a simple return statement rather than being rethrown; and whether such a clause might be entered multiple times if multiple bases/members throw, or if that is an automatic terminate call. | [Add words to 15.4 clarifying the problem cases.] | CWG | 1167 | ACCEPTED |
CH 10 | 15.4 ¶ p9 | In case of incorrect program specification, the general rule is that the behaviour is undefined. This should be true for noexcept as well. | Change the second bullet of p9 to "otherwise, the behaviour is undefined. | CWG |
REJECTED
There was no consensus to reconsider the explicit decision of the Committee on this point. |
|
GB 47 | 15.5.1 ¶ 1 | 15.5.1:1 [except.terminate] lists the situations in which "exception handling must be abandoned for less subtle error handling techniques". The list seems to omit some new situations added by other c++0x features. |
The list should be augmented with the following:
Function std::terminate is also called by the implementation, when the destrductor or a copy constructor of a class std::thread is called for the object that is joinable. |
CWG | 1168 | ACCEPTED |
GB 48 | 15.5.2 ¶ 1-4 | This subclause is dealing exclusively with dynamic exception specifications, and should clearly say so. | Replace each italicised occurrence of 'exceptionspecification' with 'dynamic-exceptionspecification' in clause 15.5.2, [except.unexpected] | editor | ACCEPTED | |
GB 49 | 15.5.2 ¶ all | Dynamic exception specifications are deprecated, so clause 15.5.2 that describes how they work should move to Annex D. | Move 15.5.2 [except.unexpected] to Annex D. | CWG |
REJECTED
The convention in the core clauses is to note the deprecation but leave the specification in situ. |
|
CH 11 | 16.1 ¶ p3 | constant-expression as given by C++'s grammar allows far more syntactical constructs than those that are allowed in preprocessor context. The footnote 145 provides some hints on the limitations, but in our opinion it should be made more clear that the "constant-expression" allows less than a lookup of the corresponding grammar rule suggests | Add a note or extend footnote 145 with "Note that constant-expression is much more limited than the C++ grammar rule would suggest. See the following paragraphs how it is limited in the context of conditional inclusion." | editor |
REJECTED
The current wording is the same as in C++03, and hasn't caused confusion. |
|
CH 12 | 16.3.5 ¶ p5 | missing space between '~' and '5' in expansion |
line
"f(2 * (2+(3,4)-0,1)) | f(2 * (~5)) & f(2 * (0,1))^m(0,1);"should read "f(2 * (2+(3,4)-0,1)) | f(2 * (~ 5)) & f(2 * (0,1))^m(0,1);" |
editor | ACCEPTED | |
CH 13 | 16.3.5 ¶ p7 | superfluous braces in source |
change
"int j[] = { t(1,2,3), t(,4,5), t(6,{,}7), t(8,9,),"to "int j[] = { t(1,2,3), t(,4,5), t(6,,7), t(8,9,)," |
editor | ACCEPTED | |
CH 14 | 16.3.5 ¶ p9 | superfluous spaces after/before parentheses |
change
fprintf(stderr, "Flag" ); fprintf(stderr, "X = %d\n", x ); puts( "The first, second, and third items." );to fprintf(stderr, "Flag"); fprintf(stderr, "X = %d\n", x); puts("The first, second, and third items."); |
editor | ACCEPTED | |
DE 13 | 16.8 | Committee Draft comment DE 18 has only been partially addressed, and the record of response ignores the missing item, namely the absence of a macro __STDCPP_STRICT_POINTER_SAFETY__ that indicates that a given implementation has strict pointer safety (see 3.7.4.3). | Add the macro to the list of predefined macros in 16.8. | CWG | 1169 | ACCEPTED |
US 80 | [library] 17 - 30 | Consider applying noexcept to all of the std::lib. | LWG | 1347 |
ACCEPTED with MODIFICATIONS
See paper N3155 |
|
GB 60 | 17-30 | Dyanamic exception specifications are deprecated; the library should recognise this by replacing all non-throwing exception specifications of the form 'throw()' with the 'noexcept' form. | Replace all non-throwing exception specifications of the form 'throw()' with the 'noexcept' form. | LWG | 1344 |
ACCEPTED with MODIFICATIONS
See documents N3148, N3150, N3195, N3155, N3156, N3199, and N3180. See paper N3148 |
GB 61 | 17-30 |
All library types should have non-throwing move
constructors and move-assignment operators unless
wrapping a type with a potentially throwing moveoperation.
When such a type is a class-template, these
operations should have a conditional noexcept
specification. There are many other places where a noexcept specification may be considered, but the move operations are a special case that must be called out, to effectively support the move_if_noexcept function template. |
Review every class and class template in the library. If noexcept move constructor/assignment operators can be implicitly declared, then they should be implicitly declared, or explicitly defaulted. Otherwise, a move constructor/moveassingment operator with a 'noexcept' exception specification should be provided. | LWG | 1345 | |
GB 62 | 17-30 | 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. | Add a 'noexcept' exception specification on each libary API that offers an unconditional Throws: Nothing guarantee. Where the guarantee is conditional, add the appropriate noexcept(constant-expression) if an appropriate constant expression exists. | LWG | 1346 |
ACCEPTED with MODIFICATIONS
See paper N3195 |
GB 63 | 17-30 | Since the newly introduced operator noexcept makes it easy (easier than previously) to detect whether or not a function has been declared with the empty exception specification (including noexcept) 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. | Review the whole library, and apply the noexcept specification where it is appropriate. | LWG | 1347 |
ACCEPTED with MODIFICATIONS
See paper N3155 |
GB 64 | 17-30 | There are a number of unspecified types used throughout the library, such as the container iterators. Many of these unspecified types have restrictions or expectations on their behaviour in terms of exceptions. Are they permitted or required to use exception specifications, more specifically the new noexcept specification? For example, if vector<T>::iterator is implemented as a native pointer, all its operations will have an (effective) nothrow specification. If the implementation uses a class type to implement this iterator, is it permitted or required to support that same guarantee? | Clearly state the requirements for exception specifications on all unspecified library types. For example, all container iterator operations should be conditionally noexcept, with the condition matching the same operation applied to the allocator pointer_type, a certain subset of which are already required not to throw. | LWG | 1348 | |
GB 65 | 17-30 | Nothrowing swap operations are key to many C++ idioms, notably the common copy/swap idiom to provide the strong exception safety guarantee. | Where possible, all library types should provide a swap operation with an exception specification guaranteeing no exception shall propagate. Where noexcept(true) cannot be guaranteed to not terminate the program, and the swap in questions is a template, an exception specification with the appropriate conditional expression could be specified. | LWG | 1349 | |
GB 66 | 17-30 |
The syntax for attributes was altered specifically to make it
legal do declare attributes on functions by making the
attribute the first token in the declaration, rather than
inserting it between the function name and the opening
paren of the parameter list. This is much more readable,
and should be the preferred style throughout the library.
For example, prefer: [[noreturn]] void exit(int status); to void exit [[noreturn]] (int status); |
Update all function declarations throughout the library to use the preferred placement of functionlevel attributes. | editor | ACCEPTED | |
CH 15 | Library clauses | Due to the new rules about implicit copy and move constructors some library facilities are now move-only. | Make them copyable again. | LWG | 1421, 1350 | |
CH 16 | Library clauses | Dynamic exception specifications are deprecated. Deprecated features shouldn't be used in the Standard. | Replace dynamic exception specifications with noexcept. | LWG | 1351 |
ACCEPTED with MODIFICATIONS
See documents N3148, N3150, N3195, N3155, N3156, N3199, and N3180. See paper N3148 |
CH 17 | Library clauses | The introduction of noexcept makes "Throws: Nothing" clauses looking strange. | Consider replacing "Throws: Nothing." clause by the respective noexcept specification. | LWG | 1352 |
ACCEPTED with MODIFICATIONS
See paper N3195 |
CH 18 | 17 | The general approach on moving is that a library object after moving out is in a "valid but unspecified state". But this is stated at the single object specifications, which is error prone (especially if the move operations are implicit) and unnecessary duplication. | Consider putting a general statement to the same effect into clause 17. | LWG | 1353 | |
JP 27 | 17.1 ¶ 9 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(25)" to "(Clause 25)". | editor | ACCEPTED | |
GB 52 | 17.3.7 | The definition of deadlock in 17.3.7 excludes cases involving a single thread making it incorrect. | The definition should be corrected. | LWG | 1354 | ACCEPTED with MODIFICATIONS |
GB 50 | 17.3.13 | This definition of move-assignment operator redundant and confusing now that the term move-assignment operator is defined by the core language in subclause 12.8p21. | Strike suclause 17.3.13 [defns.move.assign.op]. Add a cross-reference to (12.8) to 17.3.12. | LWG | 1355 |
ACCEPTED with MODIFICATIONS
See paper N3142 |
GB 51 | 17.3.14 | This definition of move-constructor redundant and confusing now that the term constructor is defined by the core language in subclause 12.8p3. | Strike subclause 17.3.14, [defns.move.ctor] | LWG | 1356 |
ACCEPTED with MODIFICATIONS
See paper N3142 |
JP 67 | 17.5.2.1.2 ¶ 2 |
In some code examples, ellipsis(...) is used in ill-formed.
In these cases, "..." represents omission of some codes
like this: class A { /* ... */ } ; But in some cases, it is used without commented-out as below: class A { ... } ; It is an inconsistent usage. They all should be enclosed in a comment. In addition, the number of period should be 3 rather than 5. |
Change to:
enum bitmask { V0 = 1 << 0, V1 = 1 << 1, V2 = 1 << 2, V3 = 1 << 3, ... }; static const /* ... */ |
editor |
REJECTED
This is pseudo-code; okay as written. |
|
GB 53 | 17.5.2.1.3 | 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. | See Appendix 1 - Additional Details | LWG | 1357 |
ACCEPTED with MODIFICATIONS
See paper N3110 |
GB 54 | 17.5.2.1.4.x | The defined terms NTC16S, NTC32S, NTWCS, char16-character sequence, null-terminated char16-character string, char32-character sequence, null-terminated char32-character string, wide-character sequence and null-terminated wide-character string do not occur at any point in the standard outside their definitional subclauses and associated footnotes. | Strike 17.5.2.1.4.3, 17.5.2.1.4.4, 17.5.2.1.4.5 and associated footnotes 170, 171, 172, 173, 174 and 175. | editor | ACCEPTED | |
GB 55 | 17.6.1.3 ¶ Table 15 | The thread header uses duration types, found in the <chrono> header, and which rely on the ratio types declared in the <ratio> header. | Add the <chrono> and <ratio> headers to the freestanding requirements. It might be necessary to address scaled-down expectations of clock support in a freestanding environment, much like <thread>. | LWG | 1358 | |
GB 56 | 17.6.1.3 ¶ Table 15 | The <utility> header provides support for several important C++ idioms with move, forward and swap. Likewise, declval will be frequently used like a type trait. In order to complete cycles introduced by std::pair, the <tuple> header should also be made available. This is a similarly primitive set of functionality, with no dependency of a hosted environment, but does go beyond the minimal set of functionality otherwise suggested by the freestanding libraries. Alternatively, split the move/forward/swap/declval functions out of <utility> and into a new primitive header, requiring only that of freestanding implementation. | Add <utility> and <tuple> to table 15, headers required for a free-standing implementation. | LWG | 1359 |
REJECTED
No consensus for a change at this time. |
GB 57 | 17.6.1.3 ¶ Table 15 | 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. | Add <atomic> to table 15, headers required for a free-standing implementation. | LWG | 1360 | ACCEPTED |
GB 58 | 17.6.2 |
It is not clear whether a library header specified in terms
of a typedef name makes that same typedef name
available for use, or if it simply requires that the specified
type is an alias of the same type, and so the typedef name
cannot be used without including the specific header that
defines it. For example, is the following code required to
be accepted:
#include <vector> std::size_t x = 0;Most often, this question concerns the typedefs defined in header <cstddef> |
Add a paragraph under 17.6.2 clarifying whether or not headers specified in terms of std::size_t can be used to access the typedef size_t, or whether the header <cstddef> must be included to reliably use this name. | LWG | 1361 |
REJECTED
The standard is correct as written. |
GB 59 | 17.6.3.6 ¶ 2 | The replaceable functions in header <new> are all described in clause 18.6 [support.dynamic], where it can be seen that all the listed functions have an exception specification which must be compatible with any replacement function. Narrow the reference to (Clause 18) to (Clause 18.6). |
Add the missing exception specification on each
function signature: void* operator new(std::size_t size) throw(std::bad_alloc); void* operator new(std::size_t size, const std::nothrow_t&) throw(); void operator delete(void* ptr) throw(); void operator delete(void* ptr, const std::nothrow_t&) throw(); void* operator new[](std::size_t size) throw(std::bad_alloc); void* operator new[](std::size_t size, const std::nothrow_t&) throw(); void operator delete[](void* ptr) throw(); void operator delete[](void* ptr, const std::nothrow_t&) throw(); (note that other comments might further want to replace 'throw()' with 'noexcept') |
editor |
ACCEPTED with MODIFICATIONS
Cross-reference changed as requested. Additions to name mentions not done: these are not declarations. |
|
US 81 | 17.6.3.9 ¶ p1 | International Standards do not make “statements”; they “specify” or “require” instead. | s/statements/ specifications/ | editor |
ACCEPTED with MODIFICATIONS
Removed the offending word. |
|
US 82 | 17.6.3.9 ¶ p1, bullet 3 | The second Note can benefit by adopting recent nomenclature. | Rephrase the Note in terms of xvalue. | LWG | 1362 | ACCEPTED with MODIFICATIONS |
US 83 | 17.6.3.10 ¶ p2, first sent. | The word “constructor” is misspelled. | s/contructor/constructor/ | editor | ACCEPTED | |
GB 68 | 18.2 ¶ 4 | 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. |
Add to the end of 18.2p4: "No operation invoked by the offsetof macro shall throw an exception, and noexcept(offsetof(type,member-designator)) shall be true." |
LWG | 1363 | ACCEPTED |
JP 68 | 18.3.1.5 ¶ 2 |
In some code examples, ellipsis(...) is used in ill-formed.
In these cases, "..." represents omission of some codes
like this: class A { /* ... */ } ; But in some cases, it is used without commented-out as below: class A { ... } ; It is an inconsistent usage. They all should be enclosed in a comment. More over, in this case, "implementation-defined" would be better than "...". |
Change to:inline static constexpr float infinity() throw() { return /* ... */; } inline static constexpr float quiet_NaN() throw() { return /* ... */; } inline static constexpr float signaling_NaN() throw() { return /* ... */; } |
editor |
ACCEPTED with MODIFICATIONS
Replaced "..." by "value". |
|
JP 84 | 18.5 ¶ 5 note | Note in paragraph 5 says "the atexit() functions shall not introduce a data race" and Note in paragraph 10 says "the at_quick_exit() functions do not introduce ...". Such different expressions in similar functions are confusing. If these notes are written for unspecified behaviors just before the sentence, "do" would be preferred. | Replace "shall" with "do". | editor | ACCEPTED | |
GB 69 | 18.5 ¶ 14 | ("The function quick_exit() never returns to its caller.") should be removed as redundant. The function is already attributed with [[noreturn]]. | Remove paragraph 14 | editor | ACCEPTED | |
CH 19 | 18.8.5 | It's not clear how exception_ptr is synchronized. | Make clear that accessing in different threads multiple exception_ptr objects that all refer to the same exception introduce a race. | LWG | 1364 | |
GB 70 | 18.6 | std::nothrow_t is a literal type (being an empty POD) so the preferred form of declaration for std::nothrow is as a constexpr literal, rather than an extern symbol. |
Replace: extern const nothrow_t nothrow; with constexpr nothrow_t nothrow{}; |
LWG |
REJECTED
There was consensus that it is too late to make such a change at this time. |
|
GB 71 | 18.6.2.4 / 18.8.2.2 / 18.8.3.2 | The thread safety of std::set_new_handler(), std::set_unexpected(), std::set_terminate(), is unspecified making the the functions impossible to use in a thread safe manner. | 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. | LWG | 1365 |
ACCEPTED with MODIFICATIONS
See paper N3189 |
DE 14 | 18.6.1.4 | 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 std::set_new_handler. | Offer a non-mutating interface to query the current new-handler. | LWG | 1366 |
ACCEPTED with MODIFICATIONS
See paper N3189 |
GB 72 | 18.8.2 | 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 bad_exception class which is retained to indicate other failures in the exception dispatch mechanism (e.g. calling current_exception()). | 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. | LWG | 1367 | ACCEPTED |
GB 73 | 18.8.4 | The thread safety std::uncaught_exception() 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. | Update this clause to support safe calls from multiple threads without placing synchronization requirements on the user. | LWG | 1368 | ACCEPTED with MODIFICATIONS |
GB 74 | 18.8.5 ¶ 10 | One idea for the exception_ptr type was that a referencecounted implementation could simply 'reactivate' the same exception object in the context of a call to 'rethrow_exception'. Such an implementation would allow the same exception object to be active in multiple threads (such as when multiple threads join on a shared_future) and introduce potential data races in any exception handler that catches exceptions by reference - notably existing library code written before this capability was added. 'rethrow_exception' should *always* make a copy of the target exception object. | Throws: a copy of the exception object to which p refers. | LWG | 1369 | |
US 84 | 18.8.6 [except.nested] ¶ 6-7 | The throw_with_nested spec passes in its argument as T&& (perfect forwarding pattern), but then discusses requirements on T without taking into account that T may be an lvalue-reference type. It is also not clear in the spec that t is intended to be perfectly forwarded. | Patch 6-7 to match the intent with regards to requirements on T and the use of std::forward<T>(t). | LWG | 1370 | ACCEPTED with MODIFICATIONS |
GB 75 | 19 | None of the exception types defined in clause 19 are allowed to throw an exception on copy or move operations, but there is no clear specification that the operations have an exception specification to prove it. Note that the implicitly declared constructors, taking the exception specification from their base class (ultimately std::exception) will implicitly generate a noexcept exception specification if all of their data members similarly declare noexcept operations. As the representation is unspecified, we cannot assume nonthrowing operations unless we explicitly state this as a constraint on the implementation. | Add a global guarantee that all exception types defined in clause 19 that rely on implicitly declared operations have a non-throwing exception specification on those operations. | LWG | 1371 | |
GB 76 | 19.5.1.5 | The C++0x FCD recommends, in a note (see 19.5.1.1/1), that users create a single error category object for each user defined error category and specifies error_category 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 generic_category() and system_category() functions to return distinct objects for each invocation. | Append a new sentence to 19.5.1.5 [syserr.errcat.objects]/1, which reads "All calls of this function return references to the same object.", and append the same sentence to 19.5.1.5/3. | LWG | 1372 | ACCEPTED |
GB 77 | 19.5.6.2 ¶ 14 | The description for system_error::what (19.5.6.2/14) changed between the C++ Working Papers N2914 and N2960. The latter document indicates that the Returns clause shall read "Returns: An NTBS incorporating the arguments supplied in the constructor.". Instead, in the FCD it now reads "Returns: An NTBS incorporating and code().message() the arguments supplied in the constructor.". | Remove the extra words from 19.5.6.2 [syserr.syserr.members]/14: "Returns: A NTBS incorporating the arguments supplied in the constructor." | editor | ACCEPTED | |
GB 78 | 19.5.6.2 | The FCD contains a requirement that all standard classes which are derived from std::exception have a copy constructor and copy assignment operator which essentially copy the stored what() message (See 18.8.1/2). In contrast, it is unspecified whether copies of system_error return the same error_code on calls to system_error::code(). | Insert a new paragraph after 19.5.6.1 [syserr.syserr.overview]/1 which reads "The copy constructor and copy assignment operator of class system_error both have a strengthened postcondition which supplements the basic postcondition for standard library exception classes copy construction and copy assigment (18.8.1): If two objects lhs and rhs both have type system_error and lhs is a copy of rhs, then lhs.code() == rhs.code() shall hold." | LWG |
REJECTED
This is already addressed by 17.5.2.2 [functions.within.classes]/1. |
|
GB 79 | 20, 22, 24, 28 | The library provides several traits mechanisms intended a customization points for users. Typically, they are declared in headers that are growing quite large. This is not a problem for standard library vendors, who can manage their internal file structure to avoid large dependencies, but can be a problem for end users who have no option but to include these large headers. |
Move the following traits classes into their own
headers, and require the existing header to
#include the traits header to support backwards
compatibility: iterator_traits (plus the iterator tag-types) allocator_traits pointer_traits char_traits regex_traits |
LWG | 1373 |
REJECTED
This suggest is not a defect, as the likely benefit is small, if any, compared to the cost of not just implementating the feature, but also explaining/teaching it. |
US 85 | 20.2.1 ¶ Table 34 |
20.2.1 Table 34 "MoveConstructible requirements" says
"Note: rv remains a valid object. Its state is unspecified".
Some components give stronger guarantees. For
example, moved-from shared_ptrs are guaranteed empty
(20.9.11.2.1/25).
In general, what the standard really should say (preferably
as a global blanket statement) is that moved-from objects
can be destroyed and can be the destination of an
assignment. Anything else is radioactive. For example,
containers can be "emptier than empty". This needs to be
explicit and required generally. Note: The last time that one of us mentioned "emptier than empty" (i.e. containers missing sentinel nodes, etc.) the objection was that containers can store sentinel nodes inside themselves in order to avoid dynamically allocating them. This is unacceptable because (a) it forces existing implementations (i.e. Dinkumware's, Microsoft's, IBM's, etc.) to change for no good reason (i.e. permitting more operations on moved-from objects), and (b) it invalidates end iterators when swapping containers. (The Working Paper currently permits end iterator invalidation, which we consider to be wrong, but that's a separate argument. In any event, *mandating* end iterator invalidation is very different from permitting it.) |
State as a general requirement that moved-from objects can be destroyed and can be the destination of an assignment. Any other use is undefined behavior. | LWG | 1374 | |
GB 80 | 20.2.3 ¶ 2 | See (A) in attachment std_issues.txt | as stated in the attached paper | LWG | REJECTED | |
CA 10 | 20.2.3p2 ¶ 20.2.3p2 |
Reads of indeterminate value result in undefined
behaviour In 20.2.3p2, NullablePointer requirements [nullablepointer.requirements], the standard specifies the behaviour of programs that read indeterminate values: ... A default-initialized object of type P may have an indeterminate value. [ Note: Operations involving indeterminate values may cause undefined behaviour. end note ] We suggest changing the note to: [ Note: Operations involving indeterminate values cause undefined behaviour. end note ] Rationale: The note uses the word "may", but we believe the intention is that such reads will cause undefined behaviour, but implementations are not required to produce an error. Clark adds: > Unfortunately, this issue goes deeper than can be > addressed by deleting the word "may" from a note in > clause 20. The term "indeterminate value" and its > meaning were introduced in C99. While the term is > generally understood to be applicable to C++ (and > section 20.2.3 reflects that), the term isn't actually > defined in the C++ WD, and worse yet, there's no > statement that use of an indeterminate value can result > in undefined behavior (so the existing note can't be > deduced from the normative statements of the standard). > This is tracked by core issue 616. The wording in > 20.2.3 should be noted as relating to that issue, and > should be handled as part thereof. Further on this, in the current draft standard, we can construct executions in which an atomic read happensbefore the initialization of the atomic object, so there is no place to take a read value from. We imagine that such reads should also be of indeterminate values and result in undefined behaviour? |
In 20.2.3p2, the standard specifies the behaviour
of programs that read indeterminate values: ... A default-initialized object of type P may have an indeterminate value. [ Note: Operations involving We suggest changing the note to: [ Note: Operations involving indeterminate values cause undefined behaviour. end note ] |
LWG |
REJECTED
It is an accurate statement because there is at least one operation, assignment with the indeterminate value on the left hand side, that does not involve undefined behavior. |
|
US 86 | 20.2.5 ¶ Table 42 | In the row for X::propagate_on_container_move_assignment, the note says “copied” when it should say “moved” |
Change the note as follows: true_type only if an allocator of type X should be |
editor | ACCEPTED | |
US 87 | 20.2.5 ¶ Table 42 | reference_type should not have been removed from the allocator requirements. Even if it is always the same as value_type&, it is an important customization point for extensions and future features. |
Add a row (after value_type) with columns: Expression: X::reference_type Return type: T& Assertion/note...: (empty) Default: T& [allocator.traits]: Add reference_type to allocator_traits template, defaulted to value_type&. |
LWG | 1375 | |
US 88 | 20.2.5 | Allocator interface is not backward compatible. | See Appendix 1 - Additional Details | LWG | 1376 |
REJECTED
Withdrawn by the submitter. |
US 89 | 20.3 [utility] | make_pair is missing from the <utility> synopsis. | Add template <class T1, class T2> pair<V1, V2> make_pair(T1&&, T2&&); to the synopsis in [utility]. | editor | ACCEPTED | |
GB 81 | 20.3 ¶ 1 | make_pair should be declared in the synopsis of <utility> |
add to 20.3 [utility] paragraph 1: template see below make_pair(T1&&, T2&&); |
editor | ACCEPTED | |
GB 82 | 20.3 ¶ 1 |
The <utility> synopsis precedes the tuple_size and
tuple_element declarations with a comment saying "//
20.3.5, tuple-like access to pair:" but the sub-clause
should be 20.3.5.3 and the comment should probably be
below those declarations (since they, like the tuple
declaration above them, are defined in <tuple> and are
not related to pair.) Also, there should be a comment above piecewise_construct_t giving the sub-clause 20.3.5.5, and it should be at the end of the synopsis, |
correct the sub-clause reference for tuple-like access to 20.3.5.3, move the comment after the uple_element declaration, and add "// defined in <tuple>" to the tuple_size and tuple_element declarations. Move the piecewise_construct_t and piecewise_constrct declarations to the end of the synopsis and precede them with "// 20.3.5.5 Piecewise construction" | editor | ACCEPTED | |
US 90 | 20.3 ¶ 3 |
In n3090, at variance with previous iterations of the idea
discussed in papers and incorporated in WDs,
std::forward is constrained via std::is_convertible, 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 enable_ifs
instead of concepts for the constraining, of course)
#include <utility> struct Base { Base(Base&&); }; struct Derived : private Base { Derived(Derived&& d) : Base(std::forward<Base>(d)) { } };In other terms, LWG 1054 can be resolved in a better way, the present status is not acceptable. |
LWG | 1377 |
ACCEPTED with MODIFICATIONS
See paper N3143 |
|
JP 28 | 20.3.1 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(31)" to "(Clause 31)". | editor |
ACCEPTED with MODIFICATIONS
Changed to "(Table 31)". |
|
JP 29 | 20.3.1 ¶ 4, 6, 8 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(32)" to "(Clause 32)". | editor |
ACCEPTED with MODIFICATIONS
Changed to "(Table 32)". |
|
JP 30 | 20.3.2 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. |
Change "(34)" to "(Table 34)". Change "(36)" to "(Table 36)". |
editor | ACCEPTED | |
US 91 | Merged with US 90 | LWG | 1377 |
ACCEPTED with MODIFICATIONS
See paper N3143 |
||
US 92 | 20.3.3 | std::identity was removed from 20.3.3 [forward], apparently because std::forward() no longer needs it. However, std::identity was useful by itself (to disable template argument deduction, and to provide no transformation when one is requested). | Restore std::identity, possibly in a different section. | LWG |
REJECTED
No consensus to restore at this time. common_type can be used for the use case given. |
|
US 93 | 20.3.3 ¶ 6 | When teaching C++0x, students have consistently found the name std::move confusing because it doesn't actually move the object (it just makes it possible to move). It was also confusing for me. | Choose a name that expresses the semantics more clearly. Suggestion: std::unpin |
REJECTED
No consensus for a change. |
||
US 94 | 20.3.3 ¶ 9 | Returns clause for move_if_noexcept d refers to a nonexistent symbol, t, which should be x. |
Modify the Returns clause: Returns: std::move( |
editor | ACCEPTED | |
DE 15 | 20.3.5.2, 20.4.2.1 |
Several function templates of pair and tuple allow for too
many implicit conversions, for example:
#include <tuple> std::tuple<char*> p(0); // Error? struct A { explicit A(int){} }; A a = 1; // Error std::tuple<A> ta = std::make_tuple(1); // OK? |
Consider to add wording to constrain these function templates. | LWG | 1378 |
ACCEPTED with MODIFICATIONS
See paper N3140 |
JP 31 | 20.5.1 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(section 3.9)" to "(3.9)". | editor | ACCEPTED | |
GB 84 | 20.3.5.2 | [pairs.pair] defines the class template pair as well as related non-member functions such as comparison operators and make_pair. The related non-member functions should be in a separate sub-clause, otherwise it's not clear that paragraphs below 17 do not refer to members of pair. | Create a new "Pair specialized algorithms" section containing everything below paragraph 17 in [pairs.pair] | editor | ACCEPTED | |
US 95 | 20.3.5.2 ¶ 9 | Copy-assignment for pair 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 tuple. The copy-assignment operator should be consistent with the conversion-assignment operator and with tuple's assignment operators. |
Add to pair synopsis: pair& operator=(const pair& p); Add before paragraph 9: pair& operator=(const pair& p); Requires: T1 and T2 shall satisfy the requirements of CopyAssignable. Effects: Assigns p.first to first and p.second to second. Returns: *this. |
LWG | 1379 |
ACCEPTED with MODIFICATIONS
See paper N3140 |
DE 16 | 20.3.5.2, 20.4.2.1 | Several pair and tuple functions in regard to move operations are incorrectly specified if the member types are references, because the result of a std::move cannot be assigned to lvalue-references. In this context the usage of the requirement sets MoveConstructible and CopyConstructible also doesn't make sense, because non-const lvalue-references cannot satisfy these requirements. | Replace the usage of std::move by that of std::forward and replace MoveConstructible and CopyConstructible requirements by other requirements. | LWG | 1380 |
ACCEPTED with MODIFICATIONS
See paper N3140 |
GB 85 | 20.3.5.4 | While std::pair 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 pair 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. | Strike 20.3.5.4 and the matching declarations in 20.3 header synopsis. If a replacement facility is required for C++0x, consider n2995. | LWG | 1381 | ACCEPTED with MODIFICATIONS |
ES 1 | 20.3.5.4 [pair.range] | Using pair to represent a range of iterators is too general and does not provide additional useful restrictions (see N2995 and preceding papers). | Provide a separate template range<Iterator>. | LWG |
REJECTED
No consensus to make this change. |
|
US 96 | 20.3.5.2 20.4.2.1 20.4.2.2 ¶ p 6-14 p 6-20 p 6-18 | pair and tuple constructors and assignment operators use std::move when they should use std::forward. This causes lvalue references to be erroneously converted to rvalue references. Related requirements clauses are also wrong. | See Appendix 1 - Additional Details | LWG | 1382 |
ACCEPTED with MODIFICATIONS
See paper N3140 |
US 97 | 20.3.5.2 and 20.4.2 |
pair's class definition in N3092 20.3.5.2 [pairs.pair]
contains "pair(const pair&) = default;" and "pair&
operator=(pair&& p);". The latter is described by
20.3.5.2/12-13. "pair(const pair&) = default;" is a user-declared explicitlydefaulted copy constructor. According to 12.8 [class.copy]/10, this inhibits the implicitly-declared move constructor. pair should be move constructible. (12.8/7 explains that "pair(pair<U, V>&& p)" will never be instantiated to move pair<T1, T2> to pair<T1, T2>.) "pair& operator=(pair&& p);" is a user-provided move assignment operator (according to 8.4.2 [dcl.fct.def.default]/4: "A special member function is userprovided if it is user-declared and not explicitly defaulted on its first declaration."). According to 12.8/20, this inhibits the implicitly-declared copy assignment operator. pair should be copy assignable, and was in C++98/03. (Again, 12.8/7 explains that "operator=(const pair<U, V>& p)" will never be instantiated to copy pair<T1, T2> to pair<T1, T2>.) Additionally, "pair& operator=(pair&& p);" is unconditionally defined, whereas according to 12.8/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. If "pair(const pair&) = default;" and "pair& operator=(pair&& p);" were removed from pair's class definition in 20.3.5.2 and from 20.3.5.2/12-13, pair would receive implicitly-declared copy/move constructors and copy/move assignment operators, and 12.8/25 would apply. The implicitly-declared copy/move constructors would be trivial when T1 and T2 have trivial copy/move constructors, according to 12.8/13, and similarly for the assignment operators, according to 12.8/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 pair is copyable and movable). Alternatively, pair could be given explicitly-defaulted copy/move constructors and copy/move assignment operators. This is a matter of style. tuple is also affected. tuple's class definition in 20.4.2 [tuple.tuple] contains: tuple(const tuple&) = default; tuple(tuple&&); tuple& operator=(const tuple&); tuple& operator=(tuple&&);They should all be removed or all be explicitly-defaulted, to be consistent with pair. Additionally, 20.4.2.1 [tuple.cnstr]/8-9 specifies the behavior of an explicitlydefaulted function, which is currently inconsistent with pair. |
Either remove "pair(const pair&) = default;" and
"pair& operator=(pair&& p);" from pair's class
definition in 20.3.5.2 and from 20.3.5.2/12-13, or
give pair explicitly-defaulted copy/move
constructors and copy/move assignment
operators. Change tuple to match. |
LWG | 1383 |
ACCEPTED with MODIFICATIONS
See paper N3140 |
GB 86 | 20.4 | tuple and pair are essentially two implementations of the same type, with the same public interface, and their specification in becoming increasingly intertwined. The tuple library should be merged into the <utility> header to reduce library dependencies and simplify user expectations. The <tuple> header could optionally be retained as a deprecated alias to the <utility> header. | Merge everything declared in 20.4 into the <utility> header. Either remove the <tuple> header entirely, or move it to Annex D as a deprecated alias of the <utility> header. | LWG |
REJECTED
There was no consensus to make this change. |
|
US 98 | 20.4.2.4 ¶ Paragraph 4 | pack_arguments is poorly named. It does not reflect the fact that it is a tuple creation function and that it forwards arguments. | Rename pack_arguments to forward_as_tuple throughout the standard. | LWG | 1384 | ACCEPTED |
GB 88 | 20.4.2.4 | The tuple_cat template consists of four overloads and that can concatenate only two tuples. A single variadic signature that can concatenate an arbitrary number of tuples would be preferred. | Adopt a simplified form of the proposal in n2795, restricted to tuples and neither requiring nor outlawing support for other tuple-like types. | LWG | 1385 | |
US 99 | 20.4.2.4 ¶ 4 - 6 | pack_arguments is overly complex. |
This issue resulted from a lack of understanding of
how references are forwarded. The definition of
pack_arguments should be simply: template <class... Types> tuple< Effects: ... Returns: tuple< The synopsis should also change to reflect this simpler signature. |
LWG | 1386 | ACCEPTED |
GB 87 | 20.4.2.10 | 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. | Strike 20.4.2.10 and the matching declarations in the header synopsis in 20.4. | LWG | 1387 | ACCEPTED |
US 100 | 20.6.1 [ratio.ratio] | 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<N, D>, but the typedef is intended to refer to ratio<num, den> which in general is not the same type. |
Accept the current proposed wording of LWG
1281 which adds: typedef ratio<num, den> type; |
LWG | 1388 | ACCEPTED |
GB 89 | 20.6.2 | The alias representations of the ratio arithmetic templates do not allow implementations to avoid overflow, since they explicitly specify the form of the aliased template instantiation. For example ratio_multiply,ratio<2,LLONG_MAX>> is *required* to alias ratio<2*LLONG_MAX,LLONG_MAX*2>, which overflows, so is ill-formed. However, this is trivially equal to ratio<1,1>. It also contradicts the opening statement of 20.6.2p1 "implementations may use other algorithms to compute these values". |
Change the wording in 20.6.2p2-5 as follows: template <class R1, class R2> using ratio_add = see below; The type ratio_add<R1, R2> shall be a synonym for template <class R1, class R2> using ratio_subtract = see below; The type ratio_subtract<R1, R2> shall be a synonym for template <class R1, class R2> using ratio_multiply = see below; The type ratio_multiply<R1, R2> shall be a synonym for template <class R1, class R2> using ratio_divide = see below; The type ratio_divide<R1, R2> shall be a synonym for |
LWG | 1389 |
ACCEPTED with MODIFICATIONS
See paper N3210 |
US 101 | 20.7 | Paper n2965 was largely rejected after the last CD on the grounds there was no associated national body comment, so I am submitting a national body comment this time. | Consider n2965 in the context of a national body comment. | LWG |
REJECTED
There is no consensus to adopt this proposal at this time. |
|
GB 90 | 20.7 | type_traits is a core support facility offered by the compiler, and exposed with a library interface that is required in a free-standing implementation. It has far more in common with numeric_limits than the utility components in clause 20, and should move to clause 18. | Move clause 20.7 into clause 18. | editor |
REJECTED
Type traits support queries about all types, not just built-in types. They do not belong in Clause 18. |
|
DE 17 | 20.7 | Speculative compilation for std::is_constructible and std::is_convertible should be limited, similar to the core language (see 14.8.2 paragraph 8). | LWG | 1390 |
ACCEPTED with MODIFICATIONS
See paper N3142 |
|
DE 18 | 20.7 |
Several type traits require compiler support, e.g.
std::is_constructible or std::is_convertible. Their current
specification seems to imply, that the corresponding test
expressions should be well-formed, even in absense of
access:
class X { X(int){} }; constexpr bool test = std::is_constructible<X, int>::value;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. |
Specify that std::is_constructible and std::is_convertible will return true only for public constructors/conversion functions. | LWG | 1391 |
ACCEPTED with MODIFICATIONS
See paper N3142 |
US 102 | 20.7.4 | Despite Library Issue 520's ("Result_of and pointers to data members") resolution of CD1, the FCD's result_of supports neither pointers to member functions nor pointers to data members. It should. | Ensure result_of supports pointers to member functions and pointers to data members. | LWG | 1392 |
ACCEPTED with MODIFICATIONS
See paper N3123 |
GB 91 | 20.7.4.3 ¶ Table 45 | It is mildly distasteful to dereference a null pointer as part of our specification, as we are playing on the edges of undefined behaviour. With the addition of the declval function template, already used in these same expressions, this is no longer necessary. | Replace the sub-expression '*(U*)0' with the subexpression 'declval<U&>()' in the specification for has_nothrow_copy_assign and has_nothrow_move_assign type traits. | editor |
REJECTED
There is no undefined behavior because the expression is an unevaluated operand. It's not at all clear that the proposed change would be clearer. See paper N3142 |
|
GB 92 | 20.7.4.3 ¶ Table 45 | Trivial functions implicitly declare a noexcept exception specification, so the references to has_trivial_* traits in the has_nothrow_* traits are redundant, and should be struck for clarity. | For each of the has_nothrow_something traits, remove all references to the matching has_trivial_something traits. | LWG | 1393 |
ACCEPTED with MODIFICATIONS
See paper N3142 |
FI 18 | 20.7.4.3, Table 45 (Type property predicates) | Related to the change proposed in FI 17, there should be a trait for checking whether a destructor throws. |
Add the following type predicate:
Template
template <typename T> struct has_nothrow_destructor;Condition has_trivial_destructor<T>::value is true or the expression noexcept((*(U*)0).~U()) is well-formed and true, where U is remove_all_extents<T>::type. Precondition T shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound. Reasoning: With this metafunction the destructor of a class template can adjust its noexcept specification depending on whether destructors of its unbound members (or unbound base classes) might throw: template <typename T> struct C { T t; ~C() noexcept(has_nothrow_destructor<T>::value) {} }; |
LWG |
REJECTED
No consensus to make this change at this time. See paper N3142 |
|
DE 19 | 20.7.4.3 |
The fundamental trait is_constructible reports false
positives, e.g.
is_constructible<char*, void*>::valueevaluates to true, even though a corresponding variable initialization would be ill-formed. |
Remove all false positives from the domain of is_constructible. | LWG | 1394 |
ACCEPTED with MODIFICATIONS
See paper N3047 |
JP 32 | 20.7.5 ¶ 2, table 47 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(10)" to "(Clause 10)". | LWG | 1395 | ACCEPTED |
GB 93 | 20.7.6.2 ¶ Table 49 | The comments for add_rvalue_reference say "this rule reflects the semantics of reference collapsing", but reference collapsing is not defined anywhere. | Add a new sentence at the end of 8.3.2p6 "This is called reference collapsing". Add a reference to 8.3.2 to the use of "reference collapsing" in 20.7.6.2/table 49 | LWG | REJECTED | |
US 103 | 20.7.6.6 [meta.trans.other] | The current definition of result_of works for function pointers but the condition statement outlaws them. There is even an example in the WP that shows result_of working for function pointers. | Add “pointer to function” to the list of things that Fn shall be. | LWG |
REJECTED
Standard is correct as written. |
|
US 104 | 28.8 | std::basic_regex should have an allocator for all the reasons that a std::string does. For example, I can use boost::interprocess to put a string or vector in shared memory, but not a regex. | Add allocators to regexes | LWG | 1396 | |
GB 94 | 20.8 | This subclause has grown large, with many components, and so should stand alone. | Promote 20.8 and all its contents up to a new numbered clause. | editor | ||
GB 95 | 20.8 | The adaptable function protocol supported by unary_function/binary_function has been superceded by lambda expressions and std::bind. 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 function, bind and reference_wrapper. | Move clauses 20.8.3, 20.8.9, 20.8.11 and 20.8.12 to Annex D. Remove the requirements to conditionally derive from unary/binary_function from function, reference_wrapper, and the results of calling mem_fn and bind. | LWG | 1397 |
ACCEPTED with MODIFICATIONS
See paper N3198 |
GB 96 | 20.8 | The function templates 'hash', 'less' and 'equal_to' are important customization points for user-defined types to be supported by several standard containers. These are accessed through the <functional> header which has grown significantly larger in C++0x, exposing many more facilities than a user is likely to need through there own header, simply to declare the necessary specialization. There should be a smaller header available for users to make the necessary customization. | Provide a tiny forwarding header for important functor types in the <functional> header that a user may want to specialize. This should contain the template declaration for 'equal_to', 'hash' and 'less'. | LWG | 1398 |
REJECTED
No consensus to make a change. |
GB 97 | 20.8.10 | The bind template is intended as a singe, simple to use replacement for the '98 adaptable function APIs and machinery. It works well in almost all respects, but lacks the ability to easily negate a predicate, or equivalently, act as a replacement for not1 and not2. Two easy ways to solve this omission would be to add a 'bind_not' function that produces a binder that negates its result. However, preference is given to requiring the unspecified bind result type to overload operator! to produce the same effect. This is preferred due to (i) its simpler usage, being the naively expected syntax, but more importantly (ii) some (limited) field experience. | Require the unspecified result of a bind expression to support unary operator! to yield another bind result that, when evaluated, yields '!res', where 'res' is the result of evaluating the original function. | LWG |
REJECTED
No consensus for a change at this time. |
|
JP 3 | 20.8.14.2 | explicit default contructor is defined in std::function. Although it is allowed according to 12.3.1, it seems unnecessary to qualify the constructor as explicit. If it is explicit, there will be a limitation in initializer_list. |
Remove explicit.
namespace std { template<class> class function; // undefined template<class R, class... ArgTypes> class function<R(ArgTypes...)> : public unary_function<T1, R> // iff sizeof...(ArgTypes) == 1 and ArgTypes contains T1 : public binary_function<T1, T2, R> // iff sizeof...(ArgTypes) == 2 and ArgTypes contains T1 andT2 { public:typedef R result_type; // 20.8.14.2.1, construct/copy/destroy:function(); |
LWG | 1399 | ACCEPTED |
JP 33 | 20.8.15 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(37)" to "(Table 37)". | editor | ACCEPTED | |
JP 34 | 20.8.15 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(33)" to "(Table 33)". | editor | ACCEPTED | |
JP 4 | 20.8.14.2.1 ¶ 1 | Really does the function require that default constructor is explicit? |
Remove explicit.
function(); template <class A> function(allocator_arg_t, const A& a); |
LWG | 1400 | ACCEPTED |
US 105 | 20.8.15.2 |
unique_ptr and shared_ptr are inconsistent in their
handling of arrays. We can write:
unique_ptr<int[]> p( new int[10] ); // handles deletion correctlyBut we cannot write: shared_ptr<int[]> p( new int[10] ); // incorrectThis is an inconsistency. It is true that we have the following workaround: std::shared_ptr<int> s(new int[5], std::default_delete<int[]>());But this is still inconsistent, not to mention awkward and error-prone because the programmer will occasionally forget the deleter and the code will silently compile and may appear to work on some platforms. |
Support:
shared_ptr<int[]> p( new int[10] );to handle deletion correctly by calling delete[] on the stored pointer. |
LWG | REJECTED | |
GB 98 | 20.9 | This subclause has grown large, with many components, and so should stand alone. | Promote 20.9 and all of its contents to a new, toplevel, numbered clause. | editor | ||
GB 99 | 20.9 ¶ 1 | One reason that the unique_ptr constructor taking a nullptr_t argument is not explicit is to allow conversion of nullptr to unique_ptr in contexts like equality comparison. Unfortunately operator== for unique_ptr is a little more clever than that, deducing template parameters for both arguments. This means that nullptr does not get deduced as unique_ptr type, and there are no other comparison functions to match. |
Add the following signatures to 20.9p1, <memory>
header synopsis:
template<typename T, typename D> bool operator==(const unique_ptr<T, D> & lhs, nullptr_t); template<typename T, typename D> bool operator==(nullptr_t, const unique_ptr<T, D> & rhs); template<typename T, typename D> bool operator!=(const unique_ptr<T, D> & lhs, nullptr_t); template<typename T, typename D> bool operator!=(nullptr_t, const unique_ptr<T, D> & rhs); |
LWG | 1401 | |
GB 100 | 20.9 | The unique_ptr and shared_ptr constructors taking nullptr_t delegate to a constexpr constructor, and could be constexpr themselves. |
In the 20.9.10.2 [unique.ptr.single] synopsis add
"constexpr" to unique_ptr(nullptr_t). In the 20.9.10.3 [unique.ptr.runtime] synopsis add "constexpr" to unique_ptr(nullptr_t). In the 20.9.11.2 [util.smartptr.shared] synopsis add "constexpr" to shared_ptr(nullptr_t). |
LWG | 1402 | ACCEPTED |
JP 85 | 20.9.1 |
There are inconsistent definitions for allocator_arg.
In 20.9 [memory] paragraph 1,
constexpr allocator_arg_t allocator_arg = allocator_arg_t();and in 20.9.1, const allocator_arg_t allocator_arg = allocator_arg_t(); |
Change "const" to "constexpr" in 20.9.1 as
follows.
constexpr allocator_arg_t allocator_arg = allocator_arg_t(); |
LWG | 1403 | ACCEPTED |
US 106 | 20.9.3 ¶ all | pointer_traits should have a size_type member for completeness. |
Add “typedef see below size_type;” to the generic
pointer_traits template and “typedef size_t
size_type;” to pointer_traits<T*>. Use
pointer_traits::size_type and
pointer_traits::difference_type as the defaults for
allocator_traits::size_type and
allocator_traits::difference_type. See Appendix 1 - Additional Details |
LWG | 1404 | ACCEPTED with MODIFICATIONS |
GB 104 | 20.9.5.1 ¶ 13 | The ~ is missing from the invokation of the destructor of U. | Add the missing ~ : Effects: p->~U() | editor | ACCEPTED | |
GB 105 | 20.9.6 ¶ 1 | There is a missing '_' in the piecewise-construct call for pair in the class definition. |
Fix the declaration:
template <class T1, class T2, class... Args1, class... Args2> void construct(pair<T1, T2>* p, piecewise_construct_t, tuple<Args1...> x, tuple<Args2...> y); |
editor |
REJECTED
The declaration is identical to the proposed text. |
|
US 107 | 20.9.6 | scoped_allocator_adaptor should have its own header. | See Appendix 1 - Additional Details | LWG | 1405 | ACCEPTED |
GB 101 | 20.9.10 ¶ 5 | The first sentence of the paragraph says "Each object of a type U instantiated form the unique_ptr template..." "form" should be "from" | Replace "form" with "from" in the opening sentence: "Each object of a type U instantiated from the unique_ptr template..." | editor | ACCEPTED | |
FI 13 | 20.9.10. ¶ 5 | typo | "form the unique_ptr" should be "from the unique_ptr." | editor | ACCEPTED | |
GB 102 | 20.9.10 | unique_ptr is a smart pointer so [unique.ptr] should be a sub-clause of [util.smartptr] | move [unique.ptr] to a sub-clause of [util.smartptr] | editor |
REJECTED
[util.smartptr] deals with shared_ptr and weak_ptr, which work together. Adding unique_ptr would create a muddle. |
|
JP 35 | 20.9.10.2 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(38)" to "(Table 38)". | editor | ACCEPTED | |
JP 36 | 20.9.10.2.1 ¶ 1, 6 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(33)" to "(Table 33)". | editor | ACCEPTED | |
JP 37 | 20.9.10.2.1 ¶ 18 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(34)" to "(Table 34)". | editor | ACCEPTED | |
JP 38 | 20.9.10.2.3 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(36)" to "(Table 36)". | editor | ACCEPTED | |
JP 5 | 20.9.11.2 ¶ 1 |
Hash support based on ownership sharing should be
supplied for shared_ptr and weak_ptr.
For two shared_ptr objects p and q, two distinct
equivalence relations can be defined. One is based on
equivalence of pointer values, which is derived from the
expression p.get() == q.get() (hereafter called addressbased
equivalence relation), the other is based on
equivalence of ownership sharing, which is derived from
the expression !p.owner_before(q) && !q.owner_before(p)
(hereafter called ownership-based equivalence relation).
These two equivalence relations are independent in
general. For example, a shared_ptr object created by the
constructor of the signature shared_ptr(shared_ptr<U>
const &, T *) could reveal a difference between these two
relations. Therefore, hash support based on each
equivalence relation should be supplied for shared_ptr.
However, while the standard library provides the hash
support for address-based one (20.9.11.6 paragraph 2), it
lacks the hash support for ownership-based one. In
addition, associative containers work well in combination
with the shared_ptr's ownership-based comparison but
unordered associative containers don't. This is
inconsistent.>BR/>
For the case of weak_ptr, hash support for the ownershipbased
equivalence relation can be safely defined on
weak_ptrs, and even on expired ones. The absence of
hash support for the ownership-based equivalence
relation is fatal, especially for expired weak_ptrs. And the
absence of such hash support precludes some quite
effective use-cases, e.g. erasing the unordered_map entry
of an expired weak_ptr key from a customized deleter
supplied to shared_ptrs. Hash support for the ownership-based equivalence relation cannot be provided by any user-defined manner because information about ownership sharing is not available to users at all. Therefore, the only way to provide ownership-based hash support is to offer it intrusively by the standard library. As far as we know, such hash support is implementable. Typical implementation of such hash function could return the hash value of the pointer of the counter object that is internally managed by shared_ptr and weak_ptr. |
Add the following non-static member functions to
shared_ptr and weak_ptr class template;
// 20.9.11.2 paragraph 1 namespace std{ template<class T> class shared_ptr { public: ... size_t owner_hash() const; ... }; } // 20.9.11.3 paragraph 1 namespace std{ template<class T> class weak_ptr { public: ... size_t owner_hash() const; ... }; }These functions satisfy the following requirements. Let p and q be objects of either shared_ptr or weak_ptr, H be a hypothetical function object type that satisfies the hash requirements (20.2.4) and h be an object of the type H. The expression p.owner_hash() behaves as if it were equivalent to the expression h(p). In addition, h(p) == h(q) must become true if p and q share ownership. |
LWG | 1406 |
REJECTED
No consensus to make this change at this time. |
CH 20 | 20.9.11.2 ¶ p4 | Requiring shared_ptr and weak_ptr to always synchronize the use count makes it potentially slow and is inconsistent with the general approach to leave the synchronization to the user of a facility. | Strike 'not' from 'Changes in use_count() do not reflect modifications that can introduce data races.' Possibly add additional synchronized constructors and assignments. | LWG |
REJECTED
No consensus to make a change at this time. |
|
US 108 | 20.9.11.2.1 [util.smartptr.shared.const] | shared_ptr should have the same policy for constructing from auto_ptr as unique_ptr. Currently it does not. | Add “template <class Y> explicit shared_ptr(auto_ptr<Y>&); to [util.smartptr.shared.const] (and to the synopsis). | LWG | 1407 |
ACCEPTED with MODIFICATIONS
See paper N3109 |
US 109 | 20.9.11.2.6 | 20.9.11.2.6 [util.smartptr.shared.create]/2 says: "the placement new expression ::new (pv) T() or ::new (pv) T(std::forward<Args>(args)...)". It should simply say "the placement new expression ::new (pv) T(std::forward<Args>(args)...)", because empty parameter packs expand to nothing. This would be consistent with the requirements in paragraph 1. |
Change "the placement new expression ::new (pv) T() or ::new (pv) T(std::forward<Args>(args)...)" to "the placement new expression ::new (pv) T(std::forward<Args>(args)...)" |
editor | ACCEPTED | |
GB 103 | 20.9.12 ¶ 12 | The precondition to calling declare_no_pointers is that no bytes in the range "have been previously registered" with this call. As written, this precondition includes bytes in ranges, even after they have been explicitly unregistered with a later call to 'undeclare_no_pointers'. | Replace "have been previously registered" with "are currently registered" | LWG | 1408 | |
GB 106 | 20.10.3 | duration is an arithmetic type, unlike time_point, and so should provide a specialization of numeric_limits. |
Add a declaration of a partial specialization of
numeric_limits for duration to the header synopsis
in 20.10. Add 20.3.8 [time.duration.limits] "duration is an arithmetic type, and so provides an appropriate specialization of numeric_limits." |
LWG |
REJECTED
No consensus for a change. |
|
US 110 | 20.10.5 | Significant parts of the clock section are "unspecified", rather than "implementation-defined". | Make those parts "implementation-defined". | LWG |
REJECTED
No consensus to make a change. |
|
US 111 | 20.10.5.2 ¶ para 1 | What it means for monotonic_clock to be a synonym is undefined. If it may or may not be a typedef, then certain classes of programs become unportable. | Require that it be a distinct class type. | LWG | 1409 |
ACCEPTED with MODIFICATIONS
See paper N3191 |
GB 107 | 20.10.5.2 ¶ 2 | 1.4p9 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 std::chrono::monotonic_clock 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 implementationdefined semantics. | Provide feature test macro for determining the presence of std::chrono::monotonic_clock. Add _STDCPP_HAS_MONOTONIC_CLOCK to the <chrono> header, which is defined if monotonic_clock is present, and not defined if it is not present. | LWG | 1410 |
ACCEPTED with MODIFICATIONS
See paper N3191 |
DE 20 | 20.10.5.2 | The library component monotonic_clock is conditionally supported, but no compile-time flag exists that allows user-code to query its existence. Further-on there exist no portable means to simulate such a query. (To do so, user code would be required to add types to namespace std::chrono.) | Provide a compile-time flag (preferably a macro) that can be used to query the existence of monotonic_clock. | LWG | 1411 |
ACCEPTED with MODIFICATIONS
See paper N3191 |
CH 21 | 20.10.5.2 ¶ p2 | Monotonic clocks are generally easy to provide on all systems and are implicitely required by some of the library facilities anyway. | Make monotonic clocks mandatory, i.e. remove p2. Also change 30.2.4p2 accordingly. | LWG | 1412 |
ACCEPTED with MODIFICATIONS
See paper N3191 |
US 112 | 20.10.5.3 ¶ para 1 | What it means for high_resolution_clock to be a synonym is undefined. If it may or may not be a typedef, then certain classes of programs become unportable. | Require that it be a distinct class type. | LWG | 1413 | |
JP 39 | 21.2.2 ¶ 4 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(35)" to "(Table 35)". | editor | ACCEPTED | |
GB 108 | 21.2.3.1 ¶ 2,3 | The definition of streamoff/streampos defers to the definition of off_type and pos_type in 21.2.2, which defers back to 27.2.2 for the definition of streamoff/streampos. The actual definition appears to be supplied in 27.3, the synopsis of <iosfwd>. | Update the reference in 21.2.3.1 to refer forward to 27.2.2, rather than back to 21.2.2. Add a cross-reference to from 27.2.2 to 27.3. | editor | ||
GB 109 | 21.2.3.2/3/4 | 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. | Clarify the meaning of all cross-reference to the removed type POS_T. | LWG | 1414 | ACCEPTED with MODIFICATIONS |
JP 40 | 21.4 ¶ 3 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(96)" to "(Table 96)". | editor | ACCEPTED | |
GB 110 | 21.4.7.1 | data() is the function of choice for calling into legacy 'C'-like APIs. Both vector and array designed this function to be callable in a const-correct way while allowing for functions that want to use the result to designate a return buffer. |
Add the following overload to basic_string data():
charT * data();Relax the requirement that programs do not alter values in the array through the pointe retrieved through this new overload. |
LWG |
REJECTED
No consensus to make this change. |
|
GB 111 | 21.5 | Section 17.6.4.8, Data Race Avoidance, requires the C++ Standard Library to avoid data races that might otherwise result from two threads making calls to C++ Standard Library functions on distinct objects. The C standard library is part of the C++ Standard Library and some C++ Standary library functions (parts of the Localization library, as well as Numeric Conversions in 21.5), are specified to make use of the C standard library. Therefore, the C++ standard indirectly imposes a requirement on the thread safety of the C standard library. However, since the C standard does not address the concept of thread safety conforming C implementations exist that do no provide such guarantees. This conflict needs to be reconciled. | remove the requirement to make use of strtol() and sprintf() since these functions depend on the global C locale and thus cannot be made thread safe. | editor | ||
JP 86 | 21.7 ¶ 1 | Table numbers are listed incorrectly. "74,75. and" should be "74, 75, and". |
Correct typo as follows. Tables 71, 72, 73, 74, 75, and 76 describe |
editor | ACCEPTED | |
JP 87 | 22.3.1 | While usage of "traits" and "Traits" are explained in 21.2 as template parameters and arguments respectively, specifying "Traits" as template parameter seems misuse. template <class charT, class Traits, class Allocator> bool operator()(const basic_string<charT,Traits,Allocator>& s1, const basic_string<charT,Traits,Allocator>& s2) const; | Change "Traits" to "traits" in three places. | editor | ACCEPTED | |
JP 88 | 22.6 ¶ 3, Table 91 | Typo, duplicated "ispunct" and missing "iswpunct". |
Correct as follows. isprint ispunct isspace : iswprint iswpunct iswspace |
editor | ACCEPTED | |
JP 89 | 23.1 ¶ 2, Table 92 | Typo, "<forwardlist>" should be "<forward_list>". | Correct typo. <forward_list> | editor | ACCEPTED | |
US 113 | 23.2 ¶ 5 | Resolve LWG 579 one way or the other, but preferably in the direction of changing the two erase overloads to return void. | LWG |
REJECTED
No consensus for a change. |
||
US 114 | 23.2.1 ¶ Paragraph 9 | Requirements on iterators swapping allegiance would disallow the small-string optimization. | Add an exclusion for basic_string to the sentence beginning “Every iterator referring to an element...”. Add a sentence to 21.4.6.8/2 saying that iterators and references to string elements remain valid, but it is not specified whether they refer to the same string or the other string. | LWG |
ACCEPTED with MODIFICATIONS
See paper N3108 |
|
DE 21 | 23.2.1, 23.3.3.4 | 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. | Add a "Throws: Nothing" clause to both erase_after overloads in 23.3.3.4. | LWG | 1416 | ACCEPTED |
US 115 | 23.2.1 ¶ Paragraph 15 | The terms CopyConstructible, MoveConstructible, and constructible from are redefined, then used inconsistently and often incorrectly within the section. New terms should have been introduced and used correctly. | Better terms would be X can copy-insert T, X can move-insert T, and X can construct-insert T with args. See Appendix 1 - Additional Details | editor |
ACCEPTED with MODIFICATIONS
See paper N3173 |
|
US 116 | 23.2.1 ¶ Table 96 | The requirement for X(rv) that move construction of the allocator not throw can be misread as requiring that move construction of the whole container not throw. |
Add non-normative note: Requires: move construction of A shall not exit via an exception. [Note: This requirement on allocators exists so that implementations can (optionally) provide a nothrow guarantee on move construction of some containers. end note] |
editor |
REJECTED
The text as is seems quite clear; the proposed note just muddles things. |
|
FI 12 | 23.2.3 [sequence.reqmts] ¶ Table 97 Sequence container requirements (in addition to container) | The requirement for insert says: “Requires:T shall be CopyConstructible. For vector and deque, T shall also be CopyAssignable.”. Why must T be CopyAssignable? Is it for cases where the object may be already constructed and insert will first copy the existing data out of the way and assign to an existing object? Can't such an implementation do the same with placement-new? | CopyAssignable seems like an overly strict requirement for insert, exposing implementation details in the specification. If such implementation details are achievable without assignment, eg. with placement-new, the CopyAssignable requirement should be removed. | LWG |
REJECTED
No consensus to make the change. |
|
JP 90 | 23.2.3 ¶ 17, Table 98 | In Operational semantics for "a.emplace_front(args)", <Arg> should be <Args>. Prepends an object of type T constructed with std::forward<Arg>(args)...." | Change <Arg> to <Args>. | editor | ACCEPTED | |
JP 91 | 23.2.5 ¶ 10, Table 100 |
Typo, unnecessary new-line.
a_uniq. emplace(args) Typo, unnecessary space. a_eq. emplace(args) |
Remove space characters between "." and "emplace" same as other word wrapped columns in the table. | editor |
ACCEPTED with MODIFICATIONS
The newline is needed, but the space is unnecessary. Removed the space. |
|
JP 92 | 23.2.5 ¶ 11 | Typo, "unodified" should be "unmodified". | Correct typo. unmodified | editor | ACCEPTED | |
ES 2 | 23.2.5 [unord.req], Table 100 (Unordered associative container requirements (in addition to container)) ¶ Row for expression a.erase(q) | The expression is required to return the iterator immediately following q prior to the erasure. As explained in N2023, this requirement makes it impossible to achieve average O(1) complexity for unordered associative containers implemented with singly linked lists. This has a theoretical as well as a practical impact, as reported by users of early implementations of these containers. Discussions among committee members have not found any way of remedying this deficiency (other than acknowledging it) by some smart modification of usual singly linked lists implementations. | Change the return type of the expression from iterator to void. Eliminate the sentence “Return value is the iterator immediately following q prior to the erasure”. Change accordingly the appearances of “iterator erase(const_iterator position)” in 23.5.1, 23.5.2, 23.5.3 and 23.5.4. | LWG | REJECTED | |
GB 112 | 23.3.1.7 ¶ p3 | Should the effect of calling front/back on a zero sized array really be implementation defined i.e. require the implementor to define behaviour? | Change "implementation defined" to "undefined" | LWG | 1417 | ACCEPTED |
GB 113 | 23.3.2.2 ¶ p1 | There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitely. | Append "If sz == size(), does nothing" to the effects. | LWG | 1418 | |
US 117 | 23.3.3 | forward_list::erase_after should return an iterator. | See Appendix 1 - Additional Details | LWG | 1419 | ACCEPTED |
JP 41 | 23.3.3 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(table 93)" to "(Table 93)". | editor | ACCEPTED | |
GB 114 | 23.3.4.1 ¶ p11 & p12 | It looks like the erase/insert effects given in p11 are intended for p12. | Move the erase/insert effects down to p12 | editor |
ACCEPTED with MODIFICATIONS
The code in question is a remmant from a previous version. It has now been removed. |
|
GB 115 | 23.3.4.2 ¶ p1 | There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitly. | Express the semantics as pseudo-code similarly to the way it is done for the copying overload that follows (in p3). Include an else clause that does nothing and covers the sz==size() case. | LWG | 1420 | |
GB 116 | 23.3.5 | The sequence container adaptors consume sequence containers, but are neither containers nor sequences themselves. While they clearly belong in clause 23, they should not interrupt the presentation of the sequence container themselves. | Move clause 23.3.5 out of clause 23.3. Recommending inserting as a 'new' 23.4 immediately following sequence containers, and before the current 23.4 (associative containers) which would be renumbered 23.5. | editor | ACCEPTED | |
DE 22 | 23.3.5.1, 23.3.5.2, 23.3.5.3 | With the final acceptance of move operations as special members and introduction of corresponding suppression rules of implicitly generated copy operations the some library types that were copyable in C++03 are no longer copyable (only movable) in C++03, among them queue, priority_queue, and stack. | LWG | 1421 | ||
JP 93 | 23.3.5.2 ¶ 1 |
Typo, missing ";".
template <class... Args> void emplace(Args&&... args)n |
Correct typo.
template <class... Args> void emplace(Args&&... args); |
editor | ACCEPTED | |
GB 117 | 23.3.6.2 ¶ p9 | (Same as for 23.3.2.2p1 i.e. deque::resize). There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitely. | Append "If sz == size(), does nothing" to the effects. | editor | ||
GB 118 | 23.3.7 | vector<bool> iterators are not random access iterators because their reference type is a special class, and not 'bool &'. All standard libary operations taking iterators should treat this iterator as if it was a random access iterator, rather than a simple input iterator. | Either revise the iterator requirements to support proxy iterators (restoring functionality that was lost when the Concept facility was removed) or add an extra paragraph to the vector<bool> specification requiring the library to treat vector<bool> iterators as-if they were random access iterators, despite having the wrong reference type. | LWG | 1422 |
REJECTED
The LWG does not wish to address this problem at this time. The preference is to deal with it with the more general proxy iterator problem. |
JP 6 | 23.4.1 ¶ 2 |
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
namespace std { template <class Key, class T, class Compare = less<Key>, class Allocator = allocator<pair<const Key, T> > > class map { public: ... map(const Allocator&); |
Add explicit.
namespace std { template <class Key, class T, class Compare = less<Key>, class Allocator = allocator<pair<const Key, T> > > class map { public: ... explicit map(const Allocator&); |
LWG | 1423 | ACCEPTED |
JP 7 | 23.4.2 ¶ 2 | Constructor accepting an allocator as a single parameter should be qualified as explicit. |
Add explicit.
namespace std { template <class Key, class T, class Compare = less<Key>, class Allocator = allocator<pair<const Key, T> > > class multimap { public: ... explicit multimap(const Allocator&); |
LWG | ACCEPTED | |
JP 8 | 23.4.3 ¶ 2 | Constructor accepting an allocator as a single parameter should be qualified as explicit. |
Add explicit.
namespace std { template <class Key, class Compare = less<Key>, class Allocator = allocator<Key> > class set { public: ... explicit set(const Allocator&); |
LWG | 1425 | ACCEPTED |
JP 9 | 23.4.4 ¶ 2 | Constructor accepting an allocator as a single parameter should be qualified as explicit. |
Add explicit.
namespace std { template <class Key, class Compare = less<Key>, class Allocator = allocator<Key> > class multiset { public: ... explicit multiset(const Allocator&); |
LWG | 1426 | ACCEPTED |
US 118 | 23.5 | Some unordered associative container operations have undesirable complexities when the container is implemented using singly linked lists. | See Appendix 1 - Additional Details | LWG |
REJECTED
No consensus for a change. |
|
JP 10 | 23.5.1 ¶ 3 | Constructor accepting an allocator as a single parameter should be qualified as explicit. |
Add explicit.
namespace std { template <class Key, template <class Key, class T, class Hash = hash<Key>, class Pred = std::equal_to<Key>, class Alloc = std::allocator<std::pair<const Key, T> > > class unordered_map { public: ... explicit unordered_map(const Allocator&); |
LWG | 1427 | ACCEPTED |
JP 11 | 23.5.2 ¶ 3 | Constructor accepting an allocator as a single parameter should be qualified as explicit. |
Add explicit.
namespace std { template <class Key, class T, class Hash = hash<Key>, class Pred = std::equal_to<Key>, class Alloc = std::allocator<std::pair<const Key, T> > > class unordered_multimap { public: ... explicit unordered_multimap(const Allocator&); |
LWG | 1428 | ACCEPTED |
JP 94 | 23.5.2 ¶ 1 |
"see below" should be in italic and need one space
between words. explicit unordered_multimap(size_type n = seebelow, |
Change to: explicit unordered_multimap(size_type n = see below, |
editor | ACCEPTED | |
JP 12 | 23.5.3 ¶ 3 | Constructor accepting an allocator as a single parameter should be qualified as explicit. |
Add explicit.
namespace std { template <class Key, class Hash = hash<Key>, class Pred = std::equal_to<Key>, class Alloc = std::allocator<Key> > class unordered_set { public: ... explicit unordered_set(const Allocator&); |
LWG | 1429 | ACCEPTED |
JP 13 | 23.5.4 ¶ 3 | Constructor accepting an allocator as a single parameter should be qualified as explicit. |
Add explicit.
namespace std { template <class Key, class Hash = hash<Key>, class Pred = std::equal_to<Key>, class Alloc = std::allocator<Key> > class unordered_multiset { public: ... explicit unordered_multiset(const Allocator&); |
LWG | 1430 | ACCEPTED |
US 119 | [input.iterators] 24.2.3 ¶ Table 104 | Although the section talks about operator==, there is no requirement that it exist. | Add a == b to Table 104 | LWG |
REJECTED
Standard is correct as is. |
|
JP 42 | 25.1 ¶ 8, 9 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(4)" to "(Clause 4)". | editor | ACCEPTED | |
US 120 | 25.2.12 ¶ para 1 | 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. | Restrict is_permutation to the case where it is well specified. See Appendix 1 - Additional Details | LWG | 1431 | ACCEPTED |
ES 3 | 25.2.12 | is_permutation does not require ForwardIterator1 and ForwardIterator2 to have the same value type. This opens the door to nonsense heterogeneous usage where both ranges have different value types | Require both iterator types to have the same value type | LWG | ACCEPTED | |
JP 43 | 25.3.9 ¶ 5 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(4)" to "(Clause 4)". | editor | ACCEPTED | |
US 121 | 25.3.12 [alg.random.shuffle] ¶ 1 | random_shuffle and shuffle should be consistent in how they accept their source of randomness: either both by rvalue reference or both by lvalue reference. | Change random_shuffle to accept its RandomNumberGenerator by lvalue reference. | LWG | 1432 | ACCEPTED with MODIFICATIONS |
GB 119 | 25.3.12 | The functions random_shuffle and shuffle both take arguments providing a source of randomness, but one take its argument by rvalue reference, and the other requires an lvalue reference. The technical merits of which form of argument passing should be settled for this specific case, and a single preferred form used consistently. | [DEPENDS ON WHETHER RVALUE OR LVALUE REFERENCE IS THE PREFERRED FORM] | LWG | 1433 | ACCEPTED with MODIFICATIONS |
JP 44 | 25.4 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(4)" to "(Clause 4)". | editor | ACCEPTED | |
JP 45 | 25.4.7 ¶ 1, 10, 19 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(32)" to "(Table 32)". | editor | ACCEPTED | |
US 122 | 25.4.7 [alg.min.max] | It was the LWG's intent in Pittsburgh that N2772 be applied to the WP | Apply N2772 to the WP. | LWG | 1434 |
ACCEPTED with MODIFICATIONS
See paper N3106 |
US 123 | 25.5 ¶ p5b, and all uses of lshift | N3056, as adopted, calls for each use of lshift to be followed by a subscripted value. | Adjust all occurrences of the lshift notation so as to match the notation of N3056. | editor | ||
FI 14 | 26.3.1. ¶ 3 | typo | "floating-point environmnet" should be "floating-point environment." | editor | ACCEPTED | |
GB 120 | 26.4.7 | 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. | [ONE LINE DESCRIPTIONS, AND ASSOCIATED PARAGRAPH NUMBERS, TO FOLLOW IF THE INTENT IS APPROVED] | LWG | 1435 | ACCEPTED with MODIFICATIONS |
JP 46 | 26.5.1.6 ¶ 3 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "Clause 21 and 27" to "Clauses 21 and 27". | editor | ACCEPTED | |
GB 121 | 26.5.3 | 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. | [WORDING TO FOLLOW ONCE A PREFERRED DIRECTION IS INDICATED] | LWG | 1436 | ACCEPTED with MODIFICATIONS |
US 124 | 26.5.3.2 ¶ p4 | The Mersenne twister algorithm is meaningless for word sizes less than two, as there are then insufficient bits available to be “twisted”. | Insert the following among the relations that are required to hold: 2u < w. | LWG | 1437 | ACCEPTED |
US 125 | 26.5.4.1 [rand.adapt.disc] ¶ 3 | The synopsis for min() and max() is lacking “()” in the return statements. |
return Engine::min(); return Engine::max(); |
editor | ||
US 126 | 26.5.4.1 [rand.adapt.disc], 26.5.4.2 [rand.adapt.ibits], 26.5.4.3 [rand.adapt.shuf] ¶ 3 | Each adaptor has a member function called base() which has no definition. | Give it the obvious definition. | LWG | 1438 | |
US 127 | 26.5.4.1 ¶ synopsis after p3 | Engine::min is a function and ought be invoked in the context where mentioned, as should Engine::max. | Append parentheses so as to become return Engine::min() and return Engine::max(). | editor | ||
US 128 | 26.5.4.3 ¶ synopsis after p3 | Engine::min is a function and ought be invoked in the context where mentioned, as should Engine::max. | Append parentheses so as to become return Engine::min() and return Engine::max(). | editor | ||
US 129 | 26.5.7.1 ¶ p8b | The expression begin[x+q] is incorrect since x is unspecified . | Replace x by k so as to obtain begin[k+q]. | editor | ||
US 130 | 26.5.7.1 ¶ p8c | The phrase “three more times” is misleading. | s/three more times,/again,/ | editor | ||
US 131 | 26.5.7.1 ¶ p8c | Values r3 and r4 are correctly specified, but in their subsequent use they are interchanged with respect to the original algorithm by Mutso Saito. | Exchange subscripts so as to read as follows: “... update begin[k + p] by xoring it with r3, update begin[k + q] by xoring it with r4, and ...” | editor | ||
US 132 | 26.5.7.1 [rand.util.seedseq] ¶ 8b | The last sentence includes “begin[x + q]” but “x” is nonsensical here. | Change “begin[x + q]” to “begin[k + q]” | editor | ||
US 133 | 26.5.7.1 [rand.util.seedseq] ¶ 8c | The use of r3 and r4 is reversed in the final sentence of 8c according to the defect report on comp.std.c++ that this specification is based on: http://groups.google.com/group/comp.std.c++/browse_thre ad/thread/e34cbee1932efdb8/aad523dccec12aed?q=grou p:comp.std.c%2B%2B+insubject:seed_seq If you follow the SFMT link to the software, the software also uses r3 and r4 in a manner inconsistent with N3092. I believe N3092 should be changed to be consistent with the defect report. |
Change 8c to end: ... update begin[k + p] by xoring it with r3, update begin[k + q] by xoring it with r4, and ... |
editor | ||
US 134 | 26.5.8.5.2 [rand.dist.samp.pconst], 26.5.8.5.3 [rand.dist.samp.plinear] | These two distributions have a member function called densities() which returns a vector<double>. The distribution is templated on RealType. The distribution also has another member called intervals() which returns a vector<RealType>. Why doesn't densities return vector<RealType> as well? If RealType is long double, the computed densities property isn't being computed to the precision the client desires. If RealType is float, the densities vector is taking up twice as much space as the client desires. |
Change the piecewise constant and linear
distributions to hold / return the densities in a
vector<result_type>. If this is not done, at least correct[rand.dist.samp.pconst]/13 which describes the return of densities as a vector<result_type>. |
LWG | 1439 | ACCEPTED |
US 135 | 26.5.8.5.3 ¶ 10 | This paragraph says: Let bk = xmin+k·δ for k = 0,...,n, and wk = fw(bk +δ) 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. |
Change p10 to read: Let bk = xmin+k·δ for k = 0,...,n, and wk = fw(bk) for k = 0,...,n. |
LWG | 1440 | ACCEPTED |
JP 47 | 26.7.1 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table | Change "(35)" to "(Table 35)". | editor | ACCEPTED | |
JP 48 | 26.7.2 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(35)" to "(Table 35)". | editor | ACCEPTED | |
JP 49 | 26.7.4 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(36)" to "(Table 36)". | editor | ACCEPTED | |
US 136 | 26.8 | Floating-point test functions are incorrectly specified. | See Appendix 1 - Additional Details | LWG | 1441 | ACCEPTED |
CA 9 | 27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23 ¶ 27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23 |
Imposed happens-before edges should be in
synchronizes-with Each use of the words "happens-before" should be replaced with the words "synchronizes-with" in the following sentences: 27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23 Rationale: Happens-before is defined in 1.10p11 in a way that (deliberately) does not make it explicitly transitively closed. Adding edges to happens-before directly, as in 27.2.3p2 etc., does not provide transitivity with sequenced-before or any other existing happens-before edge. This lack of transitivity seems to be unintentional. |
Each use of the words "happens-before" should
be replaced with the words "synchronizes-with" in
the following sentences: 27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23 |
LWG | 1442 |
ACCEPTED
See paper N3196 |
GB 122 | 27, 30 | See (D) in attachment Appendix 1 - Additional Details | Request the concurrency working group to determine if changes are needed | LWG | 1442, 1443 | |
GB 123 | 27.5.3.2 ¶ Table 124 | Several rows in table 124 specify a Return type of 'OFF_T', which does not appear to be a type defined in this standard. | Resolve outstanding references to the removed type 'OFF_T'. | LWG | 1414, 1444 | ACCEPTED with MODIFICATIONS |
US 137 | 27.7 | Several iostreams member functions are incorrectly specified. | See Appendix 1 - Additional Details | LWG | 1445 |
ACCEPTED with MODIFICATIONS
See paper N3168 |
US 138 | 27.7 | For istreams and ostreams, the move-constructor does not move-construct, the move-assignment operator does not move-assign, and the swap function does not swap because these operations do not manage the rdbuf() pointer. Useful applications of these operations are prevented both by their incorrect semantics and because they are protected. | In short: reverse the resolution of issue 900, then change the semantics to move and swap the rdbuf() pointer. Add a new protected constructor that takes an rvalue reference to a stream and a pointer to a streambuf, a new protected assign() operator that takes the same arguments, and a new protected partial_swap() function that doesn't swap rdbuf(). See Appendix 1 - Additional Details | LWG | 1446 |
REJECTED
The Library Working Group reviewed n3179 and concluded that this change alone was not sufficient, as it would require changes to some of the derived stream types in the library. The preference is not make such a broad fix, and retain the current semnatic. This is closed as NAD rather than NAD future as it will be difficult to rename the new functions introduced in the C++0x revision of the standard at a later date. See paper N3179 |
US 139 | 27.7 ¶ 1.1.3 | 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. | LWG | 1447 |
ACCEPTED with MODIFICATIONS
See paper N3168 |
|
US 140 | 27.8 | It should be possible to construct a stringstream with a specific allocator. | Add an allocator_type and overloaded constructors that take an Allocator argument to basic_stringbuf, basic_istringstream, basic_ostringstream, and basic_stringstream. The semantics of allocator propagation should be the same as if the stringbuf contained an embedded basic_string using the same allocator. | LWG |
REJECTED
No consensus for a change at this time. |
|
GB 124 | 27.8.1.3 ¶ 3 |
N3092 27.8.1.3 Member functions contains this text
specifying the postconditions of
basic_stringbuf::str(basic_string): "Postconditions: If mode & ios_base::out is true, pbase() points to the first underlying character and epptr() >= pbase() + s.size() holds; in addition, if mode & ios_base::in is true, pptr() == pbase() + s.data() holds, otherwise pptr() == pbase() is true. [...]" Firstly, there's a simple mistake: It should be pbase() + s.length(), not pbase() + s.data(). Secondly, it doesn't match existing implementations. As far as I can tell, GCC 4.5 does not test for mode & ios_base::in in the second part of that sentence, but for mode & (ios_base::app | ios_base_ate), and Visual C++ 9 for mode & ios_base::app. Besides, the wording of the C++0x draft doesn't make any sense to me. I suggest changing the second part of the sentence to one of the following: Replace ios_base::in with (ios_base::ate | ios_base::app), but this would require Visual C++ to change (replacing only with ios_base::ate would require GCC to change, and would make ios_base::app completely useless with stringstreams): in addition, if mode & (ios_base::ate | ios_base::app) is true, pptr() == pbase() + s.length() holds, otherwise pptr() == pbase() is true. Leave pptr() unspecified if mode & ios_base::app, but not mode & ios_base::ate (implementations already differ in this case, and it's always possible to use ios_base::ate to get the effect of appending, so it's not necessary to require any implementation to change): in addition, if mode & ios_base::ate is true, pptr() == pbase() + s.length() holds, if neither mode & ios_base::ate nor mode & ios_base::app is true, pptr() == pbase() holds, otherwise pptr() >= pbase() && pptr() <= pbase() + s.length() (which of the values in this range is unspecified). Slightly stricter: in addition, if mode & ios_base::ate is true, pptr() == pbase() + s.length() holds, if neither mode & ios_base::ate nor mode & ios_base::app is true, pptr() == pbase() holds, otherwise pptr() == pbase() || pptr() == pbase() + s.length() (which of these two values is unspecified). A small table might help to better explain the three cases. BTW, at the end of the postconditions is this text: "egptr() == eback() + s.size() hold". Is there a perference for basic_string::length or basic_string::size? It doesn't really matter, but it looks a bit inconsistent. |
LWG | 1448 | ||
CA 4 | 27.8.2 ¶ various | Subclause 27.9.2 [c.files] specifies that <cinttypes> 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 <cinttypes>. 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, <cinttypes> is not specified in FCD to include <cstdint> (whereas <inttypes.h> includes <stdint.h> in C). | Please clarify. | LWG | 1449 | ACCEPTED with MODIFICATIONS |
JP 14 | 28.4 |
Support of char16_t/char32_t is insufficient. The <regex>
does not have typedefs for char16_t/char32_t. The reason we need this typedefs is, because anybody may define exactly same type with different typedef names. Doesn't <locale> offer enough operations which is required by regex implementation? |
Add typedefs below
typedef basic_regex<char16_t> u16regex; typedef basic_regex<char32_t> u32regex; |
LWG |
REJECTED
No consensus to make a change at this time. |
|
GB 127 | 28.5.2 | The Bitmask Type requirements in 17.5.2.1.3 p3 say that all elements on a bitmask type have distinct values, but 28.5.2 defines regex_constants::match_default and regex_constants::format_default as elements of the bitmask type regex_constants::match-flag_type, both with value 0. This is a contradiction. | One of the bitmask elements should be removed from the declaration and should be defined separately, in the same manner as ios_base::adjustfield, ios_base::basefield and ios_base::floatfield are defined by 27.5.2.1.2p2 and Table 120. These are constants of a bitmask type, but are not distinct elements, they have more than one value set in the bitmask. regex_constants::format_default should be specified as a constant with the same value as regex_constants::match_default. | LWG | 1450 | |
JP 50 | 28.5.2 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "table 136" to "Table 136". | editor | ACCEPTED | |
JP 51 | 28.5.3 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "table 137" to "Table 137". | editor | ACCEPTED | |
US 141 | 28.8 | std::basic_regex should have an allocator for all the reasons that a std::string does. For example, I can use boost::interprocess to put a string or vector in shared memory, but not a regex. | Add allocators to regexes | LWG | 1451 | |
GB 125 | 28.10.3 ¶ 2 | The term "target sequence" is not defined. | Replace "target sequence" with "string being searched/matched" | LWG | 1452 | |
GB 126 | 28.10.3 | 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. |
Add to match_results::operator[],
match_results::prefix and match_results::suffix: Requires: !empty() |
LWG | 1453 |
ACCEPTED with MODIFICATIONS
See paper N3158 |
JP 52 | 28.11.2 ¶ 3 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "table 139" to "Table 139". | editor | ACCEPTED | |
JP 95 | 28.11.3 ¶ 1 | The section number "(24.1.4)" for "Bidirectional Iterator" is wrong. The correct one is "(24.2.6)". In addition, it is written as normal text, but it should be embedded as a link to the section. | Change "(24.1.4)" to "(24.2.6)" and make it a link to section (24.2.6). | editor | ACCEPTED | |
JP 53 | 28.11.3 ¶ 3 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "table 140" to "Table 140". | editor | ACCEPTED | |
JP 54 | 28.13 ¶ 6 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "table 135" to "Table 135". | editor | ACCEPTED | |
GB 128 | 29 | WG14 has made some late changes to their specification of atomics, and care should be taken to ensure that we retain a common subset of language/library syntax to declare headers that are portable to both languages. Ideally, such headers would not require users to define their own macros, especially not macros that map to keywords (which remains undefined behaviour) | Depends on result of the review of WG14 work, which is expected to be out to ballot during the time wg21 is resolving its own ballot comments. Liaison may also want to file comments in WG14 to ensure compatibity from both sides. | LWG | 1455, 1454 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
CH 22 | 29 | WG14 currently plans to introduce atomic facilities that are intended to be compatible with the facilities of clause 29. They should be compatible. | Make sure the headers in clause 29 are defined in a way that is compatible with the planned C standard. | LWG | 1455, 1454 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
GB 129 | 29 ¶ Table 143 | Table 143 lists the typedefs for various atomic types corresponding to the various standard integer typedefs, such as atomic_int_least8_t for int_least8_t, and atomic_uint_fast64_t for uint_fast64_t. However, there are no atomic typedefs corresponding to the fixed-size standard typedefs int8_t, int16_t, and so forth. |
Add the following entries to table 143: atomic_int8_t => int8_t (optional), atomic_int16_t => int16_t (optional), atomic_int32_t => int32_t (optional), atomic_int64_t => int64_t (optional), atomic_uint8_t => uint8_t (optional), atomic_uint16_t => uint16_t (optional), atomic_uint32_t => uint32_t (optional), atomic_uint64_t => uint64_t (optional) These typedefs should be available if the corresponding typedefs from are available. |
LWG | 1456 | |
CA 16 | 29.1p1 29.3p8 ¶ 29.1p1 footnote 343 29.3p8 footnote 344 |
Radioactivity Footnotes 343 and 344 from 29.1p1 and 29.3p8 read: "Atomic objects are neither active nor radioactive" and "Among other implications, atomic variables shall not decay". We suggest that these be removed - the first is pretty clearly a joke, but it's not obvious that the second doesn't have some technical meaning. |
Footnotes 343 and 344 from 29.1p1 and 29.3p8 should be removed. | editor | ACCEPTED | |
US 142 | 29.1 ¶ P2 table 141 | Missing 29.8 Fences | Add 29.8 Fences | editor | ACCEPTED | |
US 143 | [atomics.syn] 29.2 ¶ before 1 | There is no free function atomic_compare_exchange_strong for volatile atomic integral types; there is one for non-volatile types. | Add atomic_compare_exchange_strong for volatile integral types to the synopsis. | editor | ACCEPTED | |
US 144 | [atomics.syn] 29.2 ¶ before 1 | The synopsis lists the macros ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE; the Lock-free Property requirements don't have ATOMIC_INTEGRAL_LOCK_FREE, but have 8 macros for the various integral types. | Change 29.2 [atomics.syn] to match 29.4 [atomics.lockfree]. | editor | ACCEPTED | |
US 145 | 29.2 |
missing atomic_compare_exchange_strong(volatile ....)
and atomic_compare)exchange_strong_explict( ...//no
volatile *? > bool atomic_compare_exchange_weak(volatile atomic_itype*, integral*, integral); > bool atomic_compare_exchange_weak(atomic_itype*, integral*, integral); > bool atomic_compare_exchange_strong(atomic_itype*, integral*, integral); > bool atomic_compare_exchange_weak_explicit(volatile atomic_itype*, integral*, > integral, memory_order, memory_order); > bool atomic_compare_exchange_weak_explicit(atomic_itype*, integral*, > integral, memory_order, memory_order); > bool atomic_compare_exchange_strong_explicit(volatile atomic_itype*, integral*, > integral, memory_order, memory_order); |
Repair as suggested | editor | ACCEPTED | |
GB 130 | 29.2 | The synopsis for the <atomic> header lists the macros ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE. The ATOMIC_INTEGRAL_LOCK_FREE macro has been replaced with a set of macros for each integral type, as listed in 29.4 |
Replace "#define
ATOMIC_INTEGRAL_LOCK_FREE unspecified"
with
#define ATOMIC_CHAR_LOCK_FREE implementation-defined #define ATOMIC_CHAR16_T_LOCK_FREE implementation-defined #define ATOMIC_CHAR32_T_LOCK_FREE implementation-defined #define ATOMIC_WCHAR_T_LOCK_FREE implementation-defined #define ATOMIC_SHORT_LOCK_FREE implementation-defined #define ATOMIC_INT_LOCK_FREE implementation-defined #define ATOMIC_LONG_LOCK_FREE implementation-defined #define ATOMIC_LLONG_LOCK_FREE implementation-defined |
LWG | 1457 | |
US 146 | 29.2 ¶ syn 29.4 | The ATOMIC_..._LOCK_FREE macros have not had changes applied. | Change to match 29.4/0. | editor | ACCEPTED | |
US 147 | 29.2 ¶ syn 29.7 | The declaration of ATOMIC_VAR_INIT should be referenced to section 29.6 [atomics.types.operations], not 29.7. | Change it to 29.6. | editor | ACCEPTED | |
US 148 | 29.2 ¶ syn 29.7 | The definition of ATOMIC_VAR_INIT should be 'implementation defined' rather than 'see below'. | Change it to 'implementation defined'. | editor |
REJECTED
No, definitely not implementation defined. "See below "is correct. |
|
US 149 | 29.2 ¶ syn 29.5.1 | The synopsis is missing the atomic_init function declarations for the bool, integral and address types. | Copy them from 29.5.1. | editor | ACCEPTED | |
US 150 | 29.2 ¶ syn 29.5.1 | There are missing function prototypes bool atomic_compare_exchange_strong(volatile atomic_itype*, integral*, integral); and integral atomic_fetch_add(volatile atomic_itype*, integral); | Add them. | editor | ACCEPTED | |
US 151 | 29.2 ¶ syn 29.5.1 | There is a duplicate function declaration of integral atomic_fetch_or(volatile atomic_itype*, integral); | Remove the volatile qualifier from the second declaration. | editor | ACCEPTED | |
US 152 | 29.3 ¶ para 1 | The table shows no disinct meaning for memory_order_seq_cst. | Add another bullet: "- memory_order_seq_cst: See below." | editor |
REJECTED
It's named in the second and fourth bullet items. |
|
GB 131 | 29.3 ¶ 8 | See (H) in attachment Appendix 1 - Additional Details | Request the concurrency working group to determine if changes are needed. Consider changing the use of "sequence" in 29.3 | LWG | 1458 | |
CA 21 | 9.3p8 1.9p13 ¶ 29.3p8 1.9p13 |
Overlapping evaluations are allowed 29.3p8 states: "An atomic store shall only store a value that has been computed from constants and program input values by a finite sequence of program evaluations, such that each evaluation observes the values of variables as computed by the last prior assignment in the sequence." ... but 1.9p13 states: "If A is not sequenced before B and B is not sequenced before A, then A and B are unsequenced. [ Note: The execution of unsequenced evaluations can overlap. -end note ]" Overlapping executions can make it impossible to construct the sequence described in 29.3p8. We are not sure of the intention here and do not offer a suggestion for change, but note that 29.3p8 is the condition that prevents out-of-thin-air reads. For an example, suppose we have a function invocation f(e1,e2). The evaluations of e1 and e2 can overlap. Suppose that the evaluation of e1 writes y and reads x whereas the evaluation of e2 reads y and writes x, with reads-from edges as below (all this is within a single thread). e1 e2 Wrlx y-- --Wrlx x rf\ /rf X / \ Rrlx x<- ->Rrlx yThis seems like it should be allowed, but there seems to be no way to produce a sequence of evaluations with the property above. In more detail, here the two evaluations, e1 and e2, are being executed as the arguments of a function and are consequently not sequenced-before each other. In practice we'd expect that they could overlap (as allowed by 1.9p13), with the two writes taking effect before the two reads. However, if we have to construct a linear order of evaluations, as in 29.3p8, then the execution above is not permited. Is that really intended? |
Please clarify. | LWG | 1459 | |
US 153 | [atomics.lockfree] 29.4 ¶ before 1 | The macros are all specified as "implementation-deifned"; they should be "see below", since the required values are spelled out. | Change the definitions of the macros in 29.4 [atomics.lockfree] from "implementation-defined" to "see below". | editor |
REJECTED
Implementation defined requires that the implementation document what it does. Removing this requirement would be a technical change. |
|
US 154 | [atomics.lockfree] 29.4 ¶ before 1 | There is no ATOMIC_BOOL_LOCK_FREE macro. | Add ATOMIC_BOOL_LOCK_FREE to 29.4 [atomics.lockfree] and to 29.2 [atomics.syn] | LWG | 1460 | |
US 155 | 29.4 ¶ para 3 | The 'via' 'by' word pairing is awkward. | Replace 'by' with 'via' in 'communication via memory ... and by memory'. | editor | ACCEPTED | |
CA 1 | 29.4, 29.6 29.7 ¶ various | All ATOMIC_... macros should be prefixed with STD_ as in STD_ATOMIC_... to indicate they are STD macros as other standard macros. The rationale that they all seem too long seems weak. |
This covers the following macros which we
suggest prepending with STD_: 29.4: #define ATOMIC_CHAR_LOCK_FREE implementation-defined #define ATOMIC_CHAR16_T_LOCK_FREE implementation-defined #define ATOMIC_CHAR32_T_LOCK_FREE implementation-defined #define ATOMIC_WCHAR_T_LOCK_FREE implementation-defined #define ATOMIC_SHORT_LOCK_FREE implementation-defined #define ATOMIC_INT_LOCK_FREE implementation-defined #define ATOMIC_LONG_LOCK_FREE implementation-defined #define ATOMIC_LLONG_LOCK_FREE implementation-defined #define ATOMIC_ADDRESS_LOCK_FREE implementation-defined 29.6: #define ATOMIC_VAR_INIT(value) see below 29.7: #define ATOMIC_FLAG_INIT see below |
LWG | 1461 | |
US 156 | [atomics.types.integral] 29.5.1 ¶ before 1 | The list of member functions for atomic_bool has four versions of compare_exchange_weak taking one memory_order argument; the last two should be compare_exchange_strong. | Change the last two member functions comapare_exchange_weak taking two memory_order arguments to compare_exchange_strong. | editor | ACCEPTED | |
JP 55 | 29.5.1 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "table 142" to "Table 142". | editor | ACCEPTED | |
GB 132 | 29.5.1 |
The atomic_itype types and atomic_address have two
overloads of operator= --- one is volatile qualified, and the
other is not. atomic_bool only has the volatile qualified
version: bool operator=(bool) volatile; On a non-volatile-qualified object this is ambiguous with the deleted copy-assignment operator atomic_bool& operator=(atomic_bool const&) = delete; due to the need for a single standard conversion in each case when assigning a bool to an atomic_bool as in: atomic_bool b; b=true;The conversions are atomic_bool& -> atomic_bool volatile& vs bool -> atomic_bool |
Add the "bool operator=(bool);" overload to atomic_bool in 29.5.1 | LWG | 1462 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
US 157 | [atomics.types.integral] 29.5.1 ¶ before 1 | atomic_bool has a volatile assignment operator but not a non-volatile operator The other integral types have both.. | Add a non-volatile assignment operator to atomic_bool. | LWG | 1463 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
US 158 | 29.5.1 ¶ para 0 | There is a space before the second & in the declaration atomic_itype& operator=(const atomic_itype &) = delete; | Remove the space. | editor | ACCEPTED | |
US 159 | 29.5.1 |
Last 2 should be compare_exchane_strong > bool compare_exchange_weak(bool&, bool, memory_order, memory_order) volatile; > bool compare_exchange_weak(bool&, bool, memory_order, memory_order); > bool compare_exchange_strong(bool&, bool, memory_order, memory_order) volatile; > bool compare_exchange_strong(bool&, bool, memory_order, memory_order); > bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst) volatile; > bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst); > bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst) volatile; > bool compare_exchange_weak(bool&, bool, memory_order = memory_order_seq_cst); |
Fix last 2 | editor | ACCEPTED | |
US 160 | [atomic.types.integral] 29.5.1 ¶ 1 | The last sentence of 29.5.1 [atomics.types.integral]/1 says "Table 143 shows typedefs to atomic integral classes and the corresponding typedefs." That's nice, but nothing says these are supposed to be part of the implementation, and they are not listed in the synopsis. | Remove Table 143 and the last sentence of 29.5.1 [atomics.types.integral]/1. | LWG | 1464 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
US 161 | [atomic.types.address] 29.5.2 ¶ before 1 | atomic_address has operator+= and operator-=, but no operator++ or operator--. The template specialization atomic<Ty*> has all of them. | Add operator++(int) volatile, operator++(int), operator++() volatile, operator++(), operator--(int) volatile, operator--(int), operator--() volatile, and operator--() to atomic_address. | LWG | 1465 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
US 162 | [atomics.typres.address] 29.5.2 | The compare_exchange_weak and compare_exchange_strong member functions that take const void* arguments lead to a silent removal of const, because the load member function and other acessors return the stored value as a void*. | Remove the const void* overloads of compare_exchange_weak and compare_exchange_strong | LWG | 1466 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
US 163 | [atomics.type.address], [atomics.types.generic] 29.5.2, 29.5.3 |
Requiring atomic<Ty*> to be derived from atomic_address
breaks type safety:
atomic<double*> ip; char ch; atomic_store(&ip, &ch); *ip.load() = 3.14159;The last line overwrites ch with a value of type double |
Remove the requirement that atomic<Ty*> be derived from atomic_address. | LWG | 1467 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
US 164 | [atomics.types.address] 29.5.2 ¶ before 1 | atomic_address has member functions compare_exchange_weak and compare_exchange_strong that take arguments of type const void*, in addition to the void* versions. If these member functions survive, there should be corresponding free functions. | Add atomic_compare_exchange_weak and atomic_compare_exchange_strong free functions taking pointers to volatile and non-volatile atomic_address objects and const void* arguments. | LWG | 1468 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
JP 56 | 29.5.3 ¶ 3 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "table 142 or table 143" to "Table 142 or Table 143". | editor | ACCEPTED | |
GB 133 | 29.5.3 |
The free functions that operate on atomic_address can be
used to store a pointer to an unrelated type in an
atomic<T*> without a cast. e.g.
int i; atomic<int*> ai(&i); string s; atomic_store(&ai,&s); |
Overload the atomic_store, atomic_exchange and
atomic_compare_exchange_[weak/strong]
operations for atomic<T*> to allow storing only
pointers to T:
template<typename T> void atomic_store(atomic<T*>&,T*); template<typename T> void atomic_store(atomic<T*>&,void*) = delete; template<typename T> void atomic_store_explicit(atomic<T*>&,T*,memory_or der); template<typename T> void atomic_store_explicit(atomic<T*>&,void*,memory _order) = delete; template<typename T> T* atomic_exchange(atomic<T*>&,T*); template<typename T> T* atomic_exchange(atomic<T*>&,void*) = delete; template<typename T> T* atomic_exchange_explicit(atomic<T*>&,T*,memor y_order); template<typename T> T* atomic_exchange_explicit(atomic<T*>&,void*,me mory_order) = delete; template<typename T> T* atomic_compare_exchange_weak(atomic<T*>&,T **,T*); template<typename T> T* atomic_compare_exchange_weak(atomic<T*>&,v oid**,void*) = delete; template<typename T> T* atomic_compare_exchange_weak_explicit(atomic <T*>&,T**,T*,memory_order); template<typename T> T* atomic_compare_exchange_weak_explicit(atomic <T*>&,void**,void*,memory_order) = delete; template<typename T> T* atomic_compare_exchange_strong(atomic<T*>&, T**,T*); template<typename T> T* atomic_compare_exchange_strong(atomic<T*>&, void**,void*) = delete; template<typename T> T* atomic_compare_exchange_strong_explicit(atomi c<T*>&,T**,T*,memory_order); template<typename T> T* atomic_compare_exchange_strong_explicit(atomi c<T*>&,void**,void*,memory_order) = delete; |
LWG | 1469 |
ACCEPTED with MODIFICATIONS
See paper N3193 |
US 165 | 29.5.3 ¶ Paragraph 23 | “is the same that same as that of” is not grammatical (and is not clear) | LWG | 1470 | ||
US 166 | 29.6 ¶ para 2 | The first three bullets seem to be missing terminal punctuation. | Add semicolons to ends of the bullets. | editor | ACCEPTED | |
US 167 | 29.6 ¶ para 3 | The first three bullets seem to be missing terminal punctuation. | Add semicolons to ends of the bullets. | editor |
REJECTED
Seems to be a duplicate of US 166 but with the wrong section number. |
|
US 168 | 29.6 ¶ para 4 | The definition of the default constructor needs exposition. | Add a new paragraph: A::A() = default; Effects: Leaves the atomic object in an uninitialized state. [Note: These semantics ensure compatiblity with C. --end note] | LWG | 1471 |
ACCEPTED
See paper N3196 |
US 169 | 29.6 ¶ para 5 | The definition of ATOMIC_VAR_INIT should be 'implementation defined' rather than 'see below'. | Change it to 'implementation defined'. | editor |
REJECTED
No, we should not require implementors to document the details of how they do this. |
|
US 170 | 29.6 ¶ para 6 | The definition of atomic_init should be grouped with the value constructor. | Move the atomic_init definition to just after the constructor definition. | editor |
REJECTED
The current order reflects the order of declarations. No need to change it. |
|
GB 134 | 29.6 ¶ 5 | Some of the declarations of is_lock_free seem to be missing return types. |
Replace: A::is_lock_free() const volatile; A::is_lock_free() const; With: bool A::is_lock_free() const volatile; bool A::is_lock_free() const; |
editor | ACCEPTED | |
US 171 | 29.6 ¶ para 6 | The atomic_init definition "Non-atomically assigns the value" is not quite correct, as the atomic_init purpose is initialization. | Change "Non-atomically assigns the value desired to *object." with "Initializes *object with value desired". Add the note: "[Note: This function should only be applied to objects that have been default constructed. These semantics ensure compatibility with C. --end note]" | LWG | 1472 |
ACCEPTED
See paper N3196 |
US 172 | 29.6 ¶ para 9, 13, 17, 20 | The order specifications are incomplete because the non-_explicit functions do not have such parameters. | Add a new sentence: "If the program does not specify an order, it shall be memory_order_seq_cst." Or perhaps: "The non-_explicit non-member functions shall affect memory as though they were _explicit with memory_order_seq_cst." | LWG | 1473 |
REJECTED
The Concurrency subgroup reviewed this, and deemed it NAD according to 29.6 [atomics.types.operations] paragraph 2, bullet 4. |
US 173 | 29.6 ¶ para 20 | Misspelling. | Replace "operations ate atomic" with "operations are atomic". | editor | ACCEPTED | |
US 174 | 29.6 ¶ para 22 | The first note is about effects, not returns. | Move this note to just after the Effects paragraph. | editor |
REJECTED
This would require a significant rewrite, because the Returns clause refers to the "result of the comparison" from the Effects clause. Okay as written. |
|
US 175 | 29.6 ¶ para 23 | The first sentence is grammatically incorrect. | Replace the sentence with two: "The weak compare-and-exchange operations may fail spuriously. That is, it may return false while leaving the contents of memory pointed to by expected the same as it was before the operation." | LWG | 1474 | |
CH 23 | 29.6 ¶ p23 | The first sentence has non-English syntax. | Change to "The weak compare-and-exchange operations may fail spuriously, that is, return false while leaving the contents of memory pointed to by expected unchanged." | LWG | 1475 | |
US 176 | 29.6 ¶ para 23 | Unintended paragraph break. | Proposal: Remove the paragraph break between "will be in a loop." and "When a compare-andexchange is in a loop,". | editor |
REJECTED
Okay as written. Two different subjects, two paragraphs. |
|
US 177 | [atomics.types.operations] 29.6 ¶ 23 | The first sentence of this paragraph doesn't make sense. | Figure out what it's supposed to say, and say it. | LWG | 1476 | |
GB 135 | 29.6 ¶ 23 | The first sentence of 29.6p23 was changed by n2992 but now makes no sense: "that is, return false while leaving the contents of memory pointed to by expected before the operation is the same that same as that of the object and the same as that of expected after the operation." There's a minor editorial difference between n2992 ("is that same as that" vs "is the same that same as that") but neither version makes sense. Also, the remark talks about "object" which should probably be "object or this" to cover the member functions which have no object parameter. | Fix the Remark to say whatever was intended. | LWG | 1477 | |
GB 136 | 29.6 | See (K) in attachment Appendix 1 - Additional Details | GB requests normative clarification in 29.6p4 that concurrent access constitutes a race, as already done on p6 and p7. | LWG | 1478 | |
US 178 | 29.7 ¶ para 7 | The sentence "The order argument shall not be memory_order_acquire nor memory_order_acq_rel." is awkwardly phrased. | Change the sentence to "The order argument shall be neither memory_order_acquire nor memory_order_acq_rel." | editor |
ACCEPTED with MODIFICATIONS
Changed "nor" to "or". |
|
US 179 | 29.8 ¶ para 5, 6 | The fence functions should be extern "C", for C compatibility. | Add extern "C" to their declarations in 29.8 and in 29.2. | LWG | 1479 | |
GB 137 | 29.8 ¶ 6 | Thread fence not only establish synchronizes with relationships, there are semantics of fences that are expressed not in terms of synchronizes with relationships (for example see 29.3p5). These semantics also need to apply to the use of atomic_signal_fence in a restricted way. | Change 29.8p6 to "Effects: equivalent to atomic_thread_fence(order), except that the resulting ordering constraints are established only between a thread and a signal handler executed in the same thread." | LWG | 1480 | |
US 180 | 30.1 ¶ para 1 | The introductory sentence is missing futures. | Replace "communicate conditions between threads" with "communicate conditions and values between threads". | editor | ACCEPTED | |
GB 138 | 30.2 | The FCD combines the requirements for lockable objects with those for the standard mutex objects. These should be separate. This is LWG issue 1268. | See attached Appendix 1 - Additional Details | LWG | 1481 |
ACCEPTED with MODIFICATIONS
See paper N3197 |
US 181 | 30.2.4 ¶ para 2 | The timeout operations are under-specified. | Define precise semantics for timeout_until and timeout_for. See Appendix 1 - Additional Details | LWG | 1482 |
ACCEPTED with MODIFICATIONS
See paper N3191 |
US 182 | [thread.req.native] 30.2.3 | native_handle and native-handle_type should be removed. It is implementation-defined whether these names are present in the various thread support classes, and if present, it is implementation-defined what the name native_handle_type refers to. This is exactly what the implementor namespace is for. There is no benefit to programmers from providing a way to portably detect that an implementation provides non-portable extensions. The standard should not reserve these names, with unspecified semantics; it if does, the names will never become portable because implementations will differ on what they mean. | Remove [thread.req.native] 30.2.3 and remove all mentions of native_handle and native_handle_type. | LWG |
REJECTED
No consensus to make a change at this time. |
|
DE 23 | 30.3 | Predefined macros usually start and end with two underscores, see 16.8 and FDIS 29124 = WG21 N3060 clause 7. __STDCPP_THREADS should blend in. | Change the macro name to __STDCPP_THREADS__. | LWG | 1483 | ACCEPTED |
US 183 | 30.3.1 | There is no way to join a thread with a timeout. | Add join_for and join_until. Or decide one should never join a thread with a timeout since pthread_join doesn't have a timeout version. | LWG | 1484 |
REJECTED
The concurrency working group deemed this an extension beyond the scope of C++0x. |
US 184 | 30.3.1.1 ¶ para 2 | It is unclear when a thread::id ceases to be meaningful. The sentence "The library may reuse the value of a thread::id of a terminated thread that can no longer be joined." implies that some terminated threads can be joined. It says nothing about detached threads. | Require a unique thread::id for every thread that is (1) detached and not terminated or (2) has an associated std::thread object. | LWG | 1485 | |
JP 97 | 30.3.1.5 ¶ 9 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
JP 98 | 30.3.1.5 ¶ 14 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
CH 24 | 30.3.2 ¶ p1 | What would be the value this_thread::get_id() when called from a detached thread? | Add some text to clarify that get_id() still returns the same value even after detaching. | LWG | 1486 | |
CH 25 | 30.3.2 ¶ p8 and p11 | Clock related operations are currently not required not to throw. So "Throws: Nothing." is not always true. | Either require clock related operations not to throw (in 20.10) or change the Throws clauses in 30.3.2. Also possibly add a note that abs_time in the past or negative rel_time is allowed. | LWG | 1487 | |
US 185 | 30.4 | Cooperate with WG14 to improve interoperability between the C++0x and C1x threads APIs. In particular, C1x mutexes should be conveniently usable with a C++0x lock_guard. Performance overheads for this combination should be considered. | Remove C++0x timed_mutex and timed_recursive_mutex if that facilitates development of more compatible APIs. | LWG | 1488 |
REJECTED
The concurrency group reviewed the options, and decided that closer harmony should wait until both standards are published. |
CH 26 | 30.4 | Specifications of unlock member functions and unlock mutex requirements are inconsistent wrt to exceptions and pre- and postconditions. | unlock should specifiy the precondition that the current thread "owns the lock", this will make calls without holding the locks "undefined behavior". unlock in [mutex.requirements] should either be noexcept(true) or be allowed to throw system_error like unique_lock::unlock, or the latter should be nothrow(true) and have the precondition owns==true. Furthermore unique_lock's postcondition is wrong in the case of a recursive mutex where owns might stay true, when it is not the last unlock needed to be called. | LWG | 1489 |
ACCEPTED with MODIFICATIONS
See paper N3197 |
CH 27 | 30.4.1 ¶ p18 | The mutex requirements force try_lock to be noexcept(true). However, where they are used by the generic algorithms, those relax this requirement and say that try_lock may throw. This means the requirement is too stringent, also a non-throwing try_lock does not allow for a diagnostic such as system_error that lock() will give us. | delete p18, adjust 30.4.4 p1 and p4 accordingly | LWG | 1490 |
ACCEPTED with MODIFICATIONS
See paper N3197 |
JP 99 | 30.4.1 ¶ 11 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
US 186 | 30.4.1 ¶ 14 | try_lock does not provide a guarantee of forward progress because it is allowed to spuriously fail. | The standard mutex types must not fail spuriously in try_lock. See Appendix 1 - Additional Details | LWG | 1491 |
ACCEPTED with MODIFICATIONS
See paper N3209 |
US 187 | 30.4.1 ¶ 14 | Paragraph mentions compare_exchange, which no longer exists. | Change “compare_exchange” to “compare_exchange_weak”. | editor |
ACCEPTED with MODIFICATIONS
Changed compare_exchange to "compare and exchange". |
|
JP 57 | 30.4.1 ¶ 14 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(29)" to "(Clause 29)". | editor | ACCEPTED | |
US 188 | 30.4.1 ¶ 20, 21 | Mutex requirements should not be bound to threads | See Appendix 1 - Additional Details | LWG | 1492 |
ACCEPTED with MODIFICATIONS
See paper N3197 |
JP 58 | 30.4.1.1 ¶ 3 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(9)" to "(Clause 9)". | editor | ACCEPTED | |
US 189 | 30.4.1.1 30.4.1.2 | mutex and recursive_mutex should have an is_locked() member function. is_locked allows a user to test a lock without acquiring it and can be used to implement a lightweight try_try_lock. |
Add a member function:
bool is_locked() const;to std::mutex and std::recursive_mutex. These functions return true if the current thread would not be able to obtain a mutex. These functions do not synchronize with anything (and, thus, can avoid a memory fence). |
LWG | 1493 |
REJECTED
The Concurrency subgroup reviewed this issue and deemed it to be an extension to be handled after publishing C++0x. |
JP 59 | 30.4.1.2 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(9)" to "(Clause 9)". | editor | ACCEPTED | |
JP 60 | 30.4.2.1 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(9)" to "(Clause 9)". | editor | ACCEPTED | |
JP 61 | 30.4.2.2 ¶ 2 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(9)" to "(Clause 9)". | editor | ACCEPTED | |
JP 70 | 30.4.3.2 ¶ 18 | Constant width font should be used for "std::system_error"s in the paragraph as described in Syntax notation (1.6). |
Change the font for "std::system_error" to
constant width type. Throws: system_error when an exception is required |
editor | ACCEPTED | |
JP 100 | 30.4.3.2.2 ¶ 18 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
US 190 | 30.4.5.2 ¶ para 2, 3 | The term "are serialized" is never defined. | Remove the sentence with "are serialized" from paragraph 2. Add "Calls to call_once on the same once_flag object shall not introduce data races (17.6.4.8)." to paragraph 3. | LWG | 1494 | |
JP 101 | 30.4.5.2 ¶ 4 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
US 191 | 30.5 | The condition variable wait_for returning cv_status is insufficient. | Return a duration of timeout remaining instead. See Appendix 1 - Additional Details | LWG | 1495 |
ACCEPTED with MODIFICATIONS
See paper N3191 |
GB 139 | 30.5 ¶ 7 | The text says "... ownership of the lock as the current thred exits, ...", with "thread" misspelled. | Replace "thred" with "thread" | editor | ACCEPTED | |
GB 140 | 30.5 ¶ 9 | The text says "... waiting threds ..." with "threads" misspelled. | Replace "threds" with "threads". | editor | ACCEPTED | |
CH 28 | 30.5.1 | Requiring wait_until makes it impossible to implement condition_variable correctly using respective objects provided by the operating system (i.e. implementing the native_handle() function) on many platforms (e.g. POSIX, Windows, MacOS X) or using the same object as for the condition variable proposed for C. | Remove the wait_until functions or make them at least conditionally supported. | LWG | 1496 |
ACCEPTED with MODIFICATIONS
See paper N3191 |
JP 102 | 30.5.1 ¶ 3 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
CH 30 | 30.5.1 and 30.5.2 ¶ p13, last bullet, and corresponding paragraphs in all wait functions | If lock.lock() throws an exception, the postcondition can not be generally achieved. | Either state that the postcondition might not be achieved, depending on the error condition, or state that terminate() is called in this case. | LWG | 1497 | |
JP 103 | 30.5.1 ¶ 15 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
CH 31 | 30.5.1 and 30.5.2 ¶ p19, third bullet, and corresponding paragraphs in all wait_for/wait_until functions | The sentences contain superflous "or"s. | Change "The function will unblock when signaled by a call to notify_one() or a call to notify_all(), if abs_time <= Clock::now(), or spuriously." to "The function will unblock when signaled by a call to notify_one(), a call to notify_all(), if abs_time <= Clock::now(), or spuriously." | editor |
REJECTED
This is correct as written. There are three conditions: "when signalled", "if", "spuriously". The first has two parts, separated by "or". |
|
JP 104 | 30.5.1 ¶ 22 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
US 192 | 30.5.1 ¶ para 26 | The identifier cv_status::no_timeout is not in code font. | Change it to code font. | editor | ACCEPTED | |
CH 29 | 30.5.1 and 30.5.2 ¶ p34 and p28, respectively | 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. | 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. | LWG | 1498 |
ACCEPTED with MODIFICATIONS
See paper N3191 |
US 193 | 30.5.1, 30.5.2 | Condition variables preclude a wakeup optimization. | Change condition_variable to allow such optimization. See Appendix 1 - Additional Details | LWG | 1499 |
REJECTED
THe Concurrency subgroup reviewed the issue, and deemed it an extension to be handled after C++0x. |
JP 62 | 30.5.1 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(9)" to "(Clause 9)". | editor | ACCEPTED | |
CH 32 | 30.5.2 | Given that the lock type can be something the underlying doesn't know 'native_handle()' is probably unimplementable on essentially all platforms. | Consider the removal of 'native_handle()'. | LWG | 1500 | ACCEPTED |
JP 105 | 30.5.2 ¶ 12 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
JP 106 | 30.5.2 ¶ 18 | In Throw clause, both "Throws: system_error" and "Throws: std::system_error" are used. They should be in a unified way, and we propose to use system_error instead of std::system_error. |
Change to: Throws: system_error |
editor | ACCEPTED | |
CH 33 | 30.5.2 ¶ before p25 | Template function wait_until is missing class Clock template parameter. | Change "template <class Lock, class Duration, class Predicate>" to "template <class Lock, class Clock, class Duration, class Predicate>". | editor | ACCEPTED | |
JP 96 | 30.5.3 ¶ 2 |
Inconsistency between 30.4 paragraph 1 and 30.4.3
paragraph 2.
In 30.4 paragraph 1:
namespace std { ... constexpr defer_lock_t defer_lock { }; constexpr try_to_lock_t try_to_lock { }; constexpr adopt_lock_t adopt_lock { }; }In 30.4.3 paragraph 2: namespace std { ... extern const defer_lock_t defer_lock { }; extern const try_to_lock_t try_to_lock { }; extern const adopt_lock_t adopt_lock { }; }The writer seems to have forgotten to rewrite latter cases, so 30.4.3 paragraph 2 should be modified as this proposal. |
Change "extern const" to "constexpr".
namespace std { ... constexpr defer_lock_t defer_lock { }; constexpr try_to_lock_t try_to_lock { }; constexpr adopt_lock_t adopt_lock { }; } |
editor | ACCEPTED | |
US 194 | 30.6 | The specification for managing associated asynchronous state is confusing, sometimes omitted, and redundantly specified. | Define terms-of-art for releasing, making ready, and abandoning an associated asynchronous state. Use those terms where appropriate. See Appendix 1 - Additional Details | LWG | 1501 |
ACCEPTED with MODIFICATIONS
See paper N3192 |
CH 34 | 30.6.1 ¶ p1 | The paragraph is misleading and incorrect wrt to the current specification, since an async call with launch::sync will execute in the same thread. | Change the paragraph to '30.6 describes components that a C++ program can use to retrieve the result (value or exception) of a function that has run in a (potentially different) thread.' | editor | ACCEPTED | |
US 195 | 30.6.4 ¶ para 8 | The intent and meaning of the paragraph is not apparent. | LWG | 1502 | ||
CH 35 | 30.6.4ff | The term "associated asynchronous state" is long, ugly and misleading terminology. When introduced we agreed upon that we should come up with a better name. Here it is: "liaison state". Since the state is hidden and provides synchronization of a future with its corresponding promise, we believe "liaison state" is a much better and shorter name (liaison ~ (typically hidden) relationship) | Change all occurrences of "associated asynchronous state" to "liaison state". | LWG | 1503 | |
US 196 | 30.6.5 ¶ para 21, 25 | The term "are serialized" is not defined. | Replace "are serialized" with "shall not introduce a data race (17.6.4.8)". | LWG | 1504 | |
US 197 | 30.6.5 ¶ para 21, 25 | There is no defined synchronization between promise::set_value and future::get. | Replace "[Note: and they synchronize and serialize with other functions through the referred associated asynchronous state. --end note]" with the normative "They synchronize with (1.10) any operation on a future object with the same associated asynchronous state marked ready." | LWG | 1505 | |
US 198 | 30.6.5 ¶ 22 | promise::set_exception can be called with a null pointer, but none of the descriptions of the get() functions for the three types of futures say what happens for this case. | Add the following sentence to the end of 30.6.5/22: The behavior of a program that calls set_exception with a null pointer is undefined. | LWG | 1506 | ACCEPTED |
US 199 | [futures.promise] 30.6.5 ¶ 26ff, 29ff | promise::XXX_at_thread_exit functions have no synchronization requirements. Specifying synchronization for these member functions requires coordinating with the words in 30.6.5/21 and 25, which give synchronization requirements for promise::set_value and promise::set_exception. | Change 30.6.5/21 to mention set_value_at_thread_exit and set_exception_at_thread_exit; with this text, replace 30.6.5/25 and add two new paragraphs, after 30.6.5/28 and 30.6.5/31. | LWG | 1507 | |
US 200 | 30.6.6 ¶ para 26 | The paragraph is missing the "Returns:" label. | Add the label. | editor | ACCEPTED | |
US 201 | [futures.unique_future], [futures.shared_future], [futures.atomic_future], [futures.task] 30.6.6 30.6.7 30.6.8 30.6.10 | packaged_task provides operator bool() to check whether an object has an associated asynchronous state. The various future types provide a member function valid() that does the same thing. The names of these members should be the same. | Replaced the name packaged_task::operator bool() with packaged_task::valid() in the synopsis (30.6.10 [futures.task]/2) and the member function specification (before 30.6.10.1 [futures.task.members]/15). | LWG | 1508 |
ACCEPTED with MODIFICATIONS
See paper N3194 |
US 202 | [futures.atomic_future] 30.6.8 ¶ 18 | The note in this paragraph says "unlike future, calling get more than once on the same atomic_future object is well defined and produces the result again." There is nothing in future that says anything negative about calling get more than once. | Remove this note, or add words to the requirements for future that reflect what this note says. | LWG | 1509 |
ACCEPTED with MODIFICATIONS
See paper N3194 |
US 203 | [futures.atomic_future] 30.6.8 | Both future and shared_future specify that calling most member functions on an object for which valid() == false produces undefined behavior. There is no such statement for atomic_future. | Add a new paragraph after 30.6.8 [futures.atomic_future]/2 with the same words as 30.6.7 [futures.shared_future]/3. | LWG | 1510 |
ACCEPTED with MODIFICATIONS
See paper N3194 |
US 204 | 30.6.8 ¶ Paragraph 7-8 | According to the definition of atomic_future, all members of atomic_future are synchronizing except constructors. However, it would probably be appropriate for a move constructor to be synchronizing on the source object. If not, the postconditions on paragraphs 7-8, might not be satisfied. This may be applicable if a collection of futures are being doled out to a set of threads that process their value. | Make the move constructor for atomic future lock the source | LWG | 1511 |
ACCEPTED with MODIFICATIONS
See paper N3194 |
US 205 | [futures.async] 30.6.9 ¶ 3 | The third sentence says "If the invocation is not deferred, a call to a waiting function on an asynchronous return object that shares the associated asynchronous state created by this async call shall block until the associated thread has completed." The next sentence says "If the invocation is not deferred, the join() on the created thread..." Blocking until a thread completes is not necessarily a join. | Decide whether the requirement is to block until finished or to call join, and rewrite to match. | LWG | 1512 |
ACCEPTED with MODIFICATIONS
See paper N3194 |
CH 36 | 30.6.9 and 30.6.1 ¶ <future> synopsis and p3, respectively | Providing only three different possible values for the enum launch and saying that launch::any means either launch::sync or launch::async is very restricting. This hinders future implementors to provide clever infrastructures that can simply by used by a call to async(launch::any,...). Also there is no hook for an implementation to provide additional alternatives to launch enumeration and no useful means to combine those (i.e. interpret them like flags). We believe something like async(launch::sync | launch::async, ...) should be allowed and can become especially useful if one could say also something like async(launch::any & ~launch::sync, ....) respectively. This flexibility might limit the features usable in the function called through async(), but it will allow a path to effortless profit from improved hardware/software without complicating the programming model when just using async(launch::any,...) |
Change in 30.6.1 'enum class launch' to allow
further implementation defined values and provide
the following bit-operators on the launch values
(operator|, operator&, operator~ delivering a
launch value). Note: a possible implementation might use an unsigned value to represent the launch 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. Change [future.async] p3 according to the changes to enum launch. change --launch::any 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 launch::async or launch::sync describe one should call async(launch::sync|launch::async,...) |
LWG | 1513 |
ACCEPTED with MODIFICATIONS
See paper N3188 |
JP 107 | 30.6.9 ¶ 3 | Typo, "." should be ">". decay_copy(std::forward<Args.(args))... | Correct typo. decay_copy(std::forward<Args>(args))... | editor | ACCEPTED | |
JP 108 | 30.6.9 ¶ 3 | <Arg> should be <Args>. launch::sync Stores decay_copy(std::forward<F>(f)) and decay_copy(std::forward<Arg>(args))... |
Change to: launch::sync Stores decay_copy(std::forward<F>(f)) and decay_copy(std::forward<Args>(args))... |
editor | ACCEPTED | |
US 206 | [futures.task.members] 30.6.10.1 ¶ 27, 28 | The text of paragraph 27 says that reset() moves the function object, but the text of paragraph 28 talks about exceptions thrown by the copy constructor. | Change "copy constructor" to "move constructor" in 30.6.10.1/28, bullet 2. | editor | ACCEPTED | |
US 207 | [futures.task.members] 30.6.10.1 ¶ 1-8 | The constructor that takes R(*)(ArgTypes...) is not needed; the constructor that takes a callable type works for this argument type. More generally, the constructors for packaged_task should parallel those for function. | Review the constructors for packaged_task and provide the same ones as function, except where inappropriate. | LWG | 1514 | |
US 208 | [futures.task.members] 30.6.10.1 ¶ 24-26 | packaged_task::make_ready_at_thread_exit has no synchronization requirements. | Figure out what the synchronization requirements should be and write them. | LWG | 1515 | |
GB 141 | Appendix A [gram] paragraph 1 | The links for disambiguation rules go to 6.8, 7.1 and 10.2. Section 8.2 covers ambiguity in declarators, so should be added | Added a link to 8.2 [dcl.ambig.res] to Appendix A p1 | editor | ACCEPTED | |
JP 63 | A.1 ¶ 1 | Representations of reference link are not unified. Most reference links to clause (table) number, say X, are in the form "Clause X" ("Table X") capitalized, and subsection Y.Y.Y is referenced with its number only in the form "Y.Y.Y". Whether they are parenthesized or not depends on the context. However there are some notations "(Z)" consisting of only a number Z in parentheses to confer Clause or Table number Z. | Change "(clause 9)" to "(Clause 9)". Change "(clause 14)" to "(Clause 14)". | editor | ACCEPTED | |
FI 6 | D.2 [depr.static] ¶ Paragraph 1 | The use of static in namespace scope should not be deprecated. Anonymous namespaces are not a sufficient replacement for the functionality. | Strike [depr.static] completely. | CWG | 1012 | ACCEPTED |
GB 142 | D10 | auto_ptr does not appear in the <memory> synopsis and [depr.auto.ptr] doesn't say which header declares it. Conversely, the deprecated binders bind1st etc. are in the <functional> synopsis, this is inconsistent | Either auto_ptr should be declared in the <memory> synopsis, or the deprecated binders should be removed from the <functional> synopsis and appendix D should say which header declares the binders and auto_ptr | LWG | 1516 | ACCEPTED |
JP 109 | Annex B | Although implementation limits for at_quick_exit() is mentioned in 18.5 paragraph 5, it is not on the list of Implementation quantities. | Add the following line. — Functions registered by at_quick_exit()[32]. | editor | ACCEPTED | |
JP 110 | Index |
"local scope" has been renamed to "block scope", but the
reference to "local scope" still remains in Index. block scope; see local scope, 37 "local scope" should refer to "block scope". |
Change to: local scope; see block scope, 37 |
editor | ACCEPTED |